Nmap Development mailing list archives
Re: RFC: Nping requirements and user interface
From: Fyodor <fyodor () insecure org>
Date: Fri, 22 May 2009 00:37:14 -0700
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
Current thread:
- RFC: Nping requirements and user interface Luis M. (May 17)
- Re: RFC: Nping requirements and user interface Fyodor (May 21)
- Message not available
- Re: RFC: Nping requirements and user interface Fyodor (May 22)
- Message not available
- Re: RFC: Nping requirements and user interface Fyodor (May 21)
- Re: RFC: Nping requirements and user interface Fyodor (May 22)
- Re: RFC: Nping requirements and user interface David Fifield (May 24)
- Re: RFC: Nping requirements and user interface Fyodor (May 25)
- Re: RFC: Nping requirements and user interface David Fifield (May 24)