First, you will want to install Fail2ban, so head over to Fail2Ban.org and follow their instructions for installing on your distribution. On CentOS or RedHat, you will need to first install the EPEL repository. After doing so, fail2ban can be installed with the yum command yum install fail2ban. That takes care of the installation!

Once you have Fail2Ban installed, you can start configuring it! One of the problems that I run into with Fail2Ban is that it will try to load all the firewall rules too fast, resulting in errors like this:
iptables -I INPUT -p all -j fail2ban-w00tw00t returned 400
You may also get some 100 or 200 errors as well. Well, the fix for this is easy enough (and hopefully it will be incorporated into upcoming versions; as of version 0.8.4 is is not). Simply edit the file /usr/bin/fail2ban-client and add the line time.sleep(0.1) into the __processCmd function. This is added around line #145. The first few lines of the function should look like this:

def __processCmd(self, cmd, showRet = True):
    beautifier = Beautifier()
    for c in cmd:
        time.sleep(0.1)
        beautifier.setInputCmd(c)
        try:

So, now that we have a working Fail2Ban setup, we can start configuring some rules!

First, take a look at /etc/fail2ban/fail2ban.conf. This lets us specify some log options. The only one that I am really concerned about is the logtarget, which I like to set to /var/log/fail2ban.log.

Next, let us look at the /etc/fail2ban/jail.conf file. Here you will want to configure your list of ignore IP’s, which should include localhost, and your trusted machine(s) or subnet (ex: ignoreip = 127.0.0.1 192.168.0.0/24 8.8.8.8). You can also adjust the bantime, findtime, and maxretry options, all of which are explained within the file.

Next you can pick what jails to run, and override any global settings with specific settings set here. Spend some time reading through the different jail configurations to get an idea for how to set yours up. I’m always a little more paranoid about security; I don’t want any cats in my dogghouse, so I will usually completely ban any user that fits one of my rules. You could optionally just ban them from using the service they are attempting to exploit, if you wish.

Lets take a look at a jail configuration that I wrote myself.

[dns-root]
enabled  = true
filter   = dns-root
action   = iptables-allports[name=DNS-ROOT]
           sendmail-whois[name=dns-root, dest=jerp@herpandderp.com, sender=fail2ban@myserver.com]
logpath  = /var/named/chroot/var/log/bind.log
maxretry = 2
bantime  = 86400

One of my nameservers was getting a large number of NS lookup requests for the root domains. Well, our server isn’t authoritative for the root zone, so we respond with a REFUSED notice, however this didn’t keep the requests from coming. At first I thought that it was some sort of lame DOS attack against one of my nameservers, but after investigation I found that this was likely a Root DNS Amplification Attack against Facebook! I would get approximately one request per minute for the root NS records, sending out one REFUSED response per minute to an IP address owned by Facebook. In order to combat these annoyances, I created the [dns-root] jail for Fail2Ban.

Lets take a look at what each setting in this jail does. First, the enabled line dictates whether or not the jail is active. Next, the filter line specifies the name of the filter that will be used to match undesired behavior. The action line in this case says to run the iptables-allports action, inserting an iptables rule into the chain named DNS-ROOT, which will drop traffic from the banned host on all ports. Optionally, you can select to only have specific ports dropped, instead of banning the host from your entire server. The sendmail-whois line lets us send an email, with whois inforation about the banned host, to whoever you like. Finally the logpath specifies the actual log to be checked against, and the maxretry along with the bantime values will override the global variables you specified earlier in that file.

Next, take a look at the matching filter. After removing some extra comments, we are left with this:

# Fail2Ban DNS-ROOT configuration file

[Definition]
failregex = ^.* security: info: client #.*: query \(cache\) './(NS|A|AAAA|MX|CNAME)/IN' denied

ignoreregex =

What we have are two variables. The first is failregex, which is a regex formatted statement to match denied root zone lookup lines in our log files. The next variable, ignoreregex, lets us specify something to search for, which will cause a matched line to be ignored. Basically, if the failregex line is matched, the host is banned. If both lines are matched, the host is not banned.

Now, once you have everything configured, you should be able to set the service to start at boot with the chkconfig fail2ban on command, and immediately make the service start with the service fail2ban start command.

Now you can finally have some piece of mind, knowing that those pesky internet cats wont be able to get into your dogghouse and steal your bone!

