Modern firewalls from major vendors, by default today, have a strict rule set that generally is fairly secure. Vendors are much more security aware than in previous years and products now thankfully reflect a more security conscious environment and internet. Various testing is still required to ensure the rules in place are operating as they should or to test and locate areas of improvement in configuration. Each TCP or UDP packet has four basic parts of information in the header in regards to routing:
source port : source ip | destination port : destination ip
Firewall rules are often setup to inspect packets and route them based on these source/destination indications in the packet headers. The problem with this is that the source ip or port can be altered to attempt to bypass a firewall if poor rules are in place. Firewall rules should be configured to process DENY rules first, followed by ACCEPT rules later to avoid many of these security issues in most cases.
A side note on tcpdump
Firewall testing generally involves two components: an active process or application sending requests and also a separate independent application recording down a packet capture of the event. With all of the examples below, it is recommended to run tcpdump or wireshark in a separate window to record the interaction and requests that result from the target firewall. [sourcecode] $ sudo tcpdump -i eth0 [/sourcecode] Running tcpdump tack i [interface] will provide a simple output in your terminal window. If it is more desirable to have this data written out to a file, use tack w. [sourcecode] $ sudo tcpdump -i eth0 -w myfile.cap [/sourcecode]
nmap
nmap is not only useful to gain some initial firewall assessments concerning open ports but to also do a few general firewall checks that require a quick inspection. In particular, a modern firewall should not be thrown off by a host fragmenting packets or using an alternate source port to allow traffic to pass through the firewall. [sourcecode] $ sudo nmap [target] [/sourcecode] Running nmap [target] by default with no options will only perform a TCP scan. Use -Pn if ICMP replies are blocked to skip the ICMP host discovery step of nmap. [sourcecode] $ sudo nmap example.com Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-24 18:22 EDT Nmap scan report for example.com (192.168.1.14) Host is up (0.12s latency). Not shown: 990 filtered ports PORT STATE SERVICE 25/tcp open smtp 80/tcp open http 110/tcp open pop3 143/tcp open imap 443/tcp open https 465/tcp open smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 5432/tcp open postgresql [/sourcecode]
SYN scan
[sourcecode] $ sudo nmap -sS [target] [/sourcecode] To perform a TCP SYN scan, use -sS. This is helpful for firewall that would generally block port scanners. A SYN scan only sends the initial TCP SYN packet creating what is known as a half-open connection. It is often perceived that this method causes less load or network stress on resources.
ACK scan
[sourcecode]$ sudo nmap -sA [target] [/sourcecode] TCP ACK scan can be useful as well. If allowed at the firewall, an ACK scan can report back if a port is being filtered or unfiltered. Generally, most modern firewalls filter such ACK requests. Below is the output from a firewall properly configured to filter this sort of probe: [sourcecode] $ sudo nmap -sA example.com Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-24 18:19 EDT Nmap scan report for example.com (192.168.1.12) Host is up (0.11s latency). rDNS record for 192.168.1.12: example.com All 1000 scanned ports on example.com (192.168.1.12) are filtered [/sourcecode] Compared to a firewall that is not filtering probes from an ACK scan: [sourcecode] $ sudo nmap -sA example.com Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-24 18:21 EDT Nmap scan report for example.com (192.168.1.12) Host is up (0.10s latency). rDNS record for 192.168.1.12: example.com Not shown: 996 filtered ports PORT STATE SERVICE 22/tcp unfiltered ssh 25/tcp unfiltered smtp 80/tcp unfiltered http 443/tcp unfiltered https [/sourcecode]
UDP scan
[sourcecode]$ sudo nmap -sU [target] [/sourcecode] To perform a UDP scan, use -sU. This must be done in addition to TCP scanning to inspect current open UDP ports of a firewall. Scanning for UDP ports is more problematic than scanning for TCP, due to the lack of any back and forth handshake response when sending UDP packets. Be aware that many false positives can occur when attempting UDP scans.
Additional nmap tips
Once general port assessment is achieved with nmap, a couple of other quick checks can be performed to test firewall rules. -f fragment packets [sourcecode]$ sudo nmap -f [target] [/sourcecode] Tack f in nmap is possible from Linux or BSD hosts only. This option is used to bypass firewalls; though, again, most all modern firewall vendors block these types of requests. Test that the firewall does not treat this traffic different than regular traffic. -g specify source port As mentioned, each packet has a source port as well as destination port, along with source ip and destination ip. It is possible to change the source port with a quick nmap test to test if firewall rules are configured to allow traffic according to particular source ports. Port 53 or 20 are often used as a testing source port. Many times this is used in combination of specifying the destination port to see if the traffic is allowed to pass through the firewall with a particular source/destination combo: [sourcecode]$ sudo nmap -g53 -p22 [target] [/sourcecode] Here is an example of a host that has port 22 TCP filtered at the firewall. Using a source port of 20 allow the traffic to bypass the firewall can be demonstrated as follows: [sourcecode] $ sudo nmap -sS -p22 -g20 192.168.1.16 Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-24 18:12 EDT Nmap scan report for 192.168.1.16 Host is up (0.057s latency). PORT STATE SERVICE 22/tcp filtered ssh [/sourcecode] Whereas, a typical port scan would not show the specified port visible: [sourcecode] $ sudo nmap 192.168.1.16 Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-24 18:14 EDT Nmap scan report for 192.168.1.16 Host is up (0.060s latency). Not shown: 998 filtered ports PORT STATE SERVICE 80/tcp closed http 443/tcp closed https [/sourcecode]
hping
hping is a tool for crafting TCP, UDP, or ICMP packets in a repetitive fashion much like the ping utility operates for ICMP packets. hping is useful to inspect if a particular port or packet is being filtered at the target firewall side or if a particular traffic type is being manipulated altogether. An example command with hping is: [sourcecode]$ sudo hping3 192.168.1.202 -p 22 -c 4 -V -S [/sourcecode] sudo hping3 [destination host] [port] [number of packets to transmit] [verbose] [-S for SYN] This above example is sending four TCP SYN packets on port 22 to the host. It is helpful while issuing hping commands to open up a second terminal and run tcpdump to record the session at the same time. An example of port 22 traffic being filtered looks similar to the following: [sourcecode] $ sudo hping3 example.com -p 22 -c 4 -V -S Password: using en1, addr: 172.16.1.101, MTU: 1500 HPING example.com (en1 192.168.1.12): S set, 40 headers + 0 data bytes — example.com hping statistic — 4 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms [/sourcecode] Whereas port 22 SYN packets accepted would appear similar to the following: [sourcecode] $ sudo hping3 example.com -p 22 -c 4 -V -S using en1, addr: 172.16.1.101, MTU: 1500 HPING example.com (en1 192.168.1.14): S set, 40 headers + 0 data bytes len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 sport=22 flags=SA seq=0 win=14600 rtt=94.4 ms seq=2025389860 ack=1382964684 sum=d336 urp=0 len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 sport=22 flags=SA seq=1 win=14600 rtt=114.5 ms seq=2231940279 ack=1895298182 sum=abbf urp=0 len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 sport=22 flags=SA seq=2 win=14600 rtt=97.0 ms seq=1994283418 ack=1525068590 sum=5b80 urp=0 len=44 ip=192.168.1.14 ttl=51 DF id=0 tos=0 iplen=44 sport=22 flags=SA seq=3 win=14600 rtt=95.3 ms seq=96473888 ack=1204458524 sum=216a urp=0 — example.com hping statistic — 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 94.4/100.3/114.5 ms [/sourcecode]
tcpreplay
tcpreplay is a suite of tools used by many firewall vendors to test their own firewall hardware. tcpreplay operates by replaying a previously recorded packet capture (.pcap format) against a particular target. The particular capture can be edited with tcprewrite and replayed to assist in testing particular hardware or TCP/IP stack for a given network traffic scenario. tcpreplay is not only used to simply replay edited captures for testing, but it is also used to test particular rates of the captured traffic as well against the device. To replay a particular packet capture via the specified, use the following command: [sourcecode]$ sudo tcpreplay –intf1=eth0 file.cap [/sourcecode] The rate of playback can be specified in mbps, for example: [sourcecode]$ sudo tcpreplay –mbps=100.0 –intf1=eth0 file.cap [/sourcecode] The counterpart of tcpreplay is tcprewrite. tcprewrite is used to modify the existing capture file which can then be replayed via tcpreplay. The syntax used for editing a packet capture file is: [sourcecode]$ tcprewrite [options] –infile=input.cap –outfile=output.cap [/sourcecode] Various options include rewriting tcp/udp ports, rewriting source/destination addresses, altering MTU, altering source/destination MAC addresses, as well as modifying ethernet checksums. More information can be found on the project page wiki (http://tcpreplay.synfin.net/wiki/tcprewrite).
Legacy tools
Other tools related that may be of interest are isic, which can test the stability of a TCP/IP stack: http://isic.sourceforge.net/. Tomahawk is useful to test the network throughput of network hardware: http://tomahawk.sourceforge.net/. Fragroute is useful to rewrite traffic aimed for a target host for TCP/IP scrubbing or other advanced testing http://www.monkey.org/~dugsong/fragroute/. Another older utility is ftester (http://dev.inversepath.com/ftester/README) which incorporates a packet generator along with a packet sniffer. Even though these tools are some years old, they are still valid today as the basic concepts of TCP/IP remain unchanged.
Conclusions
Firewalls, along with IDS setups, are very common in networks of all sizes. Using an IDS is optional but provides a level of comfort for many administrators in that the IDS will typically monitor traffic for malicious attempts as well as offer benefits such as DoS or rate-limiting prevention. Many network administrators and security administrators often setup hardware from vendors with no additional auditing or testing. On new deployments or with any changes to firewall rules, a full audit of the firewall or IDS should be performed to verify security using tools as in this guide as well as commercial tools. The firewall is the first point of contact to a network and should be considered a device that will be poked and tested 24×7 by potential hackers. Ensuring that proper configurations and rules are in place is critical for the entire network’s security.
