Networking

Use Firewalk in Linux/UNIX to verify ACLs and check firewall rule sets

This tutorial shows how to use Firewalk to audit firewalls and routers to make sure they are filtering traffic correctly.


Access control lists represent an important first line of defense on most networks, since they are commonly used on routers to limit the protocols allowed to pass to host systems behind the router. Firewalk is an open source tool that will help you verify that your router ACLs are actually doing what you intended them to do. It can also be used as part of your security tool set for penetration testing and providing documented verification of ACLs, as well as rule sets on firewalls.

How it works
Firewalk attempts to determine which protocols a router or firewall will block and which they will pass on to downstream hosts. It operates on an IP expiry technique, much like the commonly used Traceroute program. The IP expiry technique involves manipulating the time to live (TTL) field of the IP header to map out all intermediate routers or hops between a scanning host and the target host. In Firewalk, scans are then sent with a TTL value one hop higher than that of the target host. If the scan packets are blocked by an ACL or firewall, they are dropped or rejected. If allowed to pass through, they will expire and elicit an ICMP time exceeded message. Based upon the results of the scans, Firewalk can identify which ports are open.

Installation
Firewalk is easily installed on any Linux/UNIX system (including Mac OS X). Firewalk relies on three back-end tools: libnet 1.1.x, lipcap, and libdnet. Start by downloading these tools, then unzip them with the "gunzip" command. Follow that with " ./configure", then "make" and finally "make install." After doing these command sequences for each of the backend tools, download Firewalk and do the same process for it.

Running Firewalk
Now that we're ready to run Firewalk, let's explore how it works. There are two phases of Firewalk. The first phase is basically a traceroute function called "hopcount ramping," and the second phase is the scanning or "firewalking" function. To see all the usage parameters, enter the "firewalk" command without supplying any of the host information. Here is what you will see.

Here's a brief explanation of the different options:

Option Default Explanation
-d 33434 Allows you to specify a different destination port for the ramping phase
-i off Allows you to specify a different interface
-n off Prevents DNS lookup—may increase speed
-p UDP Allows you to specify the scan protocol—can be TCP or UDP
-r off Enables strict RFC standards adherence
-S 1-130, 139, 1025 Allows you to specify a different port list for the scanning phase
-s 53 Allows you to specify a different source port for both phases
-T 2 Allows you to specify a different timeout for packet return
-t off Allows you to preload a TTL value to eliminate the ramping phase
-v N/A Shows the version of Firewalk
-x off Allows you to specify how many hops the binding host is from the target

To start firewalking, you must specify two hosts: the "target gateway," which is the router or firewall to be scanned, and the "metric." Normally we think of a metric as a number, but in this case, a metric is another gateway or host behind the target gateway.

Phase one—Hopcount ramping
Since the number of hops between the source host and the target host is not known, a standard Traceroute-style IP expiry scan is initiated. The TTL count is incremented at each hop until the target gateway is reached. At this point, the scan is "bound" to the current TTL plus one. Adding one more TTL allows the proceeding scans to go beyond the target gateway toward the metric host. The whole purpose of phase one is to find the TTL count for the target gateway.

Phase two—Firewalking
After reaching the target gateway and binding the scan to the proper TTL count, the actual scanning portion is started. Then either TCP or UDP packets are sent from the scanning host to the metric host one port at a time until the scan is completed. If a given probe is passed through the target gateway ACL, the scanning host receives an "ICMP TTL expired in transit" message from the binding host. If the scanning host receives no response after the timeout expires, it is assumed that the packet was denied by the ACL and was dropped.

Example scans
Figure A shows a diagram of the test network that we'll be using for two example scans.

Figure A


For our example, the target gateway is Router3 with the IP address of 192.168.100.2, and the metric is the host at IP address 192.168.200.10.

For demonstrative purposes, the first scan we'll do is without any ACL on the router. Then we'll apply an access list to the router, rerun our scan, and compare the firewalking results with our ACL. Note: Scan print outs have been shortened for brevity.

