- A+
[先直接复制了，回头细看]
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 scanme.nmap.org will confirm this:
PORT STATE SERVICE REASON 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 scanme.nmap.org machine? Let’s trace the path to scanme.nmap.org with tcptraceroute:
sudo tcptraceroute scanme.nmap.org 80 traceroute to scanme.nmap.org (74.207.244.221), 30 hops max, 60 byte packets 1 10.100.0.1 (10.100.0.1) 0.203 ms 0.111 ms * 2 * * * 3 * * * 4 * * * 5 * * * 6 * scanme.nmap.org (74.207.244.221) <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:
PORT STATE SERVICE REASON 22/tcp filtered ssh time-exceeded from 192.168.223.2 25/tcp filtered smtp time-exceeded from 192.168.223.2 80/tcp filtered http time-exceeded from 192.168.223.2 135/tcp filtered msrpc time-exceeded from 192.168.223.2 139/tcp filtered netbios-ssn time-exceeded from 192.168.223.2 445/tcp filtered microsoft-ds no-response 514/tcp filtered shell time-exceeded from 192.168.223.2 593/tcp filtered http-rpc-epmap time-exceeded from 192.168.223.2 9929/tcp filtered nping-echo time-exceeded from 192.168.223.2
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 192.168.223.2 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:
PORT STATE SERVICE 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: | HOP HOST PROTOCOL BLOCKED PORTS | 1 10.100.0.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 [192.168.223.2 > 10.100.0.100 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 scanme.nmap.org -p 80 HPING scanme.nmap.org (eth0 74.207.244.221): S set, 40 headers + 0 data bytes TTL 0 during transit from ip=192.168.223.2 name=UNKNOWN TTL 0 during transit from ip=192.168.223.2 name=UNKNOWN TTL 0 during transit from ip=192.168.223.2 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.
Resources
-
http://packetfactory.openwall.net/projects/firewalk/index.html
-
http://packetfactory.openwall.net/projects/firewalk/firewalk-final.pdf
source:https://diablohorn.com/2013/03/30/firewalking-with-nmap/
- 我的微信
- 这是我的微信扫一扫
-
- 我的微信公众号
- 我的微信公众号扫一扫
-
