Team LiB
Previous Section Next Section

3.2. Adding Service Signatures to Nmap

Recent versions of the popular port scanner Nmap can detect the type and version of services running on a network, as illustrated in Example 3-2.

Example 3-2. Example Nmap version scan
>nmap -sV 127.0.0.1  

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2003-07-05 17:12 EDT
Interesting ports on localhost (127.0.0.1):
(The 1658 ports scanned but not shown below are in state: closed)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 3.8.1p1 (protocol 2.0)

Nmap run completed -- 1 IP address (1 host up) scanned in 1.104 seconds

This scan is implemented as a series of probes and responses in the file nmap-service-probes. This file defines the probes that will be sent to the service to elicit some response, as well as a series of regular expressions against which to match responses to determine which services are running and, where possible, their versions.

At a high level, the version-scanning methodology follows this process:

  • If the port is a TCP port, connect to it and listen. This is called the NULL probe. Many services will return a banner on connection. If a match is made, processing stops.

  • If no match is given, or if the protocol is UDP, probes defined in the nmap-service-probes file will be attempted if the protocol and the port ranges in the file match. If a response matching a probe is found, processing stops. If a soft match occurs (whereby a service is recognized, but not its type or version), follow-on probes will be limited to relevant ones.

  • If no match is found, each probe in the nmap-service-probes file will be tried, regardless of the ports on which the service usually runs. This will be limited where a soft match has already occurred.

  • If SSL was found, Nmap will connect using SSL (if available) to run the version-detection process again.

If a service responds to a probe sent during this process, but Nmap does not recognize the response, Nmap prints a fingerprint for the service that you can use to report the signature to the Nmap developers, as shown in Example 3-3. You can use this, together with the version and service information, to include a signature that recognizes this service in the nmap-service-probes file in the future.

