mailing list archives
Re: RFC on Nping: Raw packet probing nirvana
From: Brandon Enright <bmenrigh () ucsd edu>
Date: Wed, 6 May 2009 09:21:45 +0000
-----BEGIN PGP SIGNED MESSAGE-----
[Sorry about the length of this email, it's pretty much
stream-of-consciousness. I'm too tired to express my thought
On Wed, 6 May 2009 01:01:30 -0700 or thereabouts Fyodor
<fyodor () insecure org> wrote:
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
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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org
Re: RFC on Nping: Raw packet probing nirvana ithilgore (May 06)