Firewall Howto

For Mandriva Linux 2009

March 2009

Herman Oosthuysen

General

A friend asked me: How do I enable a firewall?

The easiest way is of course to use the Mandriva Firewall Wizard - clickety-click, done. Oh, you want to do connection sharing as well with a Web Cache and parental controls too? Click the Internet Sharing Wizard and clickety-click, done again. There is nothing to it these days!

However, sometimes one needs something simple on a server or some dedicated machine and doesn't want to install the Shorewall package, so here is a super simple solution. I sometimes use this method to hook my little Eee PC netbook machine to a wireless router and then hook something else to the netbook ethernet port.

Basics

To do a firewall, you need at least two NICs of course. Most configurations will use eth0 as the WAN port and eth1 as the LAN port. This example follows this convention.

You may need to set the WAN MAC address to a specific value to keep your DSL supplier happy, in /etc/rc.d/rc.local. This forces the Linux server to use the MAC address of the network adaptor that was originally used to provision the DSL line:

# Configure the ADSL ethernet port with a specific HW address
service network stop
ifconfig eth1 hw ether 00:20:78:d9:c3:c8
service network start

Some DSL providers have an annoying system where, even if you have a server account with fixed IP addresses, still have to do periodic DHCP requests to keep the connection open - Telus for example. If you run your own DNS then this is particularly annoying, since every DHCP refresh will overwrite /etc/resolv.conf, so you may need to add some things to /etc/dhclient.conf. Here is mine:

# Configure dhclient for Telus
interface "eth0"
{
prepend domain-name-servers 127.0.0.1;
}

Multiple layers in the Onion

There are mainly two software packages involved with firewalling: IPtables and TCPwrappers. First of all deactivate TCPwrappers. In /etc/hosts.allow put the line:

ALL: ALL

for starters as the first rule to open tcpwrappers wide. You can close it up again later.

Simple Firewall

Some people still believe in creating overly complex firewalls, but the truth of the matter is that the Linux network stack is very well debugged and doesn't need a zoo of rules to protect it anymore. In fact, you can hook a Linux box to the Wild Wild Web directly with NO iptables rules and it will work perfectly fine.

So wait for, it! Drum roll!!! Here it is:

# Accept all traffic
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# General new connection rate limiting for DOS and Brute Force protection
iptables -I INPUT -p TCP -m state --state NEW -m limit --limit 30/minute --limit-burst 5 -j ACCEPT

# Configure a port for the other machine hooked to eth1
ifconfig eth1 192.168.1.254 netmask 255.255.255.0 up

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Create a NAT firewall
iptables -I FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

That is all there is to it - honest. It is better than most, since it uses a rate limit rule to protect against abuse.

Initial Tests

Connect to the wild wild world and use some pings to test the firewall. With Linux, you can specify which port to use to send the pings on. Test both ways, from LAN to WAN and WAN to LAN.

Now add some rules to hosts.allow, or just comment out the ALL: ALL:

# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#ALL: ALL
ALL: 192.168.10.
sshd: ALL
postfix: LOCAL 127.0.0.1 192.168.10.
mysqld: LOCAL 127.0.0.1 192.168.10.

Keep hosts.deny as:

# hosts.deny 
# This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
ALL:ALL

Final Test and Network Traffic Analysis

Test your firewall using nmap to see which ports are open:

# nmap -sT -P0 -v -F 111.222.333.444

Use the IP address of eth0 for the nmap command above.

Investigate the open ports and shut down services that are not needed, or block the ports with a DROP command. This script keeps my machines safe, but don't make any assumptions regarding security, since it is easy to verify yourself.

I usually create a little script called /usr/local/bin/drop to cut off an attacking host:

#! /bin/bash
# Drop all communications to/from an annoying host
iptables -I INPUT -s $1 -j DROP

and another little script called /usr/local/bin/block:

#! /bin/bash
# Drop all communications on an annoying port
iptables -I INPUT -i eth0 --dport $1 -j DROP

With those two scripts, one can quickly sew up holes in the net.

You can see which processes are doing what on the network using netstat:

# netstat -pa
# netstat -tlpn
# netstat -ulpn

To see name resolution, opening sockets, writing/reading sockets, use strace:

# strace -e trace=network curl --head http://www.redhat.com

or simply monitor network traffic with tcpdump:

# tcpdump -l -i eth0 port 80

once you know what port to look at.

Speed-ups

The next thing to configure would be squid, the http proxy, to buffer web requests. It readily reduces the bandwidth consumption by 30%. Also consider running BIND as a slave server, since it will speed up page accesses enormously - instead of waiting 250ms for each address to resolve, a local instance of BIND will do that in less than 1ms.

Intrusion Protection

On a public machine, intrusion protection is a big concern. There are a few simple steps that you can take to effectively protect the machine. First of all, always use very long usernames and passwords. This makes it unlikely that an automated brute force script will get in. I use descriptive user names, like john.doe.example.com with password j0hnd033x4mpl3c0m$1234. These kind of things are easy to remember and easy to type in.

With SSH, don't allow protocol 1 and don't allow root logins. This is set in /etc/ssh/sshd.conf. You should also consider not using the default port 22 for SSH (or FTP), but rather use something like 2222. That is still easy to remember and will throw automated attacks off, since most automated attacks are very dumb and an equally dumb defense could be very effective!

Rate limiting of new connection attempts is a general method to make brute force attacks infeasible and slow down denial of service attacks. The above firewall script has some protection in the INPUT rules. It will allow a burst of 5 new connection attempts, then limit at a rate of 1 per second. This will exhaust the patience of any common scr1pt k1dd13.

Finally, consider doing some active protection using Snort, Sentry Tools or Denyhost - all available from SourceForge.net. However, note that automatic denial of hosts could potentially cause you to lock yourself out, or an attack from the script called 'Fuck Port Sentry' could add the whole world to the deny list. I once left PortSentry running for a few months and then found that there were over 10,000 addresses in /etc/hosts.deny. Therefore, you need to add a process that will periodically clear the denied hosts.

Working on a Remote Server

Maintenance of a remote server deserves special mention. How do you safely make modifications to a remote server, without running the risk of locking yourself out?

The problem being that you can easily make a mistake and cause iptables to block all network traffic, with the result that your remote SSH or Webmin session dies. You then have to phone the Server Farm support desk with your tail between your legs and ask them to please go and fix it...

The solution is to create a safety net using the 'at' daemon. At allows you to enter a bunch of commands for later execution. This is very convenient for construction of a safety net. A simple safety, is to flush all iptables rules, then set the default policies to ACCEPT:

# at now + 20 min [Enter]
at> iptables -F
at> iptables -P INPUT ACCEPT
at> iptables -P OUTPUT ACCEPT
at> iptables -P FORWARD ACCEPT
at> [CTRL-D]
#

After entering the above, you have twenty minutes to fix the firewall and delete the at job, otherwise it will trigger and flush netfilter for you, so you can recover from your booboo.

You can see the queued jobs with 'atq' and remove a job with 'atrm jobnumber'.

As you can gather, I did lock myself out of a machine on the other side of the world once. Fortunately I had the foresight to talk to the server farm help desk before I started, so when I had to make the inevitable call for help, they could get me going again very quickly. However, the experience made me think how to prevent that from happening again and the at (or cron) daemon has saved me on numerous occations since!

Rate Limiting

Iptables nowadays has a very nice rate limit module which can prevent all kinds of abuse. This rule is also in the above firewall example:

# General new connection rate limiting for DOS and Brute Force protection
iptables -I INPUT -p TCP -m state --state NEW -m limit \
--limit 30/minute --limit -burst 5 -j ACCEPT

La voila!

Herman