If you are interested in creating your own rules, check out Regexpal.com for help in writing and debugging regex.

If you take a look at the image above, you can see how data flows through a typical Linux firewall. Since we are currently only concerned with traffic destined for our Linux box, all data flows through the “Yes” side of the “Data for the firewall?” question. In the future we will look at the other side when we configure a Linux router.

Let’s start with a description of what we are doing, and then I’ll show what it looks like. Within IPTables there are different tables and chains, which are referenced in the picture above. We want to look primarily at the Input chain in the Filter table. The first thing we are going to do is create a new chain at the top of our input chain, which will accept all predetermined traffic that we know will always be safe. This is data such as related or established traffic, traffic on the local loopback interface, and if you are running a DHCP server on your Linux machine, you would also want to accept UDP traffic on port 67. DHCP requests come from source address 0.0.0.0, which we will be blocking later, so we need to accept it now!

After we accept this traffic, we want to block all traffic that we know is bad. This is traffic from non-existent networks (bogons), traffic with bad TCP flags, and anything else you specifically want to keep out. We will create two chains for this; one to list the traffic to be blocked, and another to block and optionally log the traffic. If you don’t wish to log the traffic, you can simply stick with one chain that will only block the undesired traffic.

Finally we can create another chain to accept traffic that we want to let in. This can be access to a SSH server, DNS server, web server, or anything else you want! After all of these chains, we can also optionally log any traffic that made it this far, before dropping it into oblivion.

Here is what the INPUT table looks like:

-A INPUT -j Firewall-1-INPUT
-A INPUT -j Firewall-1-DROP
-A INPUT -j Firewall-2-INPUT
-A INPUT -m limit --limit 1/sec -j LOG --log-prefix "[INPUT] "

Here the data comes in to the Firewall-1-INPUT chain first. If it is not accepted (or blocked) by this chain, it then moves on to the Firewall-1-DROP chain. If the data makes it past that chain it goes on to the Firewall-2-INPUT chain, and finally if it makes it the whole way through without getting accepted or blocked, it will be logged before performing the default policy, which in our case is to drop the traffic so it can’t come in.

The Firewall-1-INPUT chain looks like this:

-A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A Firewall-1-INPUT -i lo -j ACCEPT
-A Firewall-1-INPUT -p udp -m udp --dport 67 -j ACCEPT

The first line accepts any related or established traffic. The second line accepts any traffic on the local loopback interface, and the third line accepts DHCP address request traffic on UDP port 67. If you are not running a DHCP server, then you won’t need that last line.

Next we move on to the Firewall-1-DROP chain, which drops any specifically unwanted traffic.

-A Firewall-1-DROP -f -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp ! --syn -m state --state NEW -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,ACK FIN -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags PSH,ACK PSH -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags ACK,URG URG -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j Firewall-2-DROP
-A Firewall-1-DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j Firewall-2-DROP

-A Firewall-1-DROP -s 0.0.0.0/8 -j Firewall-2-DROP
-A Firewall-1-DROP -d 0.0.0.0/8 -j Firewall-2-DROP
-A Firewall-1-DROP -s 10.0.0.0/8 -j Firewall-2-DROP
-A Firewall-1-DROP -d 10.0.0.0/8 -j Firewall-2-DROP
-A Firewall-1-DROP -s 127.0.0.0/8 -j Firewall-2-DROP
-A Firewall-1-DROP -d 127.0.0.0/8 -j Firewall-2-DROP
-A Firewall-1-DROP -s 169.254.0.0/16 -j Firewall-2-DROP
-A Firewall-1-DROP -d 169.254.0.0/16 -j Firewall-2-DROP
-A Firewall-1-DROP -s 172.16.0.0/12 -j Firewall-2-DROP
-A Firewall-1-DROP -d 172.16.0.0/12 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.0.0.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.0.0.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.0.2.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.0.2.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.1.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.1.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.2.0/23 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.2.0/23 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.4.0/22 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.4.0/22 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.8.0/21 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.8.0/21 -j Firewall-2-DROP
-A Firewall-1-DROP -s 162.168.16.0/20 -j Firewall-2-DROP
-A Firewall-1-DROP -d 162.168.16.0/20 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.32.0/19 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.32.0/19 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.64.0/18 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.64.0/18 -j Firewall-2-DROP
-A Firewall-1-DROP -s 192.168.128.0/17 -j Firewall-2-DROP
-A Firewall-1-DROP -d 192.168.128.0/17 -j Firewall-2-DROP
-A Firewall-1-DROP -s 198.18.0.0/15 -j Firewall-2-DROP
-A Firewall-1-DROP -d 198.18.0.0/15 -j Firewall-2-DROP
-A Firewall-1-DROP -s 198.51.100.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -d 198.51.100.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -s 203.0.113.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -d 203.0.113.0/24 -j Firewall-2-DROP
-A Firewall-1-DROP -s 224.0.0.0/3 -j Firewall-2-DROP
-A Firewall-1-DROP -d 224.0.0.0/3 -j Firewall-2-DROP

