Today, we’re going to be running through a Firewalk tutorial using Kali Linux. But first, we need to understand what Firewalk does and why it’s important for hackers and penetration testers. Basically, Firewalk is a penetration tool that can be used for reconnaissance by helping a pentration tester or hacker discover what IP protocols are permitted through a network device. The network device in question could be almost anything, including (but certainly not limited to) a home wireless router, an enterprise-class router, or just about anything with a hardware or software firewall.
Naturally, I’m sure you see the value in being able to poke and prod firewalls with a reconnaissance tool to see what can get through. It works by sending TCP and UDP packets using the specified protocol and port number, but it has a TTL (Time To Live) value one hop further than the device in question. For instance, if I was testing a firewall that was 3 hops away, the TTL of the packets would be set to 4.
As a side note, understand that TTL is the number of hops a packet can be forwarded by computers and networking devices before they are discarded. Each time a packet travels through a device, such as a router, the TTL value is decremented by 1. The TTL mechanism helps prevent looping flaws in the TCP/IP model and a whole range of attacks. Many of these flaws (which are similar to broadcast storms) are outside the scope of this guide, but know that there are some strange looping errors that essentially allow immortal packets to multiply and completely break an entire network. The TTL value thwarts these issues. While the maximum TTL value is 255, most operating systems use a value much smaller than that (usually in the 32-64 hop range).
Anyway, the goal is to receive an ICMP message. As you may know, ICMP (Internet Control Messaging Protocol) facilitates pings with the echo-request and echo-reply operations. However, today we’re more interested in the ICMP_TIME_EXCEEDED message. You see, we will only receive this message if the device we’re testing (such as a firewall) permits the traffic, and then the packets exceed their TTL value on the other side of the firewall and die. On the other hand, we’ll know if a firewall blocked the traffic type we’re testing if we don’t receive any message at all.
Identifying Network Devices
At this point, you might be wondering how on Earth we’re supposed to know if a router or firewall is in our path to the Internet. First of all, one of them has to be in your path if your accessing the public Internet from a private network. Regardless, you may want to test various networking devices on your local network. Consider a hacker or penetration tester who has access to a corporate network.
The first stage of testing would likely involve putting out ‘feelers’ to sense other devices on the network. For instance, it’s likely that a hacker or penetration tester would use various types of scanners to identify other active hosts. Perhaps they would then use NMAP to locate other devices and see what type of device they are. There is one major difference between using NMAP as a portscanner and Firewalk, however.
The distinction is extremely important, so take notes. When using a portscanner like NMAP, you are testing to see which services are running on an individual host or subnet. For instance, I can see if host 192.168.1.254 is accepting connections on ports 20 and 21, which would indicate an FTP service is running.
However, when using Firewalk, you’re really testing to see what traffic can pass through a device; not what ports are actually open on the device in question. As such, it is a much more useful tool than NMAP for testing firewalls.
Also, in some cases, it may not be necessary to use NMAP to identify devices. Furthermore, note that the final destination doesn’t even need to be reached, since the ultimate goal of this tool is simply to see if an individual protocol will be forwarded by a networking device. If you wanted to, you could simply run a traceroute to see a list of all the layer 3 forwarding devices between you and the ultimate destination.
What Are Layer 4 Protocols, and Why Do They Matter to Penetration Testers?
I would hope that, as I.T. and network engineers who want to become hackers and penetrations testers, that you already have a firm grasp on the OSI model. If you don’t, go ahead and take the time to research it a bit, since we can’t get into it today as it is far outside the scope of this guide an immensely complex.
Nevertheless, I would like to draw your attention to layer 4 of the OSI model. I mentioned already that Firewalk tests to see which layer 4 protocols can pass through a networking device, such as a firewall. So…what about all the higher level protocols? Remember that layer 4 of the OSI model is the Transport layer, and includes popular transport protocols such as TCP, UDP, IPX/SPX, Fiber Channel, RTP, and SCTP.
Naturally, TCP and UDP are the most popular and widely used layer 4 protocols. Nevertheless, I would like to point out that Firewalk does have tools and mechanisms to set different flags within the IP header, so you can test higher level protocols. That is, it won’t only check whether a layer 4 protocol (such as TCP) is forwarded, but rather how TCP is forwarded and what different types of TCP data are permitted.
So, naturally, you can test individual ports or entire ranges of ports. This allows you to poke the firewall and see what common services are blocked and which are permitted, such as HTTP, HTTPS, FTP, TFTP, DNS, SSH, TelNET, and any other service you can think of.
Firewalk Syntax and Options
Firewalk has a fairly basic command structure as follows:
firewalk [options] firewall_or_device_address metric
Furthermore, the options you can append to the command are as follows:
-d 1-65535 (34434) – This value indicates the initial destination port during the ramping phase, when Firewalk is trying to determine what value to set for the TTL.
-h – View the help screen.
-i interface_name – Specifies which interface to run Firewalk on. However, if you only have one active interface, you don’t need to supply this information.
-n – Tells Firewalk to not resolve hostnames to IP addresses using DNS. Doing so can drastically speed up a scan by circumventing length DNS timeouts.
-P 1-2000 (0) – Builds a ‘pause’ into the scanning phase, which is good because it prevents the scan from flooding the network and drawing too much attention to yourself – which is critical for hackers to maintain a low profile.
-p TCP, UDP (UDP) – Specifies which protocol you would like to test.
-r – RFC 793 support. This flag is actually quite complicated, and a lot happens in the background during the scan, so we will disregard this option for today. You are, of course, encouraged to research it further, but just know that it deals with the inner working of SYNs/ACKs.
-S 1-65535 – This option helps you to specify multiple ports in a single scan so you don’t have to run tens, or even hundreds of scans to test all the necessary ports. You can enter in lists or ranges of ports. Ranges are separated by dashes while lists of ports are delimited by commas.
-s 1-65535 (53) – This value specifies the source port for the scan.
-T 1-2000 (2) – This sets the timeout value for the packet read. Setting this to a lower value can speed up the scanning procedure, because it determines how long Firewalk waits before timing out.
-t 1-25 (1) – This value indicates the initial TTL. You can set a TTL value instead of needing to run through the ramping phase if you already know how many hops away your target is.
-v – Dumps program version and exit.
-x expire vector (1) – The expire vector is the number of hops that the scanning probes will expire, past the gateway host. The binding hop count is the hop count of the gateway + the expire vector.
So now we understand what Firewalk is, what it does, and how it works. It’s finally time to look at a n example of the syntax to see how we can poke and prod a firewall to see what traffic is permitted and which traffic is blocked. Consider the following example:
firewalk -S1-53 -i eth0 -n -pTCP 10.10.1.1 10.10.0.1
I know that when we put it all together, it can look a little intimidating. So, let’s run through exactly what this command does one option at a time. First of all, note that this operation is going to scan to see if ports 1-53 are permitted through the host’s interface with the address 10.10.1.1. In our example, 10.10.1.1 is the device that is being scanned, such as a firewall.
Also, note that the command specifies TCP traffic. And lastly, we want to check if the host 10.10.0.1 has the ability to send the traffic (on ports 1-53) through the firewall. If you want to check what common ports are available in a new environment, you would simply specifiy your port range (perhaps 1-1024, since these are well-known ports), and set the last IP address to one within your subnet.
Firewalk is a tremendously useful information gathering tool that will take a lot of the guesswork out of wondering whether or not your traffic is hitting the correct target or server. For instance, if you wanted to use Dotdotpwn to fuzz an HTTP server but kept receiving errors or timeouts, it could be because a firewall or router is blocking your traffic. You could simply use Firewalk to verify whether or not that data is permitted through the networking device.
Lastly, from a penetration testing perspective, this tool is incredibly useful for validation and verification. For instance, corporations frequently impose firewall policies regarding what traffic types shouldn’t be allowed through. This tool will help double check that the firewall rules are configured appropriately.