iptables: syn-flood rule for a busy webserver?

somebody told me there are no stupid questions... so here's mine regarding linux iptables firewall:

various sources have suggested adding a syn-flood chain to prevent some Dos attacks. so i implemented the following:



Now, as far as i understand limit matching, this example would count new connections no matter where they're from. i'm running a very busy webserver, so i assume that every client would create various connection requests (syn bit set) for every page access. so just a few clients connecting at the same time would cause this limit rule to be triggered, making for a very slow server.

is this assumption correct? does it even make sense to have a syn flood rule like this when running a busy web server or is this a safe setting (burst: 24/s then 12/s) that wouldn't cause any slowdown?

otherwise, would it make sense to exclude busy web ports from this by inserting this rule in first slot of the flood chain:

If you have a busy web server you should have a firewall in front of it, use that as you are just putting more stress on the server doing filtering there. example would be a PIX with flood defender enabled this would actualy start proxying the syn packets on behalf of the server and waite for ACKs then release half-open connections to allow veirified connections in. as well you want your router/firewall to protect against half-open (syn attacks) connections created by spoofed addresses by implementing an ACL that blocks connections from known bad addresses like so

ip access-list extended OUTSIDEACL
deny ip 10.0.0.0 0.255.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.0.255.255 any

that way they cant send SYN packets with a bad address source that creates half-open connections.

juniperr, i wish i could have a dedicated firewall; all my troubles would be solved as the firewalls offered by our host are fully managed CheckPoint L2; but unfortunately the monthly cost is not acceptable to management.

so i have to make do with basic iptables protection. but the syn flood problem still stands. might i be better off without it? it looks like it isnt much more useful than letting every syn flag request thru to these very few open ports because if you would syn-flood our server, it would slow down new connections for everyone regardless. am i correct on this?

btw, i do drop these ips you mentioned. in fact, i also don't let in multicast, RFC1918 and reserverd ips over the external interface:



in addition, i check for bad flag combos, invalid connection states and spoofed local ips.

since you are on linux I would lookup the use of "syncookies" and see if it fits your environment. also decrease the syn-ack time (how long the server waites for the ACK to time out) so it closes the connection faster. That is what I would do for now, do you see an issue right now with being attacked? the entry you are using will prolly give yourself a DoS.

syn cookies seems like a decent solution as long as it doesnt decrease performance otherwise (http://cr.yp.to/syncookies.html --> DJB ala Mr. Qmail doesn't think so...and i tend to trust the guy ). so with this enabled, i guess i can disable the syn flood chain....

however, i'm still scratching my head over the fact that almost every book out there seems to recommend the limit matching syn-flood packet-filter solution i described. as far as i can tell i must agree with you; this seems like a self-imposed DoS; or a constant connection limit for "desirable" traffic at best. what would be the advantage of it though if the server gets incapacitated either way? there must be something that i'm missing since i can't believe all these authors suggesting this didnt think it through? anybody got any ideas?

This is why they came out with syncookies and is relatively new I dont even think windows suppports it, the most common thing to do is have a firewall (or reverse proxy servers) proxy the syn requests and block bad IPs to mitigate half-open connections they also lower the syn-ack response time and or create larger buffers. I havent seen many peeps put a syn limit on the server like you where doing but if you have a low volume server it would work. however, if you are under attack you are guaranteed to DoS yourself this is why high volume servers dont use those limits unless they use IDS that will see one host spamming and use a dynamic acl to block the one host rather then a limit blocking everyone.