Increasingly, network scanning is becoming a cyclic process, primarily due to the finite amount of time you have to perform a network security assessment exercise and the fact that most firewalls repel fast SYN port scans.
The best practice approach to network scanning is to undertake the following:
Initial network scanning to identify poorly protected hosts and common services
Full scanning to identify all remotely accessible TCP and UDP services
Low-level network testing to gain insight into firewall and host configuration
In this section I perform these tests against the target 192.168.10.0/24 network. By coming up against the hurdles placed in my way by firewalls and defensive mechanisms, you will see how my approach is applied to get accurate results.
In Example 14-1, I use nmap with the -sP option to perform an initial sweep of the target network and identify any obvious accessible hosts that are poorly protected. If I don't specify the -PI option, nmap also sends TCP probes to port 80 of each host in the target range.
# nmap -sP -PI 192.168.10.0/24 Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) Nmap run completed -- 256 IP addresses (0 hosts up)
No results are seen from the initial ICMP probing, so I know that a filtering mechanism (such as a firewall or router) is dropping these packets. Filtering these initial probes forces me to scan each and every IP address for accessible services?a time-consuming process.
By performing enumeration to identify publicly accessible SMTP mail, DNS, or web servers, you should already have an idea of whether network services are accessible on certain hosts in the target address range. In Example 14-2, I use nmap to scan for a handful of common TCP services, specifying the -P0 option to skip ICMP ping and TCP port 80 sweeping, and forcefully scan all 256 addresses. Due to the number of hosts with no open ports, I also use the -oG option to push the nmap output in a format that can be used with grep to easily identify accessible services.
# nmap -sS -P0 -p21,25,53,80,110 -oG output.txt 192.168.10.0/24 < nmap output stripped for brevity > # grep open output.txt Host: 192.168.10.10 ( ) Ports: 21/closed/tcp//ftp///, 25/open/tcp//smtp///, 53/closed/tcp//domain///, 80/closed/tcp//http///, 110/closed/tcp//pop-3/// Host: 192.168.10.25 ( ) Ports: 21/closed/tcp//ftp///, 25/closed/tcp//smtp///, 53/closed/tcp//domain///, 80/open/tcp//http///, 110/closed/tcp//pop-3///
I then launch nmap to identify common UDP services. As discussed in Chapter 4, nmap performs UDP testing by sniffing for ICMP "destination port unreachable" responses from closed ports, and using a process of elimination to identify open ports. Example 14-3 shows nmap in use to identify UDP services.
# nmap -sU -P0 -p6,53,69,123,137,161 -oG output.txt 192.168.10.0/24 < nmap output stripped for brevity > # grep "6/closed" output.txt | grep open Host: 192.168.10.1 ( ) Ports: 6/closed/udp/////, 53/closed/udp//domain///, 69/closed/udp//tftp///, 123/open/udp//ntp///, 137/closed/udp//netbios-ns///, 161/open/udp//snmp///
UDP port 6 is used in this example as a dummy port. If a host is correctly responding with ICMP unreachable messages for closed ports, port 6 is closed. If you find that all hosts respond with nothing (i.e., an open response as far as nmap is concerned), you need to use a tool such as scanudp to send crafted datagrams to popular services and wait for positive responses (see Chapter 4).
Table 14-1 is a list of accessible hosts and services I have identified at this point. The next step is to investigate these accessible services fully, as well as identify peripheral services running on the same addresses.
UDP/123 (NTP) and UDP/161 (SNMP)
Probably a Cisco router
This initial stake in the ground allows me to move forward in an efficient way. Instead of waiting for long scans of non-existent hosts to finish, I have identified obvious services, which I can now investigate and expand upon, while running full scans in parallel.
Next, I perform full TCP and UDP scans to identify all accessible network services. nmap has some very useful features that can save a lot of time and effort later on, including the ability to sample IPID values, TCP sequence numbers, perform IP fingerprinting, and fingerprint accessible network services. This extra functionality can be easily enabled by specifying the -v and -A options.
Example 14-4 shows nmap performing a full TCP scan, including fingerprinting and low-level sampling of various values from the packets received.
# nmap -sS -P0 -p1-65535 -v -A -o output.txt 192.168.10.0/24 < nmap output stripped for brevity > # grep open output.txt #
In this case, nmap has returned no positive results. Many firewalls nowadays are set with SYN flood protection, which blocks SYN probes sent by network scanners, such as nmap and scanrand, especially if they are sent too quickly.
Using the -T Sneaky option to modify the timing policy within nmap, you can obtain accurate results from commercial firewalls (such as Check Point FW-1 and NG, Cisco PIX, NetScreen, and WatchGuard). The down side to this approach is that large networks can take days to scan.
nmap -sS -P0 -p1-65535 -v -A -T Sneaky -o output.txt 192.168.10.0/24
to scan the network, the output.txt log file shows a number of interesting results:
Interesting ports on 192.168.10.1: (The 65534 ports scanned but not shown below are: closed) PORT STATE SERVICE VERSION 23/tcp open telnet Cisco telnetd (IOS 12.X) Device type: router Running: Cisco IOS 12.X OS details: Cisco 801/1720 router running IOS 12.2.8 TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) IPID Sequence Generation: All zeros Interesting ports on 192.168.10.10: (The 65533 ports scanned but not shown below are: filtered) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 3.1p1 (protocol 2.0) 25/tcp open smtp Sendmail 8.11.6/8.11.6 Device type: general purpose Running: Sun Solaris 8 OS details: Sun Solaris 8 early access beta through actual release Uptime 250.224 days (since Tue Mar 04 12:47:21 2003) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) IPID Sequence Generation: Incremental Interesting ports on 192.168.10.25: (The 65532 ports scanned but not shown below are: filtered) PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS webserver 5.0 443/tcp open https? Device type: general purpose Running: Microsoft Windows 95/98/ME|NT/2K/XP OS details: Microsoft Windows 2000 Professional or Advanced Server TCP Sequence Prediction: Class=random positive increments Difficulty=5906 (Worthy challenge) IPID Sequence Generation: Incremental
The service version detection capability within nmap is excellent, with a large number of service fingerprints within Version 3.45 (at the time of writing). After performing full TCP scanning in this fashion, I have a very good idea of the target network, its entry points, and service software (OpenSSH 3.1p1, IIS 5.0, etc.).
By replacing the -sS with -sU, I can launch a full UDP scan of the target network. Example 14-5 shows nmap used to launch a UDP scan, along with results obtained from the output file. The -T Sneaky option isn't required; my UDP probes don't set off SYN flood protection and blocking.
# nmap -sU -P0 -p1-65535 -o output.txt 192.168.10.0/24 < nmap output stripped for brevity > # more output.txt Interesting ports on 192.168.10.1: (The 65533 ports scanned but not shown below are: filtered) PORT STATE SERVICE 123/udp open ntp 161/udp open snmpsnmp
By running nmap with -v -A options, I obtain results of IP ID and TCP sequence number generation, along with operating system, and uptime details. Example 14-6 reiterates these low-level results as reported by nmap.
Device type: general purpose Running: Sun Solaris 8 OS details: Sun Solaris 8 early access beta through actual release Uptime 250.224 days (since Tue Mar 04 12:47:21 2003) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) IPID Sequence Generation: Incremental
Operating-system and uptime details are guessed through responses to various probe packets. From a remote security perspective, I am interested in TCP and IP ID sequence generation and prediction, along with resilience to source routing attacks.
TCP initial sequence number (ISN) values are sampled by nmap, and class and difficulty ratings are derived based on the values received. If the ISN generation is sequential or based on time, the difficulty value decreases to a very small value, as shown here:
TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke)
If this is the case, a remote blind IP spoofing attack can be launched to establish a simple TCP connection to the target host and send traffic in one direction. Examples of TCP services that can be abused in this way include r-services, SMTP, and DNS (to execute unauthorized zone transfers). Brecht Claerhout wrote a useful white paper documenting blind IP spoofing attacks, along with working source code, which is available from http://examples.oreilly.com/networksa/tools/blind-spoof.html.
Over the three accessible hosts on the 192.168.10.0/24 network, none show weak TCP ISN sequence generation. An excellent graphical analysis of various operating platform ISN sequence generation algorithms can be found at http://razor.bindview.com/publish/papers/tcpseq.html.
If IP ID values sampled by nmap are incremental, it indicates the target host is relatively idle. This behavior can be abused to perform IP ID header scanning, as discussed in Chapter 4. Of the three hosts scanned during this exercise, two returned incremental IP ID values, and the Cisco router at 192.168.10.1 returned IP ID values of zero each time.
IP ID header scanning can launch accurate spoofed TCP port scans, and also reverse engineer target network firewall and filtering rules. Example 14-7 shows how to use nmap a bounce to port scan from 192.168.10.10 to 192.168.10.1.
# nmap -P0 -sI 192.168.10.10 192.168.10.1 Starting nmap 3.45 ( www.insecure.org/nmap/ ) Idlescan using zombie 192.168.10.10; Class: Incremental Interesting ports on (192.168.10.1): (The 1598 ports scanned but not shown below are: closed) Port State Service 25/tcp open smtp 80/tcp open http Nmap run completed -- 1 IP address (1 host up)
The Cisco router (192.168.10.1) is effectively being scanned from the Solaris mail server (192.168.10.10). nmap reveals that the Cisco device allows web connections to TCP port 80 from the Solaris host, along with the Telnet service that is open to the Internet.
Testing for source routing issues should be carried out after assessing the risks associated with TCP ISN and IP ID sequence generation. Example 14-8 uses lsrscan to test the accessible services for source routing vulnerabilities.
# lsrscan -d 23 192.168.10.1 192.168.10.1 does not reverse LSR traffic to it 192.168.10.1 does not forward LSR traffic through it # lsrscan -d 22 192.168.10.10 192.168.10.10 does not reverse LSR traffic to it 192.168.10.10 does not forward LSR traffic through it # lsrscan -d 25 192.168.10.10 192.168.10.10 does not reverse LSR traffic to it 192.168.10.10 does not forward LSR traffic through it # lsrscan -d 80 192.168.10.25 192.168.10.25 does not reverse LSR traffic to it 192.168.10.25 does not forward LSR traffic through it # lsrscan -d 443 192.168.10.25 192.168.10.25 does not reverse LSR traffic to it 192.168.10.25 does not forward LSR traffic through it
If source routing vulnerabilities are identified, lsrtunnel can be used to proxy attack traffic to the target service, as detailed in Chapter 4.
In more complex environments, in which nmap reports that ports are closed or unfiltered, tools such as hping2, firewalk, and tcpdump can analyze responses from the target network. An example of this is to analyze TTL values of RST packets received from the target network because you can identify at what point packets are being rejected, whether by a border router, firewall, or the target host itself. Chapter 4 discusses these tests in detail along with various examples.