Find Openings in Firewalls with Firewalk in Linux/UNIX

firewallAccess 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, and then do it for firewalk.

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.

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.

Tagged , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Comments are closed.