Defending against SYN floods and other TCP-level attacks is a matter of hardening your kernel. It is not something LiteSpeed Web Server or any other HTTP server can deal with. (For an explanation of how SYN floods work and why they are not related to your HTTP server, please see this blog article. This wiki will assume you understand SYN floods and the TCP handshake.) That being said, here are some simple steps for hardening your Linux kernel:

In /etc/sysctl.conf add

net.ipv4.tcp_syncookies = 1

Syncookies allows your system to serve more TCP connection requests. Instead of logging each TCP connection request and waiting for a response, the system will instead send a cookie with its SYN-ACK response and delete the original SYN message. Any ACK response the system receives from the client will then contain information about this cookie, allowing the server to recreate the original entry. 1 enables this feature, 0 disables it. This setting is off by default.

In /etc/sysctl.conf add

net.ipv4.tcp_max_syn_backlog = 2048

This setting tells the system when to start using syncookies. When you have more than 2,048 (or whatever number you set it to) TCP connection requests in your queue, the system will start using syncookies. Keep this number pretty high to prevent from using syncookies with normal traffic.(Syncookies can be taxing for the CPU.)

In /etc/sysctl.conf add

net.ipv4.tcp_synack_retries = 3

This setting tells your system how many times to retry sending the SYN-ACK reply before giving up. The default is 5. Lowering it to 3 essentially lowers the turnaround time on a TCP connection request to about 45 seconds. (It takes about 15 seconds per attempt.)

The changes above will not take effect until you reboot. To apply them now, use

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

Doing only the above echo commands without altering /etc/sysctl.conf will mean that the changes will be lost next time you reboot.