iptables rate limiting

[jbh]

I came across this as a possible way to limit the number of attempts a bot can make at registering before fail2ban kicks in (i.e. if the bot is so fast it can make many attempts before fail2ban detects that many > 3)

I did the following at the command prompt (for some reason putting this in /etc/sysconfig/iptables did not work, as it didn't like the syntax od \--set when I did a service iptables restart):

$ iptables -I INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent \--set

$ iptables -I INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent \--updaate --seconds 60 --hitcount 3 -j DROP


The effect of this seems to be to limit the number of attempts to register (even with the correct authentication details !) to three within a 60 second period. Obviously you can tweak the time period and number of attempts as you wish. I checked that it is iptables stopping the registrations by turning fail2ban off. After the 60 second period is over, you are allowed to register again.

This does not seem to retrict the ability to make lots of calls within the specified time period - just the new registration attempts.

If you want to kill the restriction - you just do a service iptables restart.

I'm aware though that I don't really understand what I'm playing with here - so would very much appreciate any input as to whether this is sensible thing to do.

If you want to kill the restriction - you just do a service iptables restart.

 

[flactemnad]

I like your implementation. I'd tweak the period and count personally, but looks pretty good. You could add that to a startup script or even modify the iptables startup to start this.

Since I don't have any outside SIP connections other than static IP I don't have this issue, but if I did I'd probably give them 2-3 chances and at least a 3 minute outage. Once your setups are saved and no retry is necessary then you could lower the trigger threshold.

I'm not sure, as I haven't tested, but I think each time someone connects to 5060 you'll count them 2x. Once on the set, and once on the update. So you've given them a total of 1 chances to login every 60 seconds.

--set
              This will add the source address of the packet to the list. If the source address is already in the list, this  will  update
              the existing entry. This will always return success.

Here's what I would probably try (Note: My example is using "-A" for add to go in a permanent ruleset. If you are using "-I" for insert it goes to the top of the list, but you should setup your rules in reverse order from last to first if doing that.)

# iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent --set
# iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent --rcheck --seconds 3600 --hitcount 100 -j DROP
# iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent --rcheck --seconds  600 --hitcount  20 -j DROP
# iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent --rcheck --seconds  300 --hitcount  10 -j DROP
# iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent --rcheck --seconds  180 --hitcount   5 -j DROP
# iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW -m recent --rcheck --seconds   60 --hitcount   3 -j DROP

^ That example first sets or updates new UDP 5060 connections counter for the remote IP. Then checks to see how many hits there are on that port, and applies a timeout accordingly. Higher timeouts come first since once a "-j" action is found the evaluation of that packet stops.

So for 3 attempts the lockout is 1 minute. If the IP continues trying the timeout will increment automatically:
5 hits 3 minutes, 10 hits 5 minutes, 20 hits 10 minutes, 100 hits 1 hour.

More info regarding the recent module in iptables.
http://snowman.net/projects/ipt_recent/
http://www.e18.physik.tu-muenchen.de/~tnagel/ipt_recent/

 

[flactemnad]

FYI, this came in handy just today on a client's non-VoIP mail server. They were getting pounded on POP3 email (TCP 110) by IP's from all over the place, mostly spoofed.

Normally this is auto blocked after a few failed attempts, but something was broken on that security check so I decided to play around with this setup to see how it works. I'm happy to report that it worked beautifully.

Here's what I did, and with only a little modification it could be used in many different ways:

First of all, create a new rule chain:

iptables -N Attack-Sense-Firewall

Then add the set rules.

iptables -A Attack-Sense-Firewall -p tcp --dport 110 -m state --state NEW -m recent --set --name MailFetch

Add in the rcheck statements. If there are more than 20 new connection hits from any IP within 60 seconds the connection is dropped.

iptables -A Attack-Sense-Firewall -p tcp --dport 110 -m state --state NEW -m recent --rcheck --seconds   60 --hitcount  20 --name MailFetch -j DROP

Now make the rules active by forcing all input traffic through the newly created Attack-Sense-Firewall chain.

iptables -I INPUT -j Attack-Sense-Firewall

I kept taking this rule offline and putting it back up. At one time we had over 1000 connections to the pop3 services and once that last command was input it was a matter of a minute or so before there were no longer any stale connections from unauthorized IP addresses. Restart the firewall from scratch and within 5 seconds the connection count was up over 800! Reapply these rules and it again dropped.

I tried to mess with other hitcount levels, but it seems on Centos 4.7 it's not really counting past 20. Will have to upgrade the OS on that system to see if we can do better than that.