Re: RFC on Nping: Raw packet probing nirvana

[Fyodor <fyodor () insecure org>]

On Wed, May 06, 2009 at 09:21:45AM +0000, Brandon Enright wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [Sorry about the length of this email, it's pretty much
> stream-of-consciousness.  I'm too tired to express my thought
> concisely.]

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
> reasonable way

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
> with Nping.

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
debugging.

> 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.

Good points.

> 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
scanme.nmap.org:31337 :).

> 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!

Cheers,
Fyodor

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org