|
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. Here's a sample NMAP SYN scan and associated tcpdump output: % nmap -P0 -sS -p78-85 192.168.1.1 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:
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. Here is an NMAP TCP connect() scan from an OpenBSD 2.5 system: n class=code> % nmap -P0 -sT -p78-85 192.168.1.1 10:56:19 172.20.1.1.20365 > 192.168.1.1.80: S 4096531040:4096531040(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 15568) 10:56:19 172.20.1.1.12145 > 192.168.1.1.79: S 4096546916:4096546916(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 5534) 10:56:19 172.20.1.1.18707 > 192.168.1.1.83: S 4096554384:4096554384(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 30006) 10:56:19 172.20.1.1.11496 > 192.168.1.1.85: S 4096604988:4096604988(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 25118) 10:56:19 172.20.1.1.34877 > 192.168.1.1.81: S 4096663100:4096663100(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 26945) 10:56:19 172.20.1.1.8426 > 192.168.1.1.78: S 4096677617:4096677617(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 10613) 10:56:19 172.20.1.1.48206 > 192.168.1.1.84: S 4096712665:4096712665(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 1824) 10:56:19 172.20.1.1.43184 > 192.168.1.1.82: S 4096765358:4096765358(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406102 0> (ttl 64, id 20815) 10:56:20 192.168.1.1.80 > 172.20.1.1.20365: S 2955488721:2955488721(0) ack 4096531041 win 1024 <mss 1460> (DF) (ttl 114, id 9608) 10:56:20 172.20.1.1.20365 > 192.168.1.1.80: . ack 1 win 16384 (ttl 64, id 406) 10:56:20 172.20.1.1.20365 > 192.168.1.1.80: R 1:1(0) ack 1 win 0 (ttl 64, id 31087) 10:56:20 192.168.1.1.81 > 172.20.1.1.34877: S 2955488364:2955488364(0) ack 4096663101 win 1024 <mss 1460> (DF) (ttl 114, id 9864) 10:56:20 172.20.1.1.34877 > 192.168.1.1.81: . ack 1 win 16384 (ttl 64, id 10544) 10:56:20 172.20.1.1.34877 > 192.168.1.1.81: R 1:1(0) ack 1 win 0 (ttl 64, id 29338) 10:56:20 172.20.1.1.35736 > 192.168.1.1.79: S 4096829741:4096829741(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406103 0> (ttl 64, id 16211) 10:56:20 172.20.1.1.23922 > 192.168.1.1.83: S 4096888063:4096888063(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406103 0> (ttl 64, id 11439) 10:56:20 172.20.1.1.9977 > 192.168.1.1.85: S 4096930837:4096930837(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406103 0> (ttl 64, id 16913) 10:56:20 172.20.1.1.30364 > 192.168.1.1.78: S 4096931462:4096931462(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406103 0> (ttl 64, id 4560) 10:56:20 172.20.1.1.16933 > 192.168.1.1.84: S 4096965847:4096965847(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406103 0> (ttl 64, id 12154) 10:56:20 172.20.1.1.19365 > 192.168.1.1.82: S 4097007100:4097007100(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406103 0> (ttl 64, id 23414) 10:56:20 172.20.1.1.8558 > 192.168.1.1.79: S 4097072333:4097072333(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 30979) 10:56:20 172.20.1.1.10392 > 192.168.1.1.83: S 4097114681:4097114681(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 23805) 10:56:20 172.20.1.1.45297 > 192.168.1.1.85: S 4097170862:4097170862(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 16011) 10:56:20 172.20.1.1.13264 > 192.168.1.1.78: S 4097221243:4097221243(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 17356) 10:56:20 172.20.1.1.38705 > 192.168.1.1.84: S 4097226803:4097226803(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 28926) 10:56:20 172.20.1.1.21255 > 192.168.1.1.82: S 4097235392:4097235392(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 2097) 10:56:20 172.20.1.1.12105 > 192.168.1.1.82: S 4097251193:4097251193(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 2880) 10:56:20 172.20.1.1.43229 > 192.168.1.1.84: S 4097258290:4097258290(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 5538) 10:56:20 172.20.1.1.30085 > 192.168.1.1.78: S 4097300637:4097300637(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 13978) 10:56:20 172.20.1.1.2161 > 192.168.1.1.85: S 4097312766:4097312766(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 31544) 10:56:20 172.20.1.1.22608 > 192.168.1.1.83: S 4097357637:4097357637(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 7895) 10:56:20 172.20.1.1.16605 > 192.168.1.1.79: S 4097410745:4097410745(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406104 0> (ttl 64, id 26786) 10:56:21 172.20.1.1.7455 > 192.168.1.1.82: S 4097471276:4097471276(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406105 0> (ttl 64, id 29609) 10:56:21 172.20.1.1.38963 > 192.168.1.1.84: S 4097510285:4097510285(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406105 0> (ttl 64, id 26241) 10:56:21 172.20.1.1.32922 > 192.168.1.1.78: S 4097523123:4097523123(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406105 0> (ttl 64, id 17252) 10:56:21 172.20.1.1.41428 > 192.168.1.1.85: S 4097541252:4097541252(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406105 0> (ttl 64, id 14265) 10:56:21 172.20.1.1.35884 > 192.168.1.1.83: S 4097545052:4097545052(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406105 0> (ttl 64, id 1832) 10:56:21 172.20.1.1.40400 > 192.168.1.1.79: S 4097565579:4097565579(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406105 0> (ttl 64, id 18442) 10:56:21 172.20.1.1.25181 > 192.168.1.1.82: S 4097617854:4097617854(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406106 0> (ttl 64, id 2438) 10:56:21 172.20.1.1.37460 > 192.168.1.1.84: S 4097669306:4097669306(0) win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 406106 0> (ttl 64, id 548) Note that:
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): % nmap -P0 -sS -sR -p78-85 192.168.1.1 Notice that:
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:
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). 10:54:11.209054 172.20.1.1.29850 > |