CS 4740/6740: Network Security

Lab: Port Scanning

In this lab, you will be doing a bit of reconnaissance. You will be using a port scanner to identify potentially vulnerable services on a target. Your principal tool will be nmap. You will first find open ports on a machine, then try to identify the services running on those ports.

Late submissions will result in a 10% penalty per day (e.g., 2.5 days late result in 25% penalty)

1. Port Scanning Basics

You will be using nmap(1) to scan the machines on the network.

Read the man page on nmap(1) and become familiar the basic scan types and command line arguments. Pay particular attention to -sS, -sT, -sU and -sP.
Run a discovery scan using -sP against the IP range: 10.0.0.64/26 . Record the output of this command for your report.
You should have identified 2 systems in that IP range. Scan both systems at once with a full TCP connect() scan (-sT scan). Record the output for your report.
Scan both machines again, except this time use a TCP SYN scan (-sS). Record the output for your report.
Review the -p option in the nmap(1) man page. Use this option to scan UDP ports from 1 to 1024 of the two systems in question. Record the output of this command.

2. Fingerprinting

A common scan technique used by many port scanners is network fingerprinting. Gathering information about the operating system running on a host is very valuable to attackers as this can indicate what other software may be running on a system and therefore what public vulnerabilities may be open to exploit.

Network fingerprinting typically involves the analysis of different behaviors of a host to various types of requests. While TCP, UDP, ICMP, and IP are all more-or-less standardized based on IETF RFCs, there are almost always small differences in implementation. For instance default TTLs, TCP options fields, optional features, and even bugs on certain systems can help an attacker identify the implementation of the network protocol stack. Fyodor's site explains nmap operating system detection. Other references also explain fingerprinting techniques.

nmap utilizes a number of tests to make educated guesses as to the operating system of a scanned host. To enable these tests, use the -O option. Scan both hosts discovered in the previous section with the -O. Record the output of this scan.
The scan you just ran didn't send any information to these systems in the application layer. It merely probed the lower-layers of the protocol stack. Often it is much easier to use the application layer to determine directly what versions of software are running on a system, because many network daemons like to advertize themselves and even their version numbers in application-layer headers.

Use telnet to connect to port 80 on both systems you discovered in the previous section. Once you connect, type in the following line exactly:
```
GET / HTTP/1.0
		
```
and at the end of that line, press enter twice. You should be presented with an HTTP response, which consists of HTTP headers, followed by two blank lines, followed by the page content you requested. Look for a header line returned by the webservers which starts with the string "Server:". Obviously, this can be a much simpler way to determine what software is running on a host. However, these headers also much easier for systems administrators to disable. Record the headers returned by each server for your report.
Once again, nmap has a feature which automates this kind of banner-grabbing. Read the man page on the -sV option. Then, run a scan against the two discovered systems using the -sS and -sV options. Record the results of this scan. There are more references about how these service probes work..

2. Stealth Scanning

A sneaky method was developed in 1998 to perform spoofed scans through the information leak of IP ID numbers. IP IDs are a field in the IP header of packets which allows a recipient to piece together packets that get fragmented in transit. In order to function properly, these IDs need to be mostly unique, and many IP implementations simply increment a global counter for each packet sent out.

However, such an implementation leaks information about how many packets are being sent from a host. Using this leak, one can obtain the results of a spoofed TCP scan. Fyodor describes idle scanning in detail, along with an early post announcing the technique. We will first try this technique manually, then learn how to use nmap's automated idle scan feature.

You will use three machines for this experiment. The Windows machine you identified in the previous scan will be called the "zombie" or "zero traffic host". The Linux machine you identified in the previous scan will be known as the victim. Your team's Linux router will be the attacker.

Before you begin the stealth scan, you will be checking to make sure that the zombie is not receiving traffic at the time of your test. If it is, you will have to wait for a later time. If you can't seem to find a quiet time, please contact the Lab TA.

Open three seperate shell sessions to your Linux router. In the first session, setup your router to listen for ICMP echo reply packets. These packets will be used to check the IP ID on the zombie host. A suggested command line for this is:
```
tcpdump -v -i tap0 icmp[icmptype] == icmp-echoreply
		
```
In the second session, send a few packets to the zombie machine to determine if it is idle. A suggested command is:
```
ping -c 10 ZOMBIE_IP_ADDRESS
		
```
Back in the first session, you should see ten lines of output from tcpdump corresponding to the ten echo reply packets. The lines should look something like:
```
11:37:52.054397 IP (tos 0x0, ttl 128, id 6197, offset 0, 
   flags [DF], proto 1, length: 84) 10.0.0.X > 10.0.0.Y: 
   icmp 64: echo reply seq 376
		
```
Notice the id field in the IP headers section. This field is the IP ID and it should be incrementing by one for every line. If it is not, the zombie is not idle. Try this lab at another time.
Now, in the third ssh session window in your router, scan the victim on a single port, spoofing the source address to point to the zombie server. You can do this with nmap using a command line like:
```
nmap -P0 -sS -p PORT -e tap0 -S ZOMBIE_IP_ADDR VICTIM_IP_ADDR
		
```
You should first select PORT as a port you know is open on the VICTIM. This scan will send a single SYN packet to an open TCP port on the victim system, made to look like it came from the zombie machine.
Send a few more ICMP echo requests to the zombie host with the command:
```
ping -c 3 ZOMBIE_IP_ADDRESS
		
```
Return to the router session window in which tcpdump is running. Play close attention to the IP ID field. You should see a hole in the sequence between the packets from the first ping command and the last one. You can repeat the experiment several times. If you did everything right, you should notice the sequence skips one number for each time you run the scan. This is because the zombie system will respond with a RST packet to the SYN/ACK received from the victim system, which causes the system-wide ID to increment by one.

Record a snippet of the tcpdump output when the scan was run. Annotate the output to point-out holes in the IP ID sequence associated with your spoofed scan.

NOTE: nmap will report correct results of the scan, even though you didn't give your system's address as the source. Because of the current network configuration, nmap sees the responses even though they aren't technically destined for your Linux router. If you were using an idle host the same interface as the victim, nmap would likely show all ports as filtered, even though the IP IDs would indicate otherwise.
Run the experiment again, this time against a port which you know is closed. Watch the IP ID sequence and see if there are any holes. Repeat this several times to be sure; there shouldn't be a hole. This is because the victim will return a RST packet to the zombie host and the zombie host will not respond to a RST packet.
Fortunately, this labor-intensive scan technique has been automated in nmap. Read the man page's explanation of the -sI scan type. Run an idle scan against the same victim host, once again using the zombie host. Scan at least 5 TCP ports, some known to be open, and some known to be closed. Record the output of this scan.

Report

For this lab, your team must submit a report with the following information:

The output of your discovery scan.
The output of your full TCP connect() scan.
The output of your TCP SYN scan.
The output of your UDP scan.
The output of your operating system identification scan.
The output of your server header grab.
The output of your service probes.
The annotated snippet of your tcpdump showing the IP ID sequence hole.
The output of your nmap idle scan.
What method does nmap use by default to ping a host?
Describe how you could use icmp_ratelimit kernel parameter in Linux to slow down a UDP scan.
Which nmap scan typically runs faster, -sS or -sT? Why?
In general, if any port scanner sends a datagram to a specific UDP port on system and receives NO response, what can be concluded without any other information? (Hint: see the nmap man page, and consider networks which use firewalls.)
When running an idle scan against a victim, what happens if a specific port's SYN packets are dropped by the victim's firewall? How does this look to the attacker, compared to an open or closed port? If the scan target were running a tar-pit on every un-used TCP port, how effective would an idle scan be? For more background on this last question, you may want to search for "iptables TARPIT" on the web.
There are a number of ways that IP stacks can be written to reduce or eliminate the information leak of system-wide incremental IP IDs. How does Linux's IP stack defend against this? Name two techniques. See the "OS Vendors" section in this previously mentioned reference. How do these help defend against side-channel attacks?

Grading

Your grade for this lab will be composed of: