Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Nmap Hackers: Re: Nmap 2.30BETA20 Released

Re: Nmap 2.30BETA20 Released

From: Andrew Brown <atatat_at_atatdot.net>
Date: Fri, 21 Apr 2000 15:23:17 -0400

>> i'd also like to suggest that you distribute the "massive" services
>> file that i've been maintaining for a year or so at
>>
>> http://www.graffiti.com/services
>>
>> as the nmap-services file. it's basically a large merge of the iana
>> port-numbers list and the services files from solaris, the bsds, a few
>> linuxes, and some submissions i've gotten, giving a really nice big
>> list. it's really good for scanning *everything*. :)
>
>I took some time to compare the differences between the services file
>distributed with nmap 2.30beta20, and the new services file that you are
>maintaining. It looks like you have roughly triple the number of port
>descriptions - good job!

thanks.:)

>I can see that these short descriptions will be useful in identifying open
>ports in a scan - however I wish that contributors to your list (and any
>port list) would drop more hints about what the services are.

well...i don't *actually* have that many submissions. maybe 12 so
far. most of it comes from the files i mentioned.

>Personally, I only recognized several of the thousands of additional ports
>on your list. Mention of an OS or application name would help with the
>research - especially for those of us performing external auditing who
>don't always have the immediate luxury of 'lsof -i'. (That comes soon
>enough, but usually not through discovering a new hole in a completely
>unknown app :)

that's information that i don't have...but wish i did. jeez...it's be
nice if i had service names, application names, platform names, and
specifications for all the protocols in the world...then i could build
a sophisticated service detector as opposed to a port scanner. :)

>I saw a few port ranges that I wanted to draw attention to for anyone
>using the service file:
>
>lines/ description
> 64/ tcp ports for x11 (6000-6063) - this is sort of overkill..
> 64/ udp ports for x11 (6000-6063) - AFAIK X doesn't use UDP
> 100/ VRML range (4200-4299) - 100 ports for what?
> 91/ swx (7300-7390) - www.swx.com? what server software is this?
> ...couple other ranges like this should be looked at

that's iana's doing. the iana file has this:

x11 6000-6063/tcp X Window System
x11 6000-6063/udp X Window System
# Stephen Gildea <gildea_at_lcs.mit.edu>

and typically assigns the udp and tcp port numbers in tandem, as
opposed to ancient practice (see syslog vs shell)

>Since I'm addressing problems - another issue is that most port lists
>(including the IANA assignments) list identifiers that are somewhat
>useless in the real world. For example all of those ports with entries
>for both TCP and UDP. Most services don't use both transports. For
>example if you are scanning and see an open TCP port 137 - it's *not* the
>netbios name service. There are a ton of port identifiers like this that
>might actually just slow down ligitimate auditing, or in some cases
>confuse/mislead administrators who don't know any better..

well...that's true.

>For the benefit of less experienced netmapers, I would prefer to see
> netbios-ns 137/tcp # netbios name service
>be replaced by
> UNKNOWN 137/tcp # daemon on priveledged port!@#$
>and other appropriate accuracies.

that's a philosophical question. i'd prefer it if the skript kiddeez
were just strangled sometimes. :)

>Another option is to remove those entries, but I generally prefer to see
>as much detail about the remote host as possible, as there are often
>"rogue" daemons listening on ports one wouldn't expect - in particular
>ftpd and httpd are sometimes bound in strange places by their owners.

they can be yes, but see my previous posting about identifying
services. i see nmap as a tool to get a list of listening ports,
along with *suggestions* as to what services might be running on those
ports.

the services file that i've generated (i didn't do it by hand) prefer
iana entries over all else, and puts those names in to the left of
numbers for cases where the iana file has an entry. iana is
"supposed" to be authoritative. as it is, lots of people just grab a
random port for their homegrown service, with the assumption that it
won't interfere with anything. in most cases, it doesn't...unless
you're portscanning. :)

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior_at_daemon.org             * "ah!  i see you have the internet
twofsonet_at_graffiti.com (Andrew Brown)                that goes *ping*!"
andrew_at_crossbar.com       * "information is power -- share the wealth."
Received on Apr 21 2000
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos