Firewalking with nmap

Posted: March 30, 2013 in MemoToSelf
Tags: , , , , ,

uhh firewalking, what’s that?

To quote the original paper (1998):

A Traceroute-Like Analysis of IP Packet Responses to Determine Gateway Access Control Lists

Now that sounds pretty neat right or not if you usually only focus on open ports and ignore all other relevant information that a network scan can give you. The paper does a pretty good job of explaining the technique, so I’m not going to repeat that. Let’s just see if we understood it correctly by doing a manual test and then let’s see how we can use nmap to automate this. In case you are wondering why I don’t use the original Firewalking tool, it’s cause I prefer to not have a lot of fragmented tools unless I really need them. I mean nmap is a great tool and it just saves you a lot of time if you can just perform all (or as much as possible) of the network mapping with nmap.

Let’s setup a little lab which roughly looks like this:


So basically the attacker wants to enumerate the firewall rules that are in place on vyatta. As said, let’s start with grasping the concept of firewalking, by testing if we can proof the following configuration:

 default-action drop
 rule 100 {
     action accept
     destination {
         group {
             network-group !denied-segments
         port !445
     protocol tcp

The above configuration allows TCP to flow out on all addresses and ports except port 445 and the addresses defined in denied-segments. A simple nmap scan against will confirm this:

22/tcp   open     ssh            syn-ack
25/tcp   filtered smtp           no-response
80/tcp   open     http           syn-ack
135/tcp  filtered msrpc          no-response
139/tcp  filtered netbios-ssn    no-response
445/tcp  filtered microsoft-ds   no-response
514/tcp  filtered shell          no-response
593/tcp  filtered http-rpc-epmap no-response
9929/tcp open     nping-echo     syn-ack

hmmm does it really confirm the firewall configuration? Who has dropped the packets, our gateway? another gateway? or the machine? Let’s trace the path to with tcptraceroute:

sudo tcptraceroute 80
traceroute to (, 30 hops max, 60 byte packets
 1 (  0.203 ms  0.111 ms *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * ( <syn,ack>  175.587 ms  178.283 ms

Well, that didn’t result into much did it? For our purposes however we have more then enough information, in this case the amount of hops to our firewall. Which logically it being a lab setup is 1. Now let’s see how the nmap result looks like when perform the same port scan but with a TTL of 2:

22/tcp   filtered ssh            time-exceeded from
25/tcp   filtered smtp           time-exceeded from
80/tcp   filtered http           time-exceeded from
135/tcp  filtered msrpc          time-exceeded from
139/tcp  filtered netbios-ssn    time-exceeded from
445/tcp  filtered microsoft-ds   no-response
514/tcp  filtered shell          time-exceeded from
593/tcp  filtered http-rpc-epmap time-exceeded from
9929/tcp filtered nping-echo     time-exceeded from

Well that seems more like it doesn’t it? In this output you can see that all of the packets except the one for port 445 are forwarded beyond the firewall, but on the next hop the TTL expires and we are notified of it. This pretty much reflects the vyatta configuration at the start of this blog post. The IP belongs to the next hop, which in my case is another machine within the ESXI setup.

Thanks to bonsaiviking it’s this easy to perform firewalking with nmap. He recently added some code to handle ICMP Time Exceeded messages, after all the information was already there but nmap wasn’t using it.  If you want to play with this make sure you get nmap from the subversion repository. Naturally there are more ways to do this, let’s also look at the nmap firewalk script:

22/tcp   open     ssh
25/tcp   filtered smtp
80/tcp   open     http
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
514/tcp  filtered shell
593/tcp  filtered http-rpc-epmap
9929/tcp open     nping-echo

Host script results:
| firewalk: 
| 1     tcp       445

That’s some output that we love to see, it confirms that our firewall at hop 1 filters port 445.

One thing I learned during this whole playing around is that the “-d” (debug) option in nmap gives you a lot of good information. It’s how I first saw that nmap did see the ICMP Time Exceeded message but didn’t do anything with them in the normal port scan results. The debug output for a ICMP Time Exceeded packet looks like this:

RCVD (0.0918s) ICMP [ > TTL=0 during transit (type=11/code=0) ] IP [ver=4 ihl=5 tos=0x00 iplen=72 id=43011 foff=0 ttl=127 proto=1 csum=0xe93e]

Which looks almost the same as a manual hping3 test:

sudo hping3 -S --ttl 2 -p 80
HPING (eth0 S set, 40 headers + 0 data bytes
TTL 0 during transit from ip= name=UNKNOWN   
TTL 0 during transit from ip= name=UNKNOWN   
TTL 0 during transit from ip= name=UNKNOWN

Hope you enjoyed the article and can use it in real life situations, it helped me to identify some wrongly configured firewalls. It also helped me to tweak and optimize my scans.


  1. […] Firewalking with nmap: Firewalking with nmap | DiabloHorn AMol […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s