The Best Damn Firewall Book Period

Now that you understand what to look for, you can use the following tools to help you:

• Rule checkers Although Iptables does not support rule checking, the ipchains -C command allows you to check how your existing rule set operates. It will return information as to whether the packet is dropped or accepted. It is up to you to act on this information.

• Port scanners A simple port scan can help you determine which ports are left open on your firewall. Using applications such as Telnet and Netcat, you can then determine what daemon is listening behind that port.

• Packet generators Using applications such as SendIP, you can generate packets designed to test whether your firewall rules are working properly.

Following is a discussion of some tools that allow you to quickly test your firewall rules.

Ipchains

The ipchains -C option allows you to send packets to test whether the rules you have created work properly. Iptables does not have the equivalent, as of this writing. When checking Ipchains rules, you simply place -C (make sure you use the uppercase C) in front of the rule. The —check and -C options, by the way, are equivalent. You will be informed if the packet is blocked. For example, suppose you create the following rule in Ipchains:

ipchains -I input -i eth0 -s 0/0 -d 0/0 -p icmp -j DENY

To test this rule, you would issue the following command on the same system:

ipchains -C input -i eth0 -p icmp -s 0/0 1 -d 0/0 1

Ipchains will then inform you that the packet is denied. This tool is handy if you are logged in to the same system as you are testing, and you are becoming familiar with the existing rules and want to send out packets that test how the rules are working.

Telnet

More universal testing methods exist. The humble Telnet application is still useful when testing a firewall. Do not use it for logging on, however. You can use it to test whether a certain firewall rule is running the way you think it should. For example, suppose that you allow all access but that which is explicitly denied by a rule, and that you have configured the following firewall rule in Iptables:

iptables –A INPUT –i eth0 –s 0/0–p tcp --dport 80 –j LOG iptables –A INPUT –i eth0 –s 0/0–p tcp --dport 80 –j REJECT

You can use your Telnet client to see whether it is working properly by specifying the port you are blocking and logging:

prompt$ telnet firewall.yournetwork.com 80

You can then view the log by using the tail command to read the file where your system stores kernel messages. For the sake of convenience, use tail's –f option so that you can view results as they happen:

tail -f /var/log/messages

Using Multiple Terminals

If you have logged in to the firewall interactively, it is often useful to open two terminals. You can use the first terminal to issue the telnet command, and you can use the second terminal to view the results in the /var/log/messages file. Remember that if you specify more complex logging options, and then send too many packets, the kernel will stop logging traffic after a certain period of time (three logging instances an hour, with only the first five packets logged). If you do not remember this, you may make the mistake of thinking that a certain rule is not working, when in fact it really is.

Netcat

You are not limited to using Telnet. Netcat is a great tool for socket creations, especially for firewall testing, which is available at http://freshmeat.net/redir/netcat/7041/url_tgz/nc110.tgz. Netcat is quite versatile, and is the self-described "Network Swiss Army Knife." Hackers and systems administrators alike use it as a tool to conduct scans, communicate with open ports, and even transfer information between hosts. Because it is so versatile, it can also be used against you, so if possible, you should install this application only on a client system, rather than on the router. This is because it can be used to open a back door on your system. Still, careful use of the application can allow you to quickly audit your firewall.

Used in the simplest way, Netcat is much like a Telnet client, because it can be used to access any remote host at any port. To connect to the host named firewall.yournetwork.com at port 80, you would issue the following command:

./nc firewall.yournetwork.com 80

You will then have to press Ctrl-c to exit the program. If the port is open, you can then enter any command you want. As far as port 80 is concerned, you can just enter some gibberish once a connection is made, and the Web server will return an error message, which usually includes the name of the Web server. Chances are, the port will not recognize your command, but for the purposes of testing a firewall, you usually want to just see if a port is open and listening. The netcat -h command provides a list of all available options, which are listed in Table 6.1 for your reference.

Sample Netcat Commands

To use Netcat in a more sophisticated and helpful way, you must use the following syntax:

nc [-options] hostname port[s] [ports]

For example, if you want to scan ports 1 through 1023 of your firewall and ensure that Netcat will not "hang" at any ports, you could issue the following command:

./nc –z –w 2 –v –v firewall.yournetwork.com 1-1023

The -z and -w 2 options tell Netcat to not bind a port, and to wait only two seconds in case a connection is accidentally made. The two -v options place Netcat into ultra verbose mode. It is likely, though, that only certain groups of ports will be open on an unsecured firewall. For example, the following command scans only certain ports and groups of ports:

