Nmap Development mailing list archives

Re: tcp and udp fastscan


From: Fyodor <fyodor () insecure org>
Date: Sun, 8 Oct 2000 02:52:53 -0700 (PDT)

On Fri, 22 Sep 2000, Dion Stempfley wrote:

Not a real problem, it works now.  But I want to scan 8 or 9 udp ports
and about 200 tcp ports.  I want this primarily for speed.  If I used:

  nmap -sUS -F -PI host

It creates a union of all the port numbers listed in tcp and udp parts
of the services file, then scans all ports for both services.

Yeah, that is a good point.  If you are using a custom Nmap-services with
only a few UDP services, that could make a big difference in speed.  For
the default nmap-services, it doesn't matter as much since most of the TCP
services have corresponding UDP entries (even for services that never use
UDP, which is annoying).

Of course, you can achieve the same thing by just running nmap twice (once
with "-sS -F" and then with "-sU -F").

But there could be other advantages of separating the ports array by
protocol.  For example, you cannot currently do a TCP scan at the same
time as IP Protocol scan because of conflicts over that ports array (if I
remember right).

It leads to somewhat messy UI issues though.  If we break up the arrays,
we might as well offer a way to specify different ports on the command
line.  Perhaps we could say:

Unqualified port(s) like '-p 25' means "use port 25 for all specified scan
types" (like it means now).

And we could allow ports to be qualified like '-p 25t' or '-p 25u' or '-i
7i' for TCP/UDP/IPProto "ports" respectively.

Then you could do something like:

nmap -sSUO -p1-25,80t,8080-8085t,161u (targets)

I think this is the syntax used by that Ndiff program James Levine posted
earlier.

This is because the ports[] structure is unsigned int and does not allow
for the storage of the protocol.   I want to solve this, but want the
least impact to the overall code baseline.  

I think separate unsigned short arrays (one for each protocol) would be
better than expanding the element length so you can tag each port with a
protocol.

Any thoughts on the best
way?  If not, I will hack it and see what others think.

I would definitely consider accepting a clean patch that does
this.  Especially if it allows ports to be specified by protocol on the
command line (as above).

Sorry if this is incoherent.  It is already 3AM and I am only up to
September 22 in answering my mail.

Cheers,
-F


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).



Current thread: