Re: RFC on Nping: Raw packet probing nirvana

[Arturo 'Buanzo' Busleiman <buanzo () buanzo com ar>]

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