./nc –z –w 2 –v –v firewall.yournetwork.com 20-30, 53, 80, 100-112, 443, 6000-6050

Analysis of Netcat Scan

The preceding scan searches for ports associated with several protocols, including:

• FTP (20 and 21)

• SSH (22)

• Telnet (23)

• DNS (53)

• WWW (both 80 and 443)

• X (ports in the 6000 range)

Figure 6.1 shows the results of a scan against a router that has left several ports open.

Figure 6.1: Scanning an Open Router

This firewall, for example, still allows connections to Simple Mail Transfer Protocol (SMTP), the sunrpc portmapper service (port 111), and X. You can, of course, specify additional ports. For example, the ranges of 20 through 00 and 5900 through 7000 can reveal commonly used ports. Consult your /etc/services file for more ideas.

Additional Netcat Commands

When compiled properly, Netcat can also spoof IP addresses. If you want to spoof the source IP address, you would use the -s option:

./nc -s 10.100.100.1 –z –w 2 –v –v firewall.yournetwork.com 20-30, 53, 80, 100-112, 443, 6000-6050

However, you should note that the -s option does not work well on some operating systems. Because Netcat defaults to TCP, you can use the –u option to send a UDP packet to a port:

UDP Scans

./nc –u –w 2 firewall.yournetwork.com 80, 443

You will have to press Enter twice to finish the command. Depending on the rules you have set (you will have to explicitly log UDP using either the –l option in Ipchains or the –j LOG target in Iptables), your firewall will log this traffic.

Testing Source Ports

If you have set a firewall rule to deny a particular source port, you can test it with Netcat. For example, if you have prohibited all hosts from accessing ports 1 through 1023 of an interface, you can test this by issuing the following command:

./nc -p 80 –w 2 –v –v firewall.yournetwork.com 1-1023

Testing DNS Connectivity

Many times, you will want to allow UDP and TCP access from and to port 53, in case a domain zone transfer needs to be made. To test whether this port is open, you would issue the following commands:

./nc -p 53 –w 2 –v –v firewall.yournetwork.com 53 ./nc –u -p 53 –w 2 –v –v firewall.yournetwork.com 53

You can also scan a range of ports using Netcat. If, for example, you wanted to scan ports 1 through 1023, you would issue the following command:

./nc firewall firewall.yournetwork.com 1-1023

Additional Netcat Features

If you want to have Netcat open a shell and listen for inbound connections (this is definitely not recommended in most circumstances), you would use the following syntax:

nc -l -p port [-options] [hostname] [port]

In addition, Netcat ships with several scripts and applications. Some of these are geared toward the hacker community, while others offer quick solutions to common problems. Most of them are less practical than they are interesting. For example, if you want to test port redirection, you can use the webproxy and webrelay applications found in the scripts directory.

You can learn more about using Netcat in this way by reading the README file that comes with the source code. For those who are truly curious about using Netcat to open listening connections, a patch exists that allows you to authenticate and encrypt traffic that streams between versions of Netcat running on opposite servers. Called aes-netcat, you can download it from packetstorm.security.com and other sites.

Using Netcat

1. Create a new directory named netcat and change into it. This step is necessary, because the tarball will deposit many different files into the destination directory.

2. Obtain Netcat version 1.10 from http://freshmeat.net/redir/netcat/7041/url_tgz/nc110.tgz.

3. Once you have obtained Netcat and saved it to the netcat directory, untar and unzip it:

   tar –zxvf nc110.tgz

4. Most versions of Linux do well with the following compile option:

   make generic

   However, you may want to read the file named Makefile and see if your operating system is specifically listed.

5. Once you have compiled Netcat, the nc binary will be created in the present directory. Copy it to the /bin/ directory. Or, if you prefer, you can just leave it in the present directory and use ./ in front of the command while it is in the same directory. Now that Netcat is ready to be used, create several firewall rules that log port scans.

6. Open a terminal on your firewall and view the /var/log/messages file:

   tail –f /var/log/messages

7. Now, conduct a sample portscan against your firewall:

   ./nc–w 2 –v –v firewall 1-1023

You can now use Netcat to conduct tests against your firewall.

SendIP: The Packet Forger

Although Netcat does have the ability to create some packets in certain instances, it is not a true packet generator. SendIP is designed to allow you to create packets of your own choosing. This practice is often called "arbitrary packet generation." SendIP allows you to create your own IP, Internet Control Message Protocol (ICMP), TCP, and UDP packets. For example, you can generate TCP packets with the FIN, ACK, and SYN bits set according to your testing needs. You can obtain SendIP from several sites, including www.earth.li/projectpurple/progs/sendip.html.