Example 3-3. Nmap unrecognized service
>nmap -sV -p 4738 127.0.0.1

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2003-07-05 17:39 EDT
Interesting ports on localhost (127.0.0.1):
PORT     STATE SERVICE VERSION
4738/tcp open  unknown
1 service unrecognized despite returning data. If you know the service/version, 
please submit the following fingerprint at http://www.insecure.org/cgi-bin/
servicefp-submit.cgi :
SF-Port4738-TCP:V=3.50%D=7/5%Time=40E9CA80%P=i686-pc-linux-gnu%r(NULL,59,"
SF:Login\x20with\x20USER\x20<name>\x20followed\x20by\x20PASS\x20<password>
SF:\x20or\x20ANON\r\nCheck\x20privileges\x20with\x20PRIVS\r\n")%r(GenericL
SF:ines,59,"Login\x20with\x20USER\x20<name>\x20followed\x20by\x20PASS\x20<
SF:password>\x20or\x20ANON\r\nCheck\x20privileges\x20with\x20PRIVS\r\n")%r
SF:(GetRequest,59,"Login\x20with\x20USER\x20<name>\x20followed\x20by\x20PA
SF:SS\x20<password>\x20or\x20ANON\r\nCheck\x20privileges\x20with\x20PRIVS\
SF:r\n")%r(HTTPOptions,59,"Login\x20with\x20USER\x20<name>\x20followed\x20 
SF:by\x20PASS\x20<password>\x20or\x20ANON\r\nCheck\x20privileges\x20with\x
<cut>

Nmap run completed -- 1 IP address (1 host up) scanned in 75.504 seconds

At this point we have several options:

  • Submit the signature to the URL provided and wait for the next version of Nmap. If responses were received from the probes sent, and the service is something that could be expected to be running on someone else's environment, this might be the best choice.

  • Create a working match and/or probe statement, and submit that to Fyodor at fyodor@insecure.org. For services that require a custom probe and can be expected to be found in another environment, this might be the best choice.

  • Create a working match and/or probe statement for your own use. You might choose this option if your environment contains custom-written software running proprietary services or protocols. In this case it is necessary to know how to write the probes and matches to detect these proprietary services running on the environment being tested.

Regardless of which option you choose, it is very useful to know how to write your own probe and match signatures.

3.2.1. The nmap-service-probes File

The keywords contained in the nmap-service-probes file are listed in Table 3-5.

Table 3-5. nmap-service-probes keywords

Keyword

Format

Probe

Probe <protocol> <probe name> <probe string>

match

match <service> <pattern> [version info]

softmatch

softmatch <service> <pattern>

ports

ports <portlist>

sslports

sslports <portlist>

Totalwaitms

totalwaitms <milliseconds>


3.2.1.1 Probes

A probe entry consists of the values shown in Table 3-6.

Table 3-6. Probe values

Parameter

Description

Protocol

TCP or UDP.

Probe name

Name of the probe (human-readable).

Probe string

String starting with a q, then a delimiter that will start and end the string sent. The string can consist of printable characters, as well as quoted unprintable characters and control characters in standard C or Perl notation.


Here are some example probe strings:


Probe TCP NULL q||

Send nothing, waiting the amount of time specified in totalwaitms.


Probe TCP GenericLines q|\r\n\r\n|

Send carriage return, newline, carriage return, newline.


Probe UDP DNSStatusRequest q|\0\0\x10\0\0\0\0\0\0\0\0\0|

Send the binary string 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00.

3.2.1.2 Matches

A match entry consists of the values defined in Table 3-7.

Table 3-7. Match values

Parameter

Description

Service

Name of the service the pattern matches.

Pattern

A Perl-compatible regular expression to match the expected response for this service. This is of the format m/regex/opts.

Version info

A field specifying additional version information. This is of the format v/product name/version/info/. This can contain variables matched from the matching pattern, such as $1, $2, where the matching pattern contains ( ) matches. Any or all entries can be empty.


Nmap uses the Perl Compatible Regular Expressions (libpcre) library for evaluating regular expressions. Perl regular expressions are documented at http://www.perldoc.com/perl5.8.0/pod/perlre.html.

Here are some example match strings:


match ssh m/^SSH-([.\d]+)-OpenSSH[_-](\S+)/ v/OpenSSH/$2/protocol $1/

Match strings such as SSH-1.5-OpenSSH-3.4p1, reading the version string (3.4p1) and protocol (1.5) into the $2 and $1 variables, respectively.


match ftp m/^220[- ].*FTP server \(Version (wu-[-.\w]+)/s v/WU-FTPD/$1//

Match strings such as 220 FTP server (Version wu-2.6.0) and extract the version wu-2.6.0.


match mysql m/^.\0\0\0\n(4\.[-.\w]+)\0...\0/s v/MySQL/$1//

Match the version of MySQL 4.x from the binary response.

3.2.1.3 Soft matches

A soft match occurs when a service can be identified, but no additional information can be derived. A soft-match entry consists of the values defined in Table 3-8.

Table 3-8. Soft-match values

Parameter

Description

Service

Name of the service the pattern matches.

Pattern

A Perl-compatible regular expression to match the expected response for this service. This is of the format m/regex/opts.


Here are some example soft-match strings:

  • softmatch ftp m/^220[- ].*ftp server.*\r\n/i

  • softmatch imap m/^\* OK [-.\w,:+ ]+imap[-.\w,:+ ]+\r\n$/i

3.2.1.4 ports

ports is a comma-separated list of ports, as well as port ranges (e.g., 35067-35090) on which the service will commonly run. This is used to ensure that probing is done efficiently, and therefore the ports entry should follow the Probe entry in nmap-service-probes.

3.2.1.5 sslports

sslports is a comma-separated list of ports, as well as port ranges (e.g., 55522-55525) on which the service will commonly run over SSL. This is used to ensure that probing is done efficiently, and therefore the sslports entry should follow the Probe and ports enTRies in nmap-service-probes.

3.2.1.6 totalwaitms

totalwaitms is used to specify the timeout for a Probe. It is not needed unless the service you are probing does not respond immediately. If it is used, it should follow the Probe entry.

    Team LiB
    Previous Section Next Section