Re: RFC: Nping requirements and user interface

[Fyodor <fyodor () insecure org>]

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

Great!  This mail looks at the command-line interface and examples.

> Nping 0.0.1-SoC9 ( http://nmap.org/nping )

You'll eventually want to use the Nmap version number (maybe prefixed
with 0.) like Zenmap, Ncat, etc.  But it is OK to just have that be a
#define for now which you can change from time to time as warranted.

> TARGET SPECIFICATION: {See [1]}
>   Targets may be specified as hostnames, IP addresses, networks, etc.
>   Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
>   -iL <inputfilename>: Read targets from list of hosts or networks

So you can specify multiple targets and Ncat will send the same probes
to each of them?  That is an interesting idea, and may prove useful.

> PING TYPES:
>   -pT, --tcp   : TCP ping mode.
>   -pU, --upd   : UPD ping mode.
>   -pI, --icmp  : ICMP ping mode.
>   -pA, --arp   : ARP ping mode.

Nmap uses a lot of these 2-character options, but I'm not sure they
are a good Nmap trait.  It is mostly done because Nmap is so complex
and has so many options.  Nping is a much simpler tool, so maybe we
can get by with simpler options.  The --tcp, --upd, --icmp, and --arp
options are well named.  You might give one-character shortcuts for
the most common.  Like maybe -t and -u for --tcp and --udp,
respectively.  If TCP is the default, you might not want to blow a
single-character option on it.  You can always be sparing with the
shortcut options now, and add more later if desired.

>   -tr, --traceroute : Traceroute mode (can be used together with TCP/UDP/ICMP 
>                       pings, but not with ARP ping)

Looks good.

> TCP PING MODE:
>    -g, --source-port <portnumber>  : Set source port.
>    -p, --dest-port <portnumber>    : Set destination port.

If you're going to allow multiple targets, are you going to allow
multiple ports at once too?

[skipping some stuff which looks fine]

> ICMP PING MODE:
>   -I3, --dest       : Send "destination unreacheable" messages.
>   -I8, --echo       : Send "echo request" messages.
>   -I13, --timestamp : Send "timestamp request" messages.
>   -I15, --info      : Send "Information request" messages.
>   -I17, --netmask   : Send "Netmask request" messages.

I'm not sure we need the -I aliases here.  Most people probably don't
know their ICMP type and code values offhand.  What are you going to
do for cases such as destination unreachable that require more
specificity?  For example, you might want to send a network
unreachable, port unreachable, protocol unreachable, etc.

>   --icmp-code <code>: ICMP code.

Ah, that could help with the dest unreachable ambiguity.  Though we
might want to provide the common codes in the help message or
something.  Again, many people might not remember offhand that code 13
is "communication administratively prohibited".

>   --icmp-id <id>    : Sets field "Identifier" in echo messages (16bits).
>   --icmp-seq <n>    : Sets field "Sequence number" in echo messages (16 bits).
>   TODO: Add options for all fields required by those ICMP msg types.

Ah, OK you have a TODO for expanding this as well.

> ARP PING MODE:
>   --sender-mac <mac> : Set sender MAC address.
>   --sender-ip  <ip>  : Set sender IP address.
>   --target-mac <mac> : Set target MAC address.
>   --target-ip  <ip>  : Set target IP address.

how about "src" and "dst" rather than sender/target?  So if you just
want to do a simple ARP ping, you don't need any of these options and
you just specify --arp and the target(s)?  You may want to share code
with Nmap for dealing with nmap-mac-prefixes so that you can print the
hardware type in responses where desirable, and you could potentially
allow spoofing in the same way as Nmap does (e.g. you can type a
vendor and Nmap will use that prefix and fill in the rest of the
source MAC address randomly).

> ETHERNET OPTIONS:
>   --dest-mac   : Set destination mac address. This disables ARP resolution. 
>   --source-mac : Set source MAC address.
>   --spoof-mac  : Set source MAC address (provides same flag as nmap).

These should probably be the same options as whatever is used in "arp
ping mode" as they are doing the same thing AFAICT.  I'm not saying
what the options should be, just that they should be the same.
--spoof-mac might be undocumented, but allowed as an alias for
--src-mac (or whatever you call it) for cases where an Nmap user types
--spoof-mac out of habit.

> IP OPTIONS:
>   --source-ip  : Set source IP address.
>   -S,--spoof-ip: Set source IP address. (consistent with --spoof-mac format)

I don't think we need --spoof-ip.  -S for consistency with Nmap seems
reasonable, and it would be good to have a long option too. --src-ip
or something.

[cut a bunch]

> PAYLOAD OPTIONS:
>   --payload <hex string>     : Include TCP/UPD/ICMP payload (if it makes sense).
>   --payload-file <filename>  : Get payload from specified file.
>   --payload-random <len>     : Include len random bytes as payload.
>   --data-length <len>        : Same previous one but with nmap syntax.  (??)