SendIP Syntax

Although there are many options, SendIP syntax is relatively straightforward:

sendip [hostname] -p <type> -d <data> <options>

SendIP Options

The -p option specifies the protocol you want to generate, and the -d option allows you to enter a random text string. The options, many of which are listed in Table 6.2, allow you to customize the contents of the packets you generate.

The SendIP man page contains additional options. As you can see, SendIP allows you to forge any part of a TCP session, as well as any element of an IP, UDP, or ICMP packet. SendIP also allows you to forge all elements of IPv6 addresses, and also allows you to forge Routing Information Protocol (RIP) packets.

This tool is useful in regard to firewalls because it allows you to simulate any situation. The ipchains -C command has similar functionality. However, you can install SendIP anywhere, whereas many newer kernels do not support Ipchains. Besides, using SendIP, you can spend your time learning only one application.

Using SendIP to Probe a Firewall

1. The source files do not differ from the RPM. Download SendIP RPM from www.earth.li/projectpurple/progs/sendip.html.

2. As root, type the following:

   rpm -ivh sendip-1.5-1.i386.rpm

3. Now that you have installed SendIP on this system, it will be known as the "attacking host." You are now going to use SendIP on this attacking host to check your firewall's ability to block spoofed packets coming in from the outside interface. To check your firewall's configuration, set up a machine outside of your firewall, and then give your firewall's IP address as the default gateway.

4. Suppose that you have only the internal networks of 192.168.2.0/24 and 10.100.100.0/24, and a simple Linux client using the IP address of 192.168.2.37. You want to test your firewall to see if spoofed traffic from outside the network can get through your firewall to your Linux client. To test this, configure a system on your internal network (say, with the IP address of 192.168.2.37) to use a packet sniffer such as Tcpdump or Ethereal to view all packets on the 192.168.2.0 network. This will be the internal host.

5. Put the NIC of the internal host into promiscuous mode so that it can capture the spoofed packet you are about to send. Hopefully, the spoofed packet won't get through.

6. Issue the following command from the attacking host to the internal host:

   sendip 192.168.2.37 -p icmp -is 192.168.2.36

7. You have just issued a spoofing attack against your firewall and internal network. Now, stop your capture of packets on your internal host. Were you able to see an echo request from 192.168.2.36? Did the 192.168.2.37 system issue an echo reply? Did you see any DNS traffic that appears to be an attempt to resolve the 192.168.2.37 IP address? If you did, then review your spoofing rules. If you did not, chances are that you have properly configured anti-spoofing on your firewall.

   Remember, if you are on a switched network, you will have to configure a packet sniffer on the victim host, and then ping that victim host directly. This is because a switched network does not use broadcasting as does a standard hub-based network.

8. If you have enabled logging for such packets, use the tail -f command on your firewall to see if the kernel records capturing the packet.

9. Now, try spoofing with another protocol:

   sendip 192.168.2.37 -p tcp -ts 2 -td 80 -tn -is 192.168.2.36

   This command sends a tcp packet with the source port of 2 to the 192.168.2.37 host at port 80. Your firewall should block this packet, because it should not allow packets to privileged ports (ports below 1023) to go into the internal network.

10. When you are reasonably sure that your firewall is blocking spoofed packets, issue the following command from your attacking host:

    sendip 192.168.2.37 -p tcp -ts 2 -td 80 -tn -is 45.2.5.6

11. This command does much the same thing, but instead, it creates a packet that has a stronger chance of passing through your firewall. Why? Because this packet apparently originates from the 45.2.5.6 host, which is an IP address that could plausibly originate from the Internet. In addition, at least for the purposes of this exercise, this address does not exist inside your network. However, this packet should not be passed through, either, because it originates from a privileged port and is directed at a privileged port (80) on the destination. Finally, issue the following command:

    sendip 192.168.2.37 -p tcp -ta 1 -ts 4356 -td 6450 -tn -is 45.2.5.6

12. Depending on your firewall configuration, this packet may be allowed to pass through. This is because the ACK bit has been set using the -ta option. As a result, the firewall rules may allow it through because it is part of an already-established session. In addition, notice that the source and destination ports are ephemeral, and not well known (below 1023). Consider using additional commands to further test your firewall. Make the necessary changes, without affecting the services that you want to provide.