IDFAQ: RPC and NMAP Patterns

Some of the RPC scanning activity is probably generated by NMAP, Daniel Ayers describes the tool and its pattern on the net in this analysis brief.

NMAP (by Fyodor, http://www.insecure.org/nmap/) is a flexible and widely used UNIX-based network scanner. It supports a range of scanning modes (standard TCP connect(), SYN, FIN, etc) and is also capable of detecting the type of host being scanned using TCP stack fingerprinting.

Recently, NMAP was enhanced further to support scanning for RPC services. NMAP bypasses the portmapper and submits RPC queries direct to any open TCP or UDP ports. RPC scans may be combined with TCP and UDP scans.

Let's start by looking probably the most commonly used NMAP scanning mode, the SYN stealth scan. This is a standard SYN scan, using crafted SYN packets to solicit a SYN+ACK response from open ports on the scanned host.

This is a TCP SYN stealth scan between ports 78 and 85 against a machine known to be running web servers on ports 80 and 81. A SYN+ACK is received on 80 and 81 indicating that those ports are open on the target host. The scanning machine's TCP/IP stack responds with a RST because it is not aware of the connection (remember - the packets are crafted by NMAP).

Points to note about this trace:

Destination ports are in a random order. This is designed to confuse simple IDS systems.

Source port is constant for a few packets, and then increments.

ISN (Initial Sequence Numbers) are also constant for a few packets and then change, but the
pattern repeats.

IP ID numbers are random.

TCP window sizes are constant during the scan. (Actually they window size is chosen randomly
at the start of the scan and will always be 1024, 2048, 3072 or 4096 octets. This is another
attempt to evade IDS systems).

The initial TTL is constant during the scan. (This trace was captured from the scanning machine.
The initial TTL is also chosen randomly at the start of the scan, and will vary from 37 to 59.
A further attempt to evade detection).

This pattern makes NMAP SYN scans quite easy to identify. The signature is so distinctive because
NMAP performs the SYN scan using crafted packets.

NMAP performs the old-style TCP connect() scanning using the operating system TCP/IP stack and
system calls. This actually makes NMAP TCP connect() scans much harder to identify in the wild
because most of the parameters in the IP datagrams are set by the host TCP/IP stack. NMAP scans
from different operating systems will look different.

Source port is random. This is normal OpenBSD behaviour. Many systems will simply increment
the source port.

ISNs increment as they should.

IP IDs are random - normal OpenBSD behaviour. Many systems just increment the IP ID when a datagram is transmitted.

TCP window size is 16384 octets, and there are many TCP options included in the connection request. Again, this is OpenBSD behaviour and is not related to NMAP.

The initial TTL, set by OpenBSD, is 64.

Clearly it will be easier to identify the host OS in this scan (OpenBSD) than the tool in use
(NMAP).

Notice that the connections on ports 80 and 81 come fully open, but no data is transmitted. (The numbers in brackets following the sequence numbers is the number of TCP data octets in the packet. All are zero in this example). The successful connection will often result in a log entry on the scanned host, which is why connect() scanning is considered "less stealthy".

If a TCP or UDP scan is combined with an RPC scan, the TCP/UDP scan occurs first and any open ports
discovered are probed for RPCs. The RPC probes are full TCP connections (via connect(), not crafted
packets) and data is sent down the connection in the form of RPC requests.

Here is an example of a scan for TCP RPC services. (This example is actually the second half of the
first example, the SYN scan):

As the TCP connections are initiated through the host TCP/IP stack, many parameters of the
datagrams follow the host's characteristics rather than the tool's - just as for the connect()
TCP scan.

Connections are only attempted on those ports that were determined by the first part of the scan
to be open - in this case, ports 80 and 81.

The connections come fully open AND DATA IS SENT. (Notice that the numbers in brackets after the sequence numbers are nonzero and the relative sequence numbers increase during the connection). You generally see little or no data being sent by the scanned system in response, unless the connection is actually an RPC program.

SUMMARY

-------

NMAP stealth SYN TCP scans are fairly easy to identify in the wild.

NMAP TCP connect() and RPC scans are harder to identify in themselves, but there are a few big clues to watch out for:

A full port scan (TCP connect(), SYN, etc) followed by a second scan only of the ports
you have open.

A port scan where the same data is sent to each open port.

If you see both of those at the same time, that is a really big clue that someone is using NMAP to find out about your RPC services.

For completeness, the following is a hex dump of NMAP's scanning of one of the TCP ports for RPC services. (This was a web server, so there were no RPC services present).