Testing Your Firewall
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.
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.
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 22.214.171.124 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-10-01 07:11 = EST Interesting ports on 126.96.36.199: (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 http://188.8.131.52 and hit a web page. Lynx (or its cousins links and elinks, or w3m) is good over ssh:
user@remotehost:~$ lynx 184.108.40.206
You cannot tell if the web server is on 220.127.116.11, 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.
In this tutorial:
- Building a Linux Firewall
- Iptables and NAT, SNAT, and DNAT
- Assembling a Linux Firewall Box
- Configuring Network Interface Cards on Debian
- Configuring Network Interface Cards on Fedora
- Identifying Which NIC Is Which
- Building an Internet-Connection Sharing Firewall on a Dynamic WAN IP Address
- Building an Internet-Connection Sharing Firewall on a Static WAN IP Address
- Displaying the Status of Your Firewall
- Turning an iptables Firewall Off
- Starting iptables at Boot, and Manually Bringing Your Firewall Up and Down
- Testing Your Firewall
- Configuring the Firewall for Remote SSH Administration
- Allowing Remote SSH Through a NAT Firewall
- Multiple SSH Host Keys Past NAT
- Running Public Services on Private IP Addresses
- Setting Up a Single-Host Firewall
- Setting Up a Server Firewall
- Configuring iptables Logging
- Writing Egress Rules