Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Port rules for unmatched services
From: David Fifield <david () bamsoftware com>
Date: Mon, 5 Aug 2013 16:45:02 -0700

On Fri, Jun 07, 2013 at 11:59:38PM +0200, Marin Maržić wrote:
- On another note, when I tried to make version scripts run for any as
of yet unidentified port (like normal probes would with --version-all),
it wasn't that straightforward. I came across this bit in
http://nmap.org/book/nse-api.html#nse-api-arguments:
"port.service
    Contains a string representation of the service running on
port.number as detected by the Nmap service detection. If the
port.version field is nil, Nmap has guessed the service based on the
port number. Otherwise version detection was able to determine the
listening service and this field is equal to port.version.name."

Thought that maybe the mentioned fields could help determine if it was a
guess or not, but this came up when testing (debug output at the start
of a portrule) the 4 possible combinations:

- port without an nmap-services entry, and no regex rule match:
NSE: port.service=nil
NSE: port.version=not nil
NSE: port.version.name=nil
NSE: port.version.name_confidence=3

PORT      STATE         SERVICE REASON      VERSION
62314/udp open|filtered unknown no-response

- port without an nmap-services entry, and there is a regex rule match:
NSE: port.service=murmur
NSE: port.version=not nil
NSE: port.version.name=murmur
NSE: port.version.name_confidence=10

PORT      STATE SERVICE REASON       VERSION
62314/udp open  murmur  udp-response Murmur 1.2.X

- port (80) with a nmap-services entry (http), and no regex rule match:
NSE: port.service=http
NSE: port.version=not nil
NSE: port.version.name=http
NSE: port.version.name_confidence=3

PORT   STATE         SERVICE REASON      VERSION
80/udp open|filtered http    no-response

- port (80) with a nmap-service entry (http), and there is a regex rule
match:
NSE: port.service=murmur
NSE: port.version=not nil
NSE: port.version.name=murmur
NSE: port.version.name_confidence=10

PORT   STATE SERVICE REASON       VERSION
80/udp open  murmur  udp-response Murmur 1.2.X

Some conclusions from this:
- port.version is never nil (guess or not)
- port.service and port.version.name are always equal (guess or not)
- port.version.name_confidence is never nil; it is 3 when a guess was
made and it is 3 even when no guess can be made, it is 10 on a match
- if a port number has an entry in nmap-services, port.service and
port.version.name will be set to it. This is why, for example, the Skype
version script can never work against port 80 (it's set to "http"), or
against any other port with an entry in nmap-services that isn't
"unknown" or "".

Then it seems that the following type of port rule would best emulate a
normal probe that runs on any open or open|filtered, and as of yet
unidentified port (udp in this case):
portrule = function(host, port)
    return port.version.name_confidence ~= 10
        and not shortport.port_is_excluded(port.number, "udp")
end

Thanks for noticing this. It was a bug that skypev2-version didn't run
against ports 80 and 443. Looking at port.version.name_confidence is
probably the right thing to do here.

David Fifield
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
  • Port rules for unmatched services David Fifield (Aug 05)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]