RFC on Nping: Raw packet probing nirvana

[Fyodor <fyodor () insecure org>]

Hi All.  Thanks for all of your feedback on Ncrack!  That discussion
was and continues to be very useful and will surely help Ithilgore
make the project a success!  Now I want to introduce and solicit your
feedback on another planned project: Nping.

We already have Ncat, which lets you do all sorts of wonderful things
with socket connections.  Our Nping utility lets you take your probing
to a lower level and manipulate raw packets and ethernet frames
instead.

Coordinating Nping development will be Luis MartinGarcia, a Master's
student at the University Carlos III Madrid in Spain.  For an example
of his talents in writing useful open source security software, check
out his Aldaba Knocking Suite at http://www.aldabaknocking.com!  We
are lucky to have Luis this summer, and ought to make the most of it!

As you may have guessed, Nping was inspired by Antirez's excellent
hping application!  That tool is great, and even placed #6 at
SecTools.Org, but I think we can do even more!  We can add great new
features, support more platforms, support IPv6, and design the
interface to be comfortable and familiar to Nmap users.  Plus we can
actively maintain and improve Nping.  The last hping2 release was more
than 5 years ago, and hping3 development seems to have been abandoned
in 2005.

So this mail is designed to flesh out exactly what we'd like to see in
Nping.  I'm listing my project requirement ideas here.  As with my
Ncrack email, I'm not saying that all of these can or must be done by
the end of SoC.  Some of these may be longer term goals.  But the
first step is to describe our dream utility, and we might then have to
triage a bit to determine which parts we can finish by August 17.
Here are my ideas:

o Must support dealing with ethernet frames, IP, TCP, UDP, and ICMP.
  We might find other protocols useful as well.  It must be able to
  handle these raw, and also provide cooked modes using connect() and
  UDP regular socket sends.  Those can be useful for users without raw
  socket privileges (e.g. nonroot on UNIX, or Windows without pcap).

o A well-organized command-line interface is required, with a logical
  and well-organized set of options.  To the extent there is a
  conflict between being more like Nmap or like Hping, choose Nmap.
  But don't feel like you have to use Nmap-style options where they
  don't fit well.  It should support verbosity/debugging levels like
  Nmap and Ncat do.

o Similarly, the packet output should be similar to what Nmap shows
  with --packet-trace.  Ideally, they would even share that code.  The
  requirement that output be similar doesn't mean you need to follow
  Nmap's current packet viewing format exactly.  If you think of
  improvements, you could keep the output similar by improving Nmap's
  output at the same time.

o Must support IPv6 and IPv4

o Of course the tool must be small, stable, secure,
  resource-efficient, and well written.

o The tool must be fully documented in a man page and users' guide.
  These should be written in Docbook XML so that we can easily
  translate them to HTML, Nroff (for the man page), or PDF for
  printing.  Check out the Zenmap and Ncat man pages and users guide
  at http://nmap.org/zenmap/ and http://nmap.org/ncat/.

o A GUI written in Python would probably be useful.

o Should be very useful and functional just for normal ping purposes
  (whether the user requests ICMP echo request, TCP connect() ping,
  UDP, ARP ping, etc.).  This means providing useful stats, common
  ping options, etc.

o Must have traceroute mode (and of course let you specify traceroute
  to a TCP port, UDP, ICMP, etc.)

o Should support useful features from hping2/hping3

o Maybe some sort of scripting functionality would be nice.  If so, it
  should of course be in Lua.  But maybe Nmap NSE using the raw packet
  mode and pcap is sufficient and we don't need it in Nping.

o Must be written in C++ (can be very C-like as Nmap itself is) and
  portable (Linux, Mac, Windows, etc)

The plan is to distribute Nping along with Nmap, Zenmap, and Ndiff.

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!

Cheers,
Fyodor

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