上QQ阅读APP看书，第一时间看更新

Firewall reconnaissance with Firewalk

Firewalk is an active reconnaissance network scanner that will help determine what Layer 4 protocols our router or firewall will pass or deny. This is a great tool for finding a way through an environment by leveraging a bad or missing ACL within one of your network devices. Firewalk leverages ICMP error messages and TTL expirations to let us know whether a port is open or not, very similar to traceroute. If a port is opened or allowed, the packet destined for that port will typically be silently dropped by the security device. But, if the port is closed, the TTL of the packet will expire at the next hop and issue an ICMP_TIME_EXCEEDED error message.

Firewalk is a two-phase command. The first phase is called the hop ramping phase. Its sole job is to find the correct hop count to the target gateway so that is has the right TTL (hop count + 1) to lock onto for the next phase. The second phase involves starting at that point and doing a port scan with the ports we specify from the options on the CLI to that metric host.

When using firewalk for the first time, the arguments can be a little confusing. Here is the screen output of the command:

There are not a large number of options compared to other tools such as Nmap, which is a good thing. Technically, we only need to specify target_gateway and metric for Firewalk to work. The target_gateway refers to the IP address of the gateway/firewall/security device I want to check ACL or access against. The metric just refers to an IP address that is somewhere behind or after that target_gateway address. This IP address doesn't even need to be within the next hop of that target_gateway, or reachable, or even in the next network. That IP address has only one job and that is to have Firewalk attempt to send traffic to it to verify that target_gateway allows the packet through it. It will technically never reach it, as the TTL will expire at the next hop, and therefore, elicit ICMP_TIME_EXCEEDED.

Here are some examples on how I utilize the firewalk command to check for a couple of well-known ports going to our target 192.168.30.250. The host that we are trying to get some reconnaissance on is host 192.168.1.1, which happens to be a security device. In the CLI command, we specified a source and destination port as well as a port range using the -S switch.

In the following output, you will see the two phases in action. In the first phase, you will see hopramping by seeing the first TTL expire. In this example, that first hop was 192.168.1.1. At the next hop, the first phase is now bound, so the second phase can start. With the second phase, those well-known ports we specified against the CLI are now being tested. The results show that ports 22 (ssh) and 5900 (VNC) are open. We can use this information, gleaned from the Firewalk test, for future pen testing use.

It is important to note that some security devices will not decrement the TTL. If this is the case, we may not get a hop count on that device or the test may even fail since Firewalk thinks it is on the same network. If so, you will see an error message that the metric responded before the target.

If testing this internally, you may have the option to turn that feature off on some firewalls if you so desire:

Because part of what we want to teach you is how to interpret results, we also want to show what would have happened if that device had an ACL on it to see how the output would change. In the following example, I put an ACL on port TCP 5900 to show us just that. With this new ACL, the output shows Firewalk has no response now versus the open and port listening. This is a clear indication that there is a security device inline that is dropping that port:

Utilizing Wireshark, you can verify what firewalk is actually doing. Here, we can drill into the Layer 3 and 4 information in the packet, and see the TTL being set to 2: