Limiting and blocking connections dynamically.
Today I feel like talking about limiting connections which get made to a server. There are a few ways to do it; some cooler than others. I'd like to feature some open source software while I'm at it.
Today I happened upon this thread which hilariously got closed for good reason. Once you wade through all the crap you'll see some pretty cool posts which explain how to limit incoming connections within a certain time period and other suggestions. I'll point out the most useful related ones and then recommend an open source solution on top of it.
Post Highlights
My first highlight is post #8. This cool post shows how you can limit incoming connection attempts on any given port (in the example port 22) to just 3 times a minute. I'm not an iptables guru but I thought that little gem was pretty cool.
Second highlight would be post #12 and post #14. Post #14 being a simple breakdown explaining what post #12 does. This is nice, because it shows how you can put the suggested rules in post #8 within a script if you don't already have a file for iptables rules and get it up and running fast. Quick and dirty but it works until the server is bounced (restarted).
This brings me to my last highlight of the thread, post #20. Building upon all the previously mentioned highlighted posts, this post shows you how to make the rules more permanent which could then optionally be enabled by default when the machine is rebooted (or loses power, or whatever).
Followup results
Here's a quick command tutorial (commands only) which explain the process of enabling that in CentOS (Actually tested on RedHat but methodically the same). This also applies to Fedora 14 (Only other version I've tested on but likely for all versions of Fedora as well). If you're running Ubuntu server then you'll want to read this instead of following my commands verbatim.
Also note these commands are run as root. These commands use information from all previously mentioned posts and then elaborated.
Remember, the rules I mentioned above are purely within the scope of the thread this blog post is about. Your system performance requirements may be different and you'll likely want more/less/different restricting port rules than the ones mentioned above.
I'd also like to state there is no such thing as an IP Phone system or application which is incompatible with SELinux, iptables, or any other security layer outlined in the PCI Security Standards. It just means you have to configure these services yourself for the given application assuming the application developers were not nice enough to include security as a section in their docs. So unless you're running a blog about cheese sandwiches then I suggest turning on as much security as you have available for your platform. If you can't be within security standards then you're using the wrong OS or you're an incompetent sysadmin.
"incompetent sysadmin" is not an insult but should be taken as an incentive to pick up a book and learn about these skills.
Recommended open source project
Now that we're on the same page with iptables it's time to introduce you to Fail2ban. Fail2ban is a cool piece of software we use here at Drexel University. Fail2ban scans auth logs associated with different services for failed login attempts. After a certain number of failed login attempts (configurable) the violating IP address attempting the logins gets banned.
Basically it reads the source IP of the auth request and then updates the iptables firewall rules to block incomming connections just from that IP address.
This is more elaborate than the previous iptables rules because it dynamically updates the firewall rules based on current and past connections. You can make the bans permanent or temporary.
Fail2ban is not a replacement for iptables but rather a helper application which further improves the security and integrity of any given system. When bullets don't work, bombs and nuclear missiles will.
DISCLAIMER: I am not being paid to promote fail2ban or any open source project on my LQ blog.
Today I happened upon this thread which hilariously got closed for good reason. Once you wade through all the crap you'll see some pretty cool posts which explain how to limit incoming connections within a certain time period and other suggestions. I'll point out the most useful related ones and then recommend an open source solution on top of it.
Post Highlights
My first highlight is post #8. This cool post shows how you can limit incoming connection attempts on any given port (in the example port 22) to just 3 times a minute. I'm not an iptables guru but I thought that little gem was pretty cool.
Second highlight would be post #12 and post #14. Post #14 being a simple breakdown explaining what post #12 does. This is nice, because it shows how you can put the suggested rules in post #8 within a script if you don't already have a file for iptables rules and get it up and running fast. Quick and dirty but it works until the server is bounced (restarted).
This brings me to my last highlight of the thread, post #20. Building upon all the previously mentioned highlighted posts, this post shows you how to make the rules more permanent which could then optionally be enabled by default when the machine is rebooted (or loses power, or whatever).
Followup results
Here's a quick command tutorial (commands only) which explain the process of enabling that in CentOS (Actually tested on RedHat but methodically the same). This also applies to Fedora 14 (Only other version I've tested on but likely for all versions of Fedora as well). If you're running Ubuntu server then you'll want to read this instead of following my commands verbatim.
Also note these commands are run as root. These commands use information from all previously mentioned posts and then elaborated.
Code:
service iptables stop iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 5060 -m state --state NEW -m recent --set iptables -A INPUT -i eth0 -p tcp --dport 5060 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP iptables -A INPUT -i eth0 -p tcp -m tcp -m state --state NEW -j ACCEPT iptables -A INPUT -i eth0 -p udp -m udp -m state --state NEW -j ACCEPT iptables -A INPUT -i eth0 -p icmp -m icmp --icmp-type any -j ACCEPT iptables -A INPUT -i eth0 -j REJECT --reject-with icmp-host-prohibited iptables-save > /etc/sysconfig/iptables chkconfig --add iptables chkconfig --levels 35 iptables on service iptables start
I'd also like to state there is no such thing as an IP Phone system or application which is incompatible with SELinux, iptables, or any other security layer outlined in the PCI Security Standards. It just means you have to configure these services yourself for the given application assuming the application developers were not nice enough to include security as a section in their docs. So unless you're running a blog about cheese sandwiches then I suggest turning on as much security as you have available for your platform. If you can't be within security standards then you're using the wrong OS or you're an incompetent sysadmin.
"incompetent sysadmin" is not an insult but should be taken as an incentive to pick up a book and learn about these skills.
Recommended open source project
Now that we're on the same page with iptables it's time to introduce you to Fail2ban. Fail2ban is a cool piece of software we use here at Drexel University. Fail2ban scans auth logs associated with different services for failed login attempts. After a certain number of failed login attempts (configurable) the violating IP address attempting the logins gets banned.
Basically it reads the source IP of the auth request and then updates the iptables firewall rules to block incomming connections just from that IP address.
This is more elaborate than the previous iptables rules because it dynamically updates the firewall rules based on current and past connections. You can make the bans permanent or temporary.
Fail2ban is not a replacement for iptables but rather a helper application which further improves the security and integrity of any given system. When bullets don't work, bombs and nuclear missiles will.
DISCLAIMER: I am not being paid to promote fail2ban or any open source project on my LQ blog.
Total Comments 0
