Firewall Wizards mailing list archives
FW: RE: RE: firewalk meets nmap - TTL
From: "Ofir Arkin" <ofir () itcon-ltd com>
Date: Sun, 5 Nov 2000 22:42:07 +0200
Lance, Some firewalls monitor for low TTL field values and will drop your packet. If there are some who will generate the ICMP time exceeded error message (and this is the firewall here generating the message) in my opinion it is a mistake, because it will reveal the firewall itself. I have more to this one. In Blackhat 2K in Amsterdam I was talking about the ability to identify the Operating System one firewall might run on top because of the ICMP error messages it might generate / or spoofed answers the firewall generates instead of its protected machines. If you have a trace I would like to have a look :P Ofir Arkin [ofir () itcon-ltd com] Senior Security Analyst Chief of Grey Hats ITcon, Israel. http://www.itcon-ltd.com Personal Web page: http://www.sys-security.com "Opinions expressed do not necessarily represent the views of my employer." ---------------------------------------------------------------------------- ------------ ---------------------------------------------------------------------------- ------------ The Trace Lance Psoted and I analyzed:
In Blackhat 2K in Amsterdam I was talking about the ability to identify
the
Operating System one firewall might run on top because of the ICMP error messages it might generate /
or
spoofed answers the firewall generates instead of its protected machines.
Very cool idea. This hack will not only map your firewall rulebase, but your firewall OS type :)
If you have a trace I would like to have a look :P
Sure, below is the technique and traces from a test. The firewall is CheckPoint FW-1 ver 4.1 SP2 on Solaris 2.7 (Ultra 5). The port 5190 TCP and port 5190 UDP are NOT filtered by the firewall. I scanned a system behind the firewall on each port with hping2, TTL set to 1 (I am 1 hop away from the firewall). Note how the firewall responds, and not the system behind the firewall I was scanning.
mozart #hping2 -c 1 -t 1 -s 53 -p 5190 -S victim eth0 default routing interface selected (according to /proc) HPING victim (eth0 172.16.1.107): S set, 40 headers + 0 data bytes TTL 0 during transit from 192.168.1.254 (firewall.example.net)
Now the packet traces (just for Ofir)
Thank you :)
-*> Snort! <*- Version 1.6.3 By Martin Roesch (roesch () clark net, www.snort.org) 11/03-09:10:36.563267 192.168.1.10:53 -> 172.16.1.107:5190 TCP TTL:1 TOS:0x0 ID:36962 **S***** Seq: 0x53C8F31C Ack: 0x1A37A627 Win: 0x200
11/03-09:10:36.564040 192.168.1.254 -> 192.168.1.10 ICMP TTL:255 TOS:0x0 ID:31007 DF TTL EXCEEDED 00 00 00 00 45 00 00 28 90 62 00 00 00 06 BB 40 ....E..(.b.....@ C0 A8 01 0A AC 10 01 6B 00 35 14 46 53 C8 F3 1C .......k.5.FS... 1A 37 A6 27 50 02 02 00 22 F6 00 00 .7.'P..."...
The Offending Packet: IP Version=4 Header Length=5 TOS = 00 16 bit total Length=00 28 16 bit Identification=90 00 3flags+13-bit frag.=00 00 TTL=06 Protocol=BB 40 Source IP Address=C0 A8 01 0A Destination IP Address=AC 10 01 6B Source Port=00 35 Destination Port=14 46 Sequence Number=53 C8 F3 1C Acknowledgment Number=1A 37 A6 27 50 02 02 00 Checksum=22 F6 Urgent Pointer=00 00 28 bytes were echoed back.
Thoughts?
This is exactly what I was talking about. If you look closely than: - DF bit is set with the ICMP Time Exceeded Error Message (SUN/HPUX11.x). It was not set with the request so we are not dealing with echoing issue here. - TTL used 255 (UNIX / UNIX-Like OS) - Quoting Size - Bigger than the first 8 bytes of data portion of the offending packet. In fact it quoted all the TCP packet (SUN/LINUX) - ICMP Echoing Integrity - The quote is OK. Sun Solaris do this OK. LINUX play with some parameters. So is it a Linux or Solaris? If you look at the possibilities you understand this is a Solaris. But lets play more. Since Linux set the Precedence field to 0x6 with its ICMP error messages we are left with Solaris. We can even go to www.checkpoint.com and look for the platform the firewall run on top. Solaris / NT. I think the point is now clear and understood :) Lance, we should automate this somehow. This is a cool thing. But again correct configuration will prevent this from happening. Ofir Arkin [ofir () itcon-ltd com] Senior Security Analyst Chief of Grey Hats ITcon, Israel. http://www.itcon-ltd.com Personal Web page: http://www.sys-security.com "Opinions expressed do not necessarily represent the views of my employer." ---------------------------------------------------------------------------- ------------ ---------------------------------------------------------------------------- ------------ -----Original Message----- From: Lance Spitzner [mailto:lance () spitzner net] Sent: Friday, November 03, 2000 7:01 AM To: nmap-hackers () insecure org Subject: firewalk meets nmap - TTL I'm not sure if anyone has thought of this, but this would be a REALLY cool feature for auditing firewall rulebases. Say you want to determine what ports a firewall allows through, what ports are NOT filtered. Have the option with nmap to set the TTL on the packets it sends. I set the TTL to be the same as the amount of hops to the firewall I am scanning. If the packet is filtered by the firewall, then it is dropped and nothing is sent back. However, if the packet is accepted by the firewall (and the port is not filtered), the firewall will attempt to forward it. However, the TTL will now be zero and the firewall will respond with ICMP TTL expired error message. You can now map what ports are passed through the firewall (i.e not filtered) without a packet ever passing through the firewall. firewalk meets nmap thoughts? -- Lance Spitzner http://www.enteract.com/~lspitz _______________________________________________ firewall-wizards mailing list firewall-wizards () nfr com http://www.nfr.com/mailman/listinfo/firewall-wizards
Current thread:
- FW: RE: RE: firewalk meets nmap - TTL Ofir Arkin (Nov 08)