Oooh!!!! I have seen this behavior before (the extra-ping reply thing) when scanning networks protected by pix. Many times! Makes me wonder..... We may test this in a lab and see what happens. I'll post again if I can find time to do it. > -----Original Message----- > From: mcoleman [mailto:mcolemanat_private] > Sent: Thursday, May 31, 2001 10:58 AM > To: vuln-devat_private > Subject: PIX revealing Statics when hit with NMAP... > > > Hi list, > > I originally submitted this to bugtraq proper, but it > was rejected with > the following message: > > >>>>> -------------------- >>>>> > Post to the vuln-devat_private mailing list. Once you > or others > have flushed out the details a little more post to bugtraq. > <<<<< -------------------- <<<<< > > I am sorry to say that I am not subscribed to the > vuln-dev list, so I > would REALLY appreciate it if all posts on this topic were CC:'d to > mcolemanat_private so that I can follow the discussion > and answer any > questions. > > I am also sorry to say that I just simply don't have > time to follow up > on this right now, but have gotten so much from these lists > that I feel > obligated to post what I have found. I would be very > interested to see > anyone's results from testing. I may get back to it soon if > nobody else is > able to. Thanks.... > > Here is my original email to bugtraq: > > --------------------------------------------------------- > > I have been playing with NMAP and think I found a way to identify > "statics" in a NATted PIX firewall. > > I don't know if this is a known thing, I did a quick > search and didn't > see anything. If so, please ignore. > > Please be aware that I temporarily have ICMP enabled in the PIX's > conduits, and when I run Eeye's M$ version NMAP (no Linux on > my laptop yet) > using the following:: > > nmapnt -O 123.123.123.2-254 -sX > > (IP address intentionally faked above) > > ...NMAP lists the following as part of its output among other things: > > Host (123.123.123.213) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > Host (123.123.123.214) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > Host (123.123.123.216) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > Host (123.123.123.217) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > Host (123.123.123.218) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > Host (123.123.123.222) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > Host (123.123.123.224) seems to be a subnet broadcast > address (returned 1 > extra pings). Skipping host. > > (Again, addresses above changed to fake numbers) > > These are inclusively the EXACT same addresses of my static address > translations in the PIX. These statics only permit very > specific things > inbound via the conduits (other than the ICMP that is), so the TCP > interaction > probably didn't occur through the PIX with other parts of the > scan. While > the conduit in the PIX is wide open for ICMP for this test: > > conduit permit icmp any any > > ...the NMAP seems to be able to identify the static'd NAT addresses. > > Those of you who are unaware of what static addresses do, > they allow you to > permanently assign an address from the NAT pool to a certain > host behind the > PIX. I use this to fix an address for access-list entries on > our border > router for a particular high UDP port for replies to our internal DNS > server. > It is very common for the static addresses to have conduits > associated with > them that allow certain inbound traffic. Revealing the > statics could give > an > attacker clues as to which NAT'ted IP addresses are servers > behind the PIX, > or have open inbound conduits. > > My config is failover PIX 520 using 5.0(3), using NAT > overflowing to PAT, > with > specific conduits on only specific Static'd addresses. I am using the > conduit > PERMIT ICMP ANY ANY, but have not yet had the time to remove > that conduit > to run NMAP again to see if removing that will eliminate the problem. > > During times of testing and troubleshooting, I will often > enable ICMP in the > conduits, but will now be reconsidering this practice for > extended periods > of time. > > I won't have time to follow up on this issue at the moment, > might get to it > later. I do know that using a sniffer, I do NOT see > duplicate ping replies > when I do a simple M$ ping (you have to use a sniffer if you > ping with M$, > as M$ doesn't list any duplicate replies I don't think, as > Linux does). I > will likely run the sniffer in a week or two when things slow > down to see > exactly what NMAP did to generate "extra pings", and to identify these > conduits. It might not even be ICMP for all I know right > now. Thanks. > > -Mark Coleman > -TNS > > > >
This archive was generated by hypermail 2b30 : Thu May 31 2001 - 23:38:33 PDT