Nmap Development mailing list archives
Re: RFC on Nping: Raw packet probing nirvana
From: Arturo 'Buanzo' Busleiman <buanzo () buanzo com ar>
Date: Thu, 07 May 2009 12:01:26 -0300
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Let me remind you all that transparent proxying is easily detectable using the QSCAN method.... More info here: http://archiver.mailfighter.net/nmap-dev/2007/Sep-Oct-Nov-Dec/0079.html Luis M. wrote:
I like that idea, it sounds really interesting! I think we could add that to a todo-list of things to be implemented after the main Nping is finished. Personally, for now, I'd prefer not to flag this "Nping server" as a must-have requirement but as functionality that would be nice to have. Summer is not very long and I'd prefer to first have a stable version of Nping and then go for that kind of enhancements. What do the rest of you guys think about the idea? Regards, Luis. Brandon Enright wrote:[Sorry about the length of this email, it's pretty much stream-of-consciousness. I'm too tired to express my thought concisely.] On Wed, 6 May 2009 01:01:30 -0700 or thereabouts Fyodor <fyodor () insecure org> wrote: ...snip...Those are my thoughts, and I hereby open the floor to ideas! Remember that it is much easier to make major changes now while we're still in the planning stage than once we begin implementation. Let us know what you think!I'm in a love-hate relationship with hping2: I love that it is such a powerful troubleshooting tool and that I can create pretty custom packets with it but I hate that it doesn't support Windows in any reasonable way and is generally too hard for the layperson to use. The times when I really need hping to work are the times when it is hardest to use. I generally find myself troubleshooting campus routing and firewall issues with hping and I generally don't have direct control over the end host but instead have to coordinate with the admin over the phone or via IM. The scenario is generally that some network traffic should be flowing but isn't. The causes of problem can range from routing issues to network firewall to host-based firewalls to all sorts of other strange things. It is usually the "middle box" problem that is the hardest to find. Suppose there is some host with a TCP service listening that you can't connect to for an unknown reason. If a Nmap -sS scan doesn't show the port as open there are a multitude of possible problems. Maybe the SYN packet never made it because of some firewall in the middle. Maybe the SYN did make it but the SYN+ACK got dropped on it's way back to you. Maybe the TTL expired in transit but the ICMP message got blocked by another firewall before making it back to you. Maybe the SYN made it but some intermediate host forged a reset packet to snipe the connection before the SYN+ACK made it back to you. When things like the above are going on it is often the case that even hping can't track down the problem alone. I generally have to turn to Wireshark on one station and hping on the other. It is *very* hard to instruct someone how to use Wireshark over the phone when they might not even know what an IP address is. What I'm proposing is a echo/daemon/server/listen mode for Nping that will give it the power of hping + tcpdump. The way it would work is that both machines would have to be running Nping, one of them in server mode. That is, the machine being scanned with Nping would have the server on it. I'm not talking about a server in the Nessus sense of the word. I'm thinking specifically of the troubleshooting connectivity scenario here so it is realistic to assume that this coordination between the person doing the scan and the person being scanned can and would take place. In server mode, when you use Nping to connect to a remote Nping server you do some hello/handshake over some standard port we pick (this is the side-channel). You then notify the server what packets you are about to send, it sets up a liberal BPF filter that will capture those packets, and it ships what it got back down to you via this side-channel. This would be essentially like running tcpdump on the remote machine and having it report back the packets you sent to it with Nping. The power of server mode wouldn't stop there though. You're Nping client should be able to issue "remote ping" commands that would instruct the server would send to you so that you can examine if they get to you and what happens to them in transit. Having the side-channel to talk to the server allows things like XMAS and NULL scans to "work" against Windows. With hping or Nmap, if you send a XMAS or NULL packet to a Windows box you won't hear anything useful back. With the help of the server though, you'll be able to see exactly what that packet looked like when it got to the target because the server will encapsulate and send the packet it got back down through the side-channel. Things like NAT would become immediately apparent because you'd see your source IP (and sometimes port) change. Things like "packet shapers" that change TCP window sizes transparently between hosts would turn up. It would be easy to tell if the traffic is being dropped in transit and never gets to the box. It would also be easy to tell if the traffic does make it to the box but the reply never makes it back to you. In general, it would be like sending a postal package to someone and having them email you a photo of the package when they get it. If you think your packages are being abused by the parcel service then having someone on the other end to send information back is a great way to uncover what is going on. We could even make a general scripted "middle box" check that looks for all sorts of craziness. If done properly and securely people like Fyodor could run a Nping server on scanme.insecure.org and people being abused by their ISP could uncover what is being done to their packets. You could find out whether or not your ISP allows spoofed IP traffic to leave the network, etc. There is precedence for this type of tool. IIRC Dan Kaminsky has done some work on a tool to detect transparent proxies and other ISP monkey-business. The Internet2 NDT tool (part of Web100) has a "middlebox" check (for example http://falcon.ucsd.edu:7123/). In short, we can clone hping and get a hacking and recon tool. We can borrow ideas from other tools and add a mode like the one described above and get a great hacking AND troubleshooting tool. Brandon_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
- -- Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107 Independent Linux and Security Consultant - SANS - OISSG - OWASP http://www.buanzo.com.ar/pro/eng.html Mailing List Archives at http://archiver.mailfighter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkoC98UACgkQAlpOsGhXcE1chgCeKmFSzHIQRqRM9MXZRz46sJb9 5AwAnj7XnNbNKdwob+8pHBFxWKQPoh1Y =SnMt -----END PGP SIGNATURE----- _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- RFC on Nping: Raw packet probing nirvana Fyodor (May 06)
- Re: RFC on Nping: Raw packet probing nirvana Brandon Enright (May 06)
- Re: RFC on Nping: Raw packet probing nirvana Luis M. (May 07)
- Re: RFC on Nping: Raw packet probing nirvana Arturo 'Buanzo' Busleiman (May 07)
- Re: RFC on Nping: Raw packet probing nirvana doug (May 30)
- Re: RFC on Nping: Raw packet probing nirvana Luis M. (Jun 01)
- Re: RFC on Nping: Raw packet probing nirvana Luis M. (May 07)
- Re: RFC on Nping: Raw packet probing nirvana Brandon Enright (May 06)
- Re: RFC on Nping: Raw packet probing nirvana Fyodor (May 08)
- Re: RFC on Nping: Raw packet probing nirvana Ron (May 08)