The first set of lines blocks any incoming packets with fragments, new connections that aren’t SYN packets, and packets with invalid TCP connection flags. This will help to prevent syn flood attacks on your machine. The second set of lines blocks traffic coming from (-s) or going to (-d) addresses in the bogon list, which helps prevent spoof attacks. It is important to note here that if your machine is on a private network using non-routable IP addresses, then you must remove the lines from the list above that correspond to your LAN IP addresses. In the above example, traffic on the 192.168.0.x network is allowed, while all other traffic beginning with 192.168.x.x is blocked. We will continue using this network in the rest of the examples.

If any traffic is caught by these rules, it is then sent to the Firewall-2-DROP chain, which will log the packet then drop it. The Firewall-2-DROP chain will limit the amount of logging (to keep from filling our logs), and will also prefix the log so we know where the traffic was blocked. Below are the lines from the Firewall-2-DROP chain:

-A Firewall-2-DROP -m limit --limit 1/sec -j LOG --log-prefix "[INFW2] "
-A Firewall-2-DROP -j DROP

Finally, if the traffic has made it this far and hasn’t been accepted or dropped yet, we can move on to the accept chain.

-A Firewall-2-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A Firewall-2-INPUT -p icmp -m icmp -m limit -s 192.168.0.0/24 --icmp-type 8 --limit 1/sec -j ACCEPT
-A Firewall-2-INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 22,53,80,443
-A Firewall-2-INPUT -p tcp -m tcp -m multiport -s 192.168.0.0/24 -j ACCEPT --dports 5000:5999
-A Firewall-2-INPUT -p udp -m udp -m multiport -s 192.168.0.0/24 -j ACCEPT --dports 69,70,71

The first line will accept DNS lookup traffic from anyone (UDP port 53). If you don’t run a DNS server, you won’t need this line. The second line accepts icmp-type 8 traffic (ping request) from the local LAN. This means that your machine will respond to ping requests from clients on the LAN, but not from clients on the internet. The third line accepts TCP traffic on ports 22, 53, 80, and 443 (SSH, DNS, HTTP, and HTTPS respectively); again, if you’re not running these services then you don’t need these ports open. The fourth line accepts traffic on ports 5000-5999; this is just an example to show how to open a range of ports. The fifth line shows us accepting UDP traffic on ports 69, 70, and 71. And finally, the last line will log any traffic that has made it this far, again limiting the amount of logs written to keep from flooding the log files, and prefixing the log lines so we know where it came from.

We also must have the default rule for our input chain, to determine what happens when traffic makes it all the way to the end of our rule list. Here is our default input rule, to drop the traffic:

:INPUT DROP [0:0]

Hopefully this will help you to create a more advanced Linux firewall to fit your needs. Sometime in the future I will show you how to use your Linux box as a router, to handle NAT and routing with your firewall. For now, I’m going to go take a nap; it’s hard being a dogg!

Lets start with the iptables command. We can first flush the firewall table, so that we have a blank set of rules to start with.

[root@machine ~]# iptables -F

Next we can start adding some rules. First, lets create a rule to accept any traffic that is either already established, or traffic that is related to the established traffic.

[root@machine ~]# iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

The -I after our command means that we want to insert our rule. We can optionally insert it into a specific location, which we would specify after the name of the chain, but we want it at the top so we can omit the location number. The INPUT chain is our set of incoming firewall rules. Next we will specify that we want to match the state of the connection with the -m state flag, followed by the state we wish to match, using --state RELATED,ESTABLISHED. Finally we say that when these conditions are met, we will jump to another specific chain or target. We could make this traffic jump to another chain that can do some extra processing, or we can just jump to one of the predefined targets. In this case, we just jump to the ACCEPT chain, so that the traffic is accepted by the firewall, and further processing of the traffic (by iptables) is discontinued.