I wonder if we should use --data rather than --payload in all four
cases?  There should be a way to specify the payload directly (e.g. in
ASCII).

> ECHO CLIENT/SERVER:
>
>   -K, --ekey <hex> : Key to be used for encryption/decryption.
>   -P, --passphrase : Passphrase to derive an encryption key from.

What are the reasons for encrypting this?  Can you describe the attack
scenario we're worried about?

>   --channel-udp <port> : Use an UDP-based side channel (Server:listen on that
>                          port, Client: communicate to that port)
>   --channel-tcp <port> : Use a TCP-based side channel (Server:listen on that
>                          port, Client: communicate to that port)

Maybe we should just worry about TCP first.  UDP would add
complications since you need to worry about dropped packets,
reordering, etc.  A default port should be used, though there should
be an option to specify a differnt port if desired (in which case
you'd have to specify the same option for both client and server).
For simplicity, it might be that this echo server thing is only
enabled when there is just one target specified.

>   CLIENT-ONLY OPTIONS:
>     --client         : Run Nping in client mode.

We may want a short option for this.  We may want to think of a better
name than "echo client/server".  Considering that this is
fundamentally a ping program, people might be confused that we're
talking about echo request (ping) clients and servers.  Anyone have
good ideas for naming this feature?  I guess I'll stick with echo
client/server for now until we think of something better.

>     --interpret      : Interpret received echoes.

Will be interesting to see what you have in mind here (I haven't read
your examples yet, so I don't know if it includes example output,
etc.).

>   SERVER-ONLY OPTIONS:
>     --server         : Run Nping in server mode.
>     --echo-link      : Return back: link+net+transport+payload
>     --echo-net       : Return back: net+transport+payload
>     --echo-trans     : Return back: transport+payload
>     --echo-data      : Just return payload.

Maybe we should just have it return everything, and let the client
decide what to print (perhaps based on some command-line options like
verbosity level, etc).

> TIMING AND PERFORMANCE:
>   Options which take <time> are in milliseconds, unless you append 's'
>   (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
>   -T[0-5]               : Set timing template (higher is faster).

I'm not sure that we actually need -T.  With Nmap, timing is far more
complicated and a single -T option encapsulates a whole lot of
disparate behaviors.  Nping is so much simpler that we can probably
just let the user specify the rate and the like exactly.

>   -i, --interval <time> : Adjust delay between probes (hping flag).
>   --ping-delay <time>   : Adjust delay between probes(nmap-like flag). (??)

We can probably deal with just the interval option.  We should
probably have a convenience option for setting a rate (# of packets
per second) too for people who like to specify it that way.

>   --host-timeout <time> : Give up on target after this long.
>   
> MISC:
>   -h, --help      : Display help information on stardard output.
>   -V, --version   : Display Nping current version number. 
>   -c, --count <n> : Stop  after  sending  (and  receiving) n response packets.

What do you mean "sending (and receiving)"?  What if the target
doesn't reply to any of the probes?  A short wait after all packets
are sent seems reasonable though to catch any replies which do come.

>   -e, --interface <name> : Use supplied network interface.
>   --privileged    : Assume that the user is fully privileged.
>   --unprivileged  : Assume the user lacks raw socket privileges.

These option may be useful but obscure options (as they are with
Nmap), but maybe we should have a different set of options for
explicitly setting raw or cooked packet mode.  That way a root user
can still request sockets API mode without having to do --unprivileged
(which might possibly restrict some other aspects of his scan).

>   -v              : Increment verbosity level by one.
>   -v[level]       : Set verbosity level. E.g: -v4
>   -d              : Increment debugging level by one.
>   -d[level]       : Set debugging level. E.g: -d3

You should also be able to specify -v or -d multiple times to achieve
the same affect, as you can with Nmap.

> In places where a port number, an IP address, etc, is expected, it is possible
> to specify the word "random", so Nping sets a random value for that option.

Sounds like a good idea.  Maybe just "rand" to save a couple chars,
while still making "random" work for people who type out the whole
thing.

> In places where a MAC address is expected, it is possible to especify a MAC 
> address, a prefix or a vendor name. Missing information will be completed with
> random values.

Great, just like Nmap.

> [1] QUESTION: Should we support specification of more than one host? Do we 
>     really need to ping more than one host? Nmap is probably more appropriate
>     if we want to test multiple hosts. However we have different choices:
>        - Send only one packet if more that one host is specified and show 
>          the replies.
>        - Loop over the target list sending packets and displaying replies.
>        - Ping the first target until the user hits CTRL-Z or "count" packets
>          have been sent.

Does anyone want multiple target hosts with nping?  Now's your chance
to speak up with what you want!  If nobody asks for this feature and
specifies how they would use it, I think we can leave it out.

I think the echo client/server will need more discussion and output
planning, but we might be able to defer some of that planning until
the other stuff is done.  Brandon's draft is a good start!

Cheers,
Fyodor



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