SYN_RECV flood still happening with giptables
 

Hello everyone, I finally finished configuring giptables as well as mrtg and am now having one final proplem. My website was working good for a few hours then all of a sudden I am unable to access it. I do a netstat -veen and realize I have over 90 syn_recv connection stattes. I thought giptables was supposed to protect against this sort of attack ? My hardware :
Amd athlon xp 3000+ with 400 mhz fsb
1 gb kingston ram
asus network card
here is what is going on
Thanks for helping me out

Did you enable syn-flood protection in the giptables.conf file?

If you haven't, checkout the link to the docs posted below under the "Syn-flood Protection Definitions" header.

You can also make sure that giptables is enabling tcp_syncookies by doing:
more /proc/sys/net/ipv4/tcp_syncookies
If it's enabled, you should see a "1" as the contents of the file.

giptables doc:
http://www.giptables.org/configuration.html

The weird thing is I have the syn cookies enabled as well as the syn flood protection in giptables. I do not know what to do anymore. It looks to me like giptables limits the number of new connections, but not total connections. It's been about 12 hours and the same ips have the same state, SYN_RECV. Is there another script that would help me in this situation, or a rule base ? Some help as to what I could do to be able to access my webserver again would be very helpful.

SFAIK SYN cookies will only help you if the same IP is trying to SYN flood you, but it won't help if multiple IPs are sending one SYN each.

There may be some sysctl kernel variables that let you reduce the amount of time that a connection will sit in SYN_RECV before it times out.

It shouldn't make a difference. Once the queue begins to fill, the system won't enter any new states into the table unless the remote system(s) sending SYNs responds to the SYN-ACK with the proper "cookie". So whether it's one or a bunch, as long as it isn't attempting real TCP connections, then tcp_syncookies should help mitigate it some.


@microsucks:
check the state table to see how many connections are actively in there. With that much RAM, you chould at least be able to handle 1024 simultaneous connections. Check the number of entries with:
cat /proc/net/ip_conntrack | wc -l
That should spit out the number of entries in the table. You only posted ~98 entries, so you should be well below the max threshold.

You might also want to fire up tcpdump and capture a few packets in order to get an idea of how big the packets are and how fast they're coming at you. If there coming in reasonably fast, you can do burst limiting.