Next we will accept any traffic on the local interface, using the -i lo option. It’s worth mentioning that we want to process our traffic efficiently, and these first two rules will accept the majority of traffic that we will see. This will allow iptables to accept the traffic near the top of the INPUT chain, reducing the amount of processing necessary. We’ll append next rule to our current list of rules, by replacing the -I flag with the -A flag.

[root@machine ~]# iptables -A INPUT -i lo -j ACCEPT

Now we can actually start setting up some real rules to accept traffic from the outside. What we can do for our basic server now is to accept a few ports, so that we will have outside access. First, lets accept our SSH traffic with the following command:

[root@machine ~]# iptables -A INPUT -p tcp --dport 22 -j ACCEPT

The -p tcp flag says that we want to match the TCP protocol, and the --dport 22 tells the rule to accept traffic coming in with a destination of port 22. This rule will allow tcp connections to the SSH server on port 22. Next, let us accept two other ports.

[root@machine ~]# iptables -A INPUT -p tcp -m tcp -m multiport --dports 80,443 -j ACCEPT

Here we have accepted incoming traffic on TCP ports 80 and 443. Notice that we also needed the -m tcp flag, in order to match our rule for the -m multiport flag. We can also accept traffic from a specific source, providing an extra layer of security to protect any administrative ports.

[root@machine ~]# iptables -A INPUT -p tcp -s 192.168.1.50/32 --dport 10000 -j ACCEPT

This previous rule only accepts traffic on port 10000 if it has a source of 192.168.1.50/32. Notice the CIDR (Classes Inter-Domain Routing) notation. We can optionally specify a subnet to accept, with something like 192.168.1.0/24. We can also omit the CIDR subnet notation if we are only allowing access to a single IP address.

Finally, we can set the default rule for the INPUT table. This rule will be run on any traffic that hasn’t been matched by a previous rule in our chain. In this case, we want to drop any other traffic, so we only allow what we have explicitly specified. We should also drop any forwarded traffic, so nobody can try to relay traffic through us.

[root@machine ~]# iptables -P INPUT DROP
[root@machine ~]# iptables -P FORWARD DROP

Finally, we want to save our work, so that our rules are persistent on reboot. On Red Hat/Fedora/CentOS, we can run the following command:

[root@machine ~]# service iptables save

The nice thing about using the iptables command, is that we can add or remove commands on the fly, allowing us to write scripts which can modify our rules, blocking potential threats on the in real time during an attack.

We can also directly edit the /etc/sysconfig/iptables file, so we can more easily create a set of default rules. Lets take a quick look at the file, so open it in your favorite text editor. It should look something like this:

# Generated by iptables-save v1.3.5 on Tue Mar 29 22:19:16 2011
*raw
:PREROUTING ACCEPT [320:29801]
:OUTPUT ACCEPT [334:46325]
COMMIT
# Completed on Tue Mar 29 22:19:16 2011
# Generated by iptables-save v1.3.5 on Tue Mar 29 22:19:16 2011
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [2:120]
:OUTPUT ACCEPT [2:120]
COMMIT
# Completed on Tue Mar 29 22:19:16 2011
# Generated by iptables-save v1.3.5 on Tue Mar 29 22:19:16 2011
*mangle
:PREROUTING ACCEPT [320:29801]
:INPUT ACCEPT [320:29801]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [334:46325]
:POSTROUTING ACCEPT [334:46325]
COMMIT
# Completed on Tue Mar 29 22:19:16 2011
# Generated by iptables-save v1.3.5 on Tue Mar 29 22:19:16 2011
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports 80,443 -j ACCEPT
-A INPUT -p tcp -s 192.168.1.50/32 --dport 10000 -j ACCEPT
COMMIT
# Completed on Tue Mar 29 22:19:16 2011

The most important parts to notice are toward the end of the file. We can see by the :FORWARD DROP [0:0] and the :INPUT DROP [0:0] lines that we are dropping the FORWARD and INPUT traffic by default. There are also the lines for our specific rules, which process the traffic in the INPUT chain in the order that the rules are listed. In the future we will take a look at some more advanced firewall rules, along with blocking potential threats on the fly, and making iptables do some NAT!