3.10. Testing Your Firewall

Problem

You want to be able to test your Linux firewall from inside your LAN and outside it so you can see your network from both sides of your firewall. You especially want to see your network the same way the big bad outside world sees it. What are some good ways to do this?

Solution

Simply network with a second PC and run your tests. Assume your firewall box is named firewall, with a WAN IP address of 172.16.0.10, and your PC is called testpc at 192.168.2.10. Connect testpc to the WAN port of firewall with a crossover cable. Then, give them temporary IP addresses and routes to each other:

	root@testpc:~# ifconfig eth0 192.168.2.10 netmask 255.255.255.0 up
	root@firewall:~# ifconfig eth0 172.16.0.10 netmask 255.255.255.0 up
	root@testpc:~# route del default
	root@testpc:~# route add -net 172.16.0.0/24 gw 192.168.2.10 eth0
	root@firewall:~# route del default
	root@firewall:~# route add -net 192.168.2.0/24 gw 172.16.0.10 eth0

Run ping to confirm connectivity.

Here are some quick tests you can run for debugging your new Linux firewall. These commands, run on firewall, show your active iptables rules:

	# /sbin/iptables -t filter -L -v --line-numbers
	# /sbin/iptables -t nat -L -v --line-numbers
	# /sbin/iptables -t mangle -L -v --line-numbers

Nmap is an excellent tool for seeing what your firewall looks like from the outside:

	root@testpc:~# nmap 172.16.0.10
	root@testpc:~# nmap -P0 172.16.0.10

Run netstat on firewall to see what sockets are open and listening for new connections:

	root@firewall:~# netstat -untap

This shows the listening interfaces and port numbers, the program names, and user IDs. The safe thing to do is turn off all services until you are satisfied with your firewall. Then, bring them back up one at a time, testing your rules until everything works right. You really shouldn't be running a lot of services on a firewall anyway— keep it lean and mean.

For more extensive network testing and debugging, see Chapter 19.

Discussion

To get completely outside of your network, get a shell account on a PC on a different network. The remote PC needs to be equipped with Nmap, ping, traceroute, and text web browsers. If you can't do this, the next best thing is a dial-up Internet account, because this still gets you outside of your local network.

My own preference is to use remote shell accounts kindly provided by friends for external testing, because this is more like a "live fire" exercise, with all the complications that come with connecting over the Internet.

Here are some sample command outputs from testing an iptables NAT firewall. This Nmap command run from a remote PC to the WAN IP address shows that iptables is blocking all inbound connections except port 80, and that the web server is up and accepting connections:

	user@remotehost:~$ nmap 1.2.3.4
	Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-10-01 07:11 = EST
	Interesting ports on 1.2.3.4: (The 1662 ports scanned but not shown below are in
	state: filtered)
	PORT STATE SERVICE 
	80/tcp open http

According to Nmap, you should be able to point a web browser to 1.2.3.4" and hit a web page. Lynx (or its cousins links and elinks, or w3m) is good over ssh:

	user@remotehost:~$ lynx 1.2.3.4

You cannot tell if the web server is on 1.2.3.4, or is sitting on a separate box somewhere behind the firewall, because to the world, a NAT-ed LAN looks like a single computer. If you do not want to run a web server, this shows you better hunt it down and turn it off.

Running Nmap from a neighboring LAN host on the LAN address shows a different picture:

	user@lanhost:~# nmap 192.168.1.10
	Starting nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2007-10-01 13:51 =
	PST
	Interesting ports on 192.168.1.10:
	(The 1657 ports scanned but not shown below are in state: filtered)
	PORT    STATE  SERVICE
	22/tcp  open ssh
	631/tcp open ipp
	MAC Address: 00:01:02:03:04:05 (The Linksys Group)
	Nmap finished: 1 IP address (1 host up) scanned in 22.645 seconds

So now we see that the SSH daemon and CUPS are running on the firewall. (Look in /etc/services to see which services are assigned to which ports.) Port 80 is not open, so this means the web server is on a different computer. If we run netstat on the firewall itself, we can see which ports are open, and which interfaces they are listening to:

	admin@firewall:~# netstat -untap
	Active Internet connections (servers and established)
	Proto Recv-Q Send-Q Local Address Foreign Address  State User   Inode
	PID/Program name
	tcp   0  0 192.168.1.10:22  0.0.0.0:*   LISTEN     0  44420       12544/sshd
	tcp   0  0 0.0.0.0:631     0.0.0.0:*   LISTEN     0  142680   22085/cupsd

So we see that the SSH daemon is listening to the LAN IP address on TCP port 22, and the CUPS daemon is listening on all interfaces on TCP 631. TCP port 80 is not open because it is on a different machine.

Now we have a good picture of what is happening on both sides of our firewall.

The netstat output illustrates an important point—application security is separate from the border security provided by a firewall. The SSH server has been configured to listen only to the LAN IP address, but cupsd is listening to all interfaces. Nmap showed us that the firewall is blocking both of those at the WAN interface. Don't feel too safe with just a firewall; the best practice is to use border and application-level security. iptables can keep the bad bits out, but if someone succeeds in penetrating your firewall, you don't want them to find a wide-open welcome into your servers.

All Linux services have access controls, and most of them also incorporate various types of authentication controls. This example from /etc/ssh/sshd_config shows how interface access controls are configured:

	# What ports, IPs and protocols we listen for
	Port 22
	# Use these options to restrict which interfaces/protocols
	# sshd will bind to
	ListenAddress 192.168.1.10

OpenSSH also restricts access by host, user, and domain, and gives the choice of several different types of authentication. Security is a many-layered beast—don't rely on a firewall to be your entire security.

See Also