mailing list archives
Re: RFC on Nping: Raw packet probing nirvana
From: Fyodor <fyodor () insecure org>
Date: Fri, 8 May 2009 02:55:10 -0700
On Wed, May 06, 2009 at 09:21:45AM +0000, Brandon Enright wrote:
-----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
Hi Brandon. You should think about this more when you're more rested,
as I think you're on to something! In particular, a number of people
over the years have asked for this sort of client/server testing to
determine what packets are being dropped and how they're being
manipulated across the network.
If you can think up a concrete proposal, please do send it for
discussion. Having Nping act as the sniff server itself is an
interesting idea. Or we could have another tool for that (nsniff?),
which would sniff for a unique token/signature which Nping, Nmap and
the like could be requested to send. This signature could be a unique
IP option string, IP ID, TCP option, data value, or the like. That
would make it very easy to isolate and only show the packets coming
from Nmap/Nping. But it may not work well for some of the things you
have in mind. I'm just doing late night incoherent brainstorming too
:). But everyone has probably noticed that I've lately had a
propensity for dreaming up new tools :).
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
That one will be easy to fix with Nping.
and is generally too hard for the layperson to use.
A quality UI and good documentation can help a lot with this.
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.
Maybe if you could run nsniff on a remote host and they could add the
--nsniff option (but probably a better option name) to nmap/nping, and
the appropriate tokens would be added to all sent packets so that you
can easily identify them with nsniff. Or, perhaps, you could just
tell nsniff the IP address of the source and let it figure out that
way. But then the value over just using tcpdump is not so clear.
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.
Nsniff could be easier for this case, though it could never be as
powerful as Wireshark. I suppose it could save in pcap format though
so that you could load the session into Wireshark later.
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
Ooh, I really like this echo mode idea! So instead of having a
tcpdump on the remote machine in one window and having hping/nping in
another and trying to match the probes to the responses and figure out
what is going on, the Nping client could learn from the Nping server
on the other side what packets were received and sort of match them up
in the output. I do like this idea (though we need to hammer out the
details of exactly how it might work). And I now understand why this
is more than just an "nsniff". I really should fully read emails
before I start replying :).
We really do need a great way to distinguish nping from hping, and
this could be a good one. Yes, we can make it more portable, more
stable, support IPv6, etc. But I'd like to really distinguish Nping
in the same way that Ncat has functionality which the original Netcat
can only dream of.
Another way to distinguish Nping would be excellent Lua scripting
support. Sure, Hping3 has TCL scripting, but I don't know how
complete that really got before they abandoned the project years ago.
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.
Getting more complex, but still interesting. I do think you're on to
something. Though it may be more of a network debugging tool than a
security tool. On the other hand, finding holes in a firewall or
exploitable network configuration problems can be a lot like
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
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.
Heh. Maybe someday scanme will run an Nping server, and Ncat chat, an
Nmap target, and provide a way to Nmap scan yourself. Hehe, I did run
Ncat chat on there for a while and David and I had some Ncat chat
meetings. But we had to move it because the screen kept overflowing
with crap from people doing version detection against
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.
I will ruminate on this, and also have a meeting with Luis on Friday.
But if you get more time to reflect on this when you're rested, I
would like to hear more of your ideas.
So far we have two (somewhat vague still) ideas for an "ultimate
distinguishing feature" for Nping: the remote echo server
functionality, and Lua scripting. If anyone has other clever
extension ideas, I'd love to hear them. They are much easier to
accommodate in this stage than later!
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org
Re: RFC on Nping: Raw packet probing nirvana ithilgore (May 06)