Chapter 3 of the Linux Networking Cookbook, "Building a Linux Firewall", lays out a number of iptables scripts for different uses, such as a server firewall, an Internet gateway, sharing an Internet connection, and host firewalls. It includes start-stop scripts so you can easily bring your firewall up and down, and have it start automatically at boot.

The other chapters in the book include iptables rules for specific services and situations, but there is one useful function that didn't make it into the book, and that is some simple iptables rules for blocking brute-force login attacks, such as the automated SSH attacks that infest the Internet. These will continue to wander and annoy long after the sociopaths who launched them are dead and forgotten. All you need are two rules per service, like this:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m
recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m
recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

This limits all incoming connections to port 22 to 8 per minute. To prevent
locking yourself out, you can create a whitelist:

iptables -N ssh-whitelist
iptables -A ssh-whitelist -s [your-ip-address] -m recent --remove --name
SSH -j ACCEPT

Then modify your limiting rules like this:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m
recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j
ssh-whitelist
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m
recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP


You can easily adapt this for any service. The --set --name option creates an arbitrary name, so you can call it anything you want. Just make sure it matches the --name in your DROP rule.

Recipe 7.15 tells how to use the excellent DenyHosts utility, which is another good way to do the same job.

I avoid having to deal with a whitelist in my rules by putting it at the top of my rules with accept targets. I like the idea of jumping to the whitelist. It simlpifies editing the rules on the fly. I don't think I understood before I read this post that named jumps dropped through back to the jump off point.

I like the tip. I've been meaning to go through my logs and the ever expanding iptables modules to figure some of this out. I'll have to use a VPN to get static addresses Gor the whitelist. I recently learned that you can have separate configurations based on ip in ssh. Which can allow for tighter restrictions on unsecure interfaces/sources.

It looks like you could combine the first and second lines of your input rules by adding the jump target to the first input rule. It also looks likes you could avoid having to clear a recent from the SSH recent by doing the whitelist jump before the recent test. Just my two cents.

Your two cents are worth at least four cents- you're right, they could be streamlined with a bit of better organization. Ok five cents. But that's my final offer. Maybe a custom rate-limiting chain would be even more efficient and easier to maintain; I'll try it out and then post the results. If it works, that is