Scan 1—No ACL
We're going to run the following command:
[root@localhost local]# firewalk -s25� -d25 -pTCP 192.168.100.2 192.168.200.10

This will result in the following output:
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 25, destination port: 25
Hotfoot through 192.168.100.2 using 192.168.200.10 as a metric.
Ramping Phase:
�1 (TTL� 1): expired [192.168.1.1]
�2 (TTL� 2): expired [192.168.1.10]
�3 (TTL� 3): expired [192.168.100.2]
Binding host reached.
Scan bound at 4 hops.
Scanning Phase:
port�� 1: A! open (port not listen) [192.168.200.10]
port�� 2: A! open (port not listen) [192.168.200.10]
port�� 3: A! open (port not listen) [192.168.200.10]
port� 21: A! open (port listen) [192.168.200.10]
port� 22: A! open (port not listen) [192.168.200.10]
port� 23: A! open (port not listen) [192.168.200.10]
port� 24: A! open (port not listen) [192.168.200.10]
port� 25: A! open (port listen) [192.168.200.10]
port� 26: A! open (port not listen) [192.168.200.10]
port 139: A! open (port not listen) [192.168.200.10]
port 1025: A! open (port not listen) [192.168.200.10]

Scan completed successfully.

Total packets sent:��������������� 135
Total packet errors:�������������� 0
Total packets caught�������������� 148
Total packets caught of interest�� 135
Total ports scanned��������������� 132
Total ports open:����������������� 132
Total ports unknown:�������������� 0

Firewalk displays "A!" when it determines that the metric host is directly behind the target gateway. From this scan we see that all ports are open, but the server is only listening to ports 21 and 25.

Scan 2—ACL applied
On the target router, I've added an ACL that blocks outbound traffic except for TCP ports 25 (SMTP) and 23 (Telnet) on the interface for network 192.168.200.0. Here's the router configuration:
interface Ethernet0
�ip address 192.168.200.1 255.255.255.0
�ip access-group 101 out
�no ip directed-broadcast
access-list 101 permit icmp any any
access-list 101 permit tcp any any eq smtp
access-list 101 permit tcp any any eq telnet
access-list 101 deny any any

Here's what Firewalk reports when we run a scan:
[root@localhost root]# firewalk -pTCP 192.168.100.2 192.168.200.10
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 53, destination port: 33434
Hotfoot through 192.168.100.2 using 192.168.200.10 as a metric.
Ramping Phase:
�1 (TTL� 1): expired [192.168.1.1]
�2 (TTL� 2): expired [192.168.1.10]
�3 (TTL� 3): expired [192.168.100.2]
Binding host reached.
Scan bound at 4 hops.
Scanning Phase:
port� 21: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port� 22: *no response*
port� 23: A! open (port listen) [192.168.200.10]
port� 24: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port� 25: A! open (port listen) [192.168.200.10]
port� 26: *no response*
port� 27: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port 139: unknown (unreach ICMP_UNREACH_FILTER_PROHIB) [192.168.100.2]
port 1025: *no response*

Scan completed successfully.

Total packets sent:��������������� 135
Total packet errors:��������������0
Total packets caught�������������� 73
Total packets caught of interest�� 72
Total ports scanned��������������� 132
Total ports open:����������������� 2
Total ports unknown:�������������� 67


The two ports definitely open are 23 (Telnet) and 25 (SMTP). The ports reporting "no response" are basically invisible. This means that no response was received before timing out. We can assume that the packets were dropped, but as you can tell from this example, you need to run a variety of scans to really map an access list or firewall rule set.

Summary
This article provides an introductory look at the capabilities of Firewalk. This open source tool clearly warrants further study and usage, and undoubtedly has a viable place in the network security tool chest for auditing and documentation purposes. One thing to keep in mind is that this is a "noisy" application, meaning it's activity will be picked up by router and firewall logs as well as by any listening IDS, so be sure you have approval before scanning any routers or firewalls.

Editor's Picks