Re: RFC: Nping requirements and user interface

[Fyodor <fyodor () insecure org>]

On Sun, May 17, 2009 at 07:49:57PM +0200, Luis M. wrote:
> Hi!
>
> It's been a busy week but finally I found the time to work on Nping
> requirements, output and command-line interface.

Thanks Luis!  And I see that you've checked them into
nmap-exp/luis/docs, which seems like as good a place as any to maintain
them.  In this email, I'll just discuss NpingRequirements.txt.  then I
may handle NpingCommandLine.txt and NpingExamples.txt in a separate
email.

Regarding NpingRequirements.txt (I'm omitting the ones I have no
comment on):

* Documentation of the source code using Doxygen syntax..............[Couldhave]

The code needs to be well documented, but you don't need to use
Doxygen syntax, as I don't think we use it for any of our other code.
Don't forget user documentation!

* 6 levels of verbosity (0 to 5)......................................[MustHave]
* 6 levels of debugging information...................................[MustHave]

You don't necessarily have to have exactly 6 levels as long as you
have verbosity and debugging flags and do a good job in ensuring that
output reflects the level chosen.  Very important stuff should be
printed by default, and other important stuff can require one level of
-v.  Adding two levels of -v can print a lot more.  With Nmap, -d
increments the verbosity level as well as debugging.  Verbosity
controls how much output is printed that might be useful to the user.
Debugging is mostly focused on output which is useful for developers
tracking down and fixing bugs.

* Custom IPv4 packet generation.......................................[MustHave]
[...]
  - Type of Service..................................................[CouldHave]
  - Custom Idenfication number......................................[ShouldHave]
  - Do Not Fragment Flag............................................[ShouldHave]
  - Invalid header checksum.........................................[ShouldHave]
  - IP options......................................................[ShouldHave]

I think these ones should all be MustHave.  Fortunately, these sorts
of things are pretty trivial to add.

* IPv6 packet generation
  - IPv6 support for TCP connect() ping.............................[ShouldHave]
  - IPv6 support for UDP pings......................................[ShouldHave]
  - IPv6 packet generation..........................................[ShouldHave]

These are MustHave too, unless there is some strong reason why we
can't do it.

* ICMP packet generation..............................................[MustHave]
[...]
  - Redirect........................................................[ShouldHave]
  - Fake Destination Unreachable Message.............................[CouldHave]

I think these are worth having.  So unless we find a problem in
implementing them, we might as well make them MustHave.

* Custom UDP packet generation........................................[MustHave]
[...]
   - Incorrect length.................................................[MustHave]

I'm not against offering incorrect UDP length, but unless you have an
idea for why we need it, we can probably make it OnRequest.

+------------------------+
| APPLICATION LAYER      |
+------------------------+
* Custom DNS request generation......................................[CouldHave]

That's an interesting idea.  How about putting HTTP request there too,
also as CouldHave?  You could give a URL and get back maybe the
response code and I guess time taken.

+------------------------+
| Nping ECHO SERVER      |
+------------------------+
* Encrypted communications symmetric encryption......................[MustHave]

I'm not sure if we'll need this encryption.  I guess it depends on how
the system ends up working.  The echo server in general, though, is
one of the features I'm most excited about.

* Use of covert channels to transfer information back 
  to the nping client................................................[CouldHave]

We may want to offer a variety of channel methods not so much for
being "covert" as to deal with firewalls or other filters which may be
in the way.  I'm not sure we'll need this, so CouldHave is fine.

* Echo back layers link+net+transport+payload
* Echo back layers net+transport+payload
* Echo back layerstransport+payload
* Echo back only payload

+------------------------+
| MISCELLANEOUS          |
+------------------------+
* Traceroute mode.....................................................[MustHave] 
  - Traceroute to a TCP port..........................................[MustHave] 
  - Traceroute to a UDP port..........................................[MustHave]

In general, it should probably be able to do a traceroute with
basically any of the types of IP probe packets it supports.
 
* Nmap style packet output............................................[MustHave]

Yes, and you should try to share the code between Nmap and Nping.  And
you might want to change/improve the output a bit where desired.  Nmap
may not be able to handle all the packet types and important data
fields desired for Nping.

Here are some more requirements from
http://seclists.org/nmap-dev/2009/q2/0314.html which don't seem to be
fully addressed in your requirement document yet:

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 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. [note that we may
  not get to this for SoC09]

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. 

My next mail will look at your NpingCommandLine.txt and
NpingExamples.txt documents.

Cheers,
-F

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