[SOLVED] iptables: appropriate limits?

DJRcomputing · 06-26-2011, 09:20 AM

After a LOT of studying iptables, one thing I'm not quite certain about is suitable limit rates for SYN, LOG & ping flood prevention. I suppose it depends a bit on traffic, as well as bandwidth. However, I don't want to limit the former. FWIW, I expect about as much traffic as a country road in the middle of nowhere, and my bandwidth for requests is 15 Mbps (Don't laugh. Content delivery is a pathetic 2 Mbps.

That's a residential cable connection for ya...)

Of all the tutorials/examples, I chose to go with Rusty Russel's limits, though they're dated 2002. Thus an excerpt of my firewall "script":

Code:

#!/bin/sh
# Saved in /etc/init.d, runlevels 2 3 4 5
# Set default (OPEN) chain policies to DROP
iptables -P INPUT   DROP
iptables -P FORWARD DROP
... <- ESTABLISHED,RELATED :)
# Prevent NEW packets without SYN set
iptables -A INPUT -p tcp ! --syn -m state --state NEW -m limit --limit 1/s -j LOG --log-prefix "iptables: NEW not SYN "
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Prevent SYN floods
iptables -N normal
iptables -A INPUT -p tcp --syn -m state --state NEW -m limit --limit 1/s -j normal
# Allow inbound session requests
iptables -A normal -p tcp --dport 80  -m state --state NEW -j ACCEPT
iptables -A normal -p tcp --dport 443 -m state --state NEW -j ACCEPT
...
# Allow helpful ICMP messages
iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW -m limit --limit 1/s -j ACCEPT
...
# Log everything else inbound before DROP default
iptables -A INPUT -m limit --limit 1/s -j --log-prefix "iptables: DROP "
exit 0

Thoughts? I will say that it really puts the brakes on Nmap. I am a bit concerned, though, that someone from Canada keeps sniffing my ports, eh.

lazydog · 06-26-2011, 11:13 AM

It would all depend on what you feel comfortable with. I do think that your limiting SYN connection to 1 a second is really low. Most browsers today try and open a number of connection to speed up the downloading of the web pages. Firefox I believe tries to open 16 by default.

Also I see you are using the NEW tag but are not using the ESTABLISHED,RELATED tags. Might want to place them at the top of your chains.

DJRcomputing · 06-26-2011, 03:15 PM

Quote:

Originally Posted by lazydog

I do think that your limiting SYN connection to 1 a second is really low. Most browsers today try and open a number of connection to speed up the downloading of the web pages. Firefox I believe tries to open 16 by default.

I appreciate your insight, as that's the type of thing I wondered about. It also raises one of my confusions: limit vs. burst, ie: --limit 16/s (default --limit-burst 5) vs --limit 5/s --limit-burst 16, at least given a rate in seconds?

Quote:

Originally Posted by lazydog

Also I see you are using the NEW tag but are not using the ESTABLISHED,RELATED tags. Might want to place them at the top of your chains.

Guess I should've also included those in my excerpt, which I did in the interest of a shorter post.

If one wishes to see my entire "script" (in quotes again because it's nothing fancy, but it does the job), I've attached it. Thanks for your concern, though.

lazydog · 06-27-2011, 12:55 PM

Maybe this SITE will help you understand limits and burst.

DJRcomputing · 07-02-2011, 07:07 AM

Quote:

Originally Posted by lazydog

Maybe this SITE will help you understand limits and burst.

As it mostly reitterates Rusty Russel, not really. However it did show me how to do a proper iptables init.d script, which I really appreciate knowing.

I decided to finally tackled Oskar Andreasson's mind-numbing tutorial, which offers a different way of explaining limits. Apparently I have a bucket. LOL!

Otherwise, I came across an insightful thread elsewhere which brought up a valid point: self-inflicted DoS. Set the SYN limit too low, and one denies service before one's resources are even depleted. That tread also turned me onto SYN cookies (mmm...cookies). Via a link from an article about such, I came across Wesley Eddy's article which mentions another option: SYN cache. As I later discovered, though, it's a FreeBSD-only option.

In the end, I'm going to drop SYN limit. Even though DoS attacks are caused by SYN floods, and iptables can limit SYN, it doesn't seem to be a very good way of preventing DoS. Regardless, I've learned a LOT about DoS mitigation, which will hopefully be valuable in the future. Thanks for your help.