Penetration testing

Snort network recon techniques

Lab 2: Network Recon

In this lab, we will examine some popular network recon techniques and practice writing Snort rules for their detection.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Exercise 1: Network discovery

Nmap is by far one of the most popular tools in the world of information security. This popularity can be attributed to many factors. One of which is the fact that it is extremely effective. Nmap was introduced as a port scanner, but it's far outgrown that title at this point. We will be using it in this exercise to make a basic Network Discovery. We will start with a ping scan. Enter the following to discover all the devices on your network. Remember your network might be in a different range than the example. So make sure you're scanning your actual network range.

nmap -sP 192.168.x.0/24

As we can see, there appears to be six hosts up (you may have a different number depending on which VMs you have running). This is the most basic Nmap scan, and it is designed strictly to tell which hosts are actually "up." Remember our first rule? It is supposed to detect pings. Let's enable it and see if it will work. On your Ubuntu Server VM, open the local.rules file if you don't have it open already:

sudo gedit /etc/snort/rules/local.rules

Un-comment our first rule (remove the "#" symbol) and save the file. Now run Snort in IDS mode.

sudo snort -A console -q -c /etc/snort/snort.conf -i eth0

Now run the Nmap ping scan again:

nmap -sP 192.168.x.0/24

Do you see any alerts from Snort? No? Hmm… Let's have a closer look at what Nmap is doing. We will run the same command, except this time we'll use the --packet-trace option. This option is good for learning about the different types of Nmap scans as you run them. It essentially causes Nmap to output to the screen all requests that it sends to targets, as well as responses from the targets. Enter the command into your Kali Linux terminal as follows:

nmap -sP 192.168.95.0/24 –-packet-trace

Well, that explains it. As we can see, Nmap was sending out ARPs and not pings. This is because you were scanning your internal network, and Nmap is smart enough to know that ARPs will work since we're scanning the same layer two network. If you continue to scroll past all the ARPs, you'll eventually see responses from the machines on the network that are up. See below.

And then finally, you should see the same output you see if you would have left off the packet trace option. To force Nmap to use pings, modify the command as follows:

nmap -sP 192.168.x.0/24 –-disable-arp-ping

These options tell Nmap to use ICMP Echo requests (-PE) and disable ARP pinging. Check your Snort output. We're back in business.

However, there is a possible false positive issue with our rule: it will alert on all pings, so if you are not blocking ICMP requests on your network, legitimate pinging will also generate alerts. Make sure your Snort is still running. Go to your Windows Server 2012 R2 VM, open command prompt and enter ping 192.168.x.x (using your Ubuntu Server IP address). You will see alerts from Snort.

We need to find out whether Nmap pings are different from regular pings (in other words, do they have a signature we can use in our rule?) To do that, we need to capture some traffic. On your Ubuntu Server VM, hit Ctrl+C to stop Snort and enter sudo wireshark. So far we've been using it to look at traffic captures. Now let's see how the live traffic capture works. From the Wireshark main window, select eth0 from the Interface List and click Start (or the green shark fin icon on the top menu bar).

You may or may not see any traffic right away, depending on your lab setup. Go to your Kali Linux VM and re-issue the ping sweep command:

nmap -sP 192.168.x.0/24 –-disable-arp-ping

From your Windows Server VM, re-issue the ping command.

ping 192.168.x.x

Now go back to your Wireshark and select the red stop button from the top menu to stop the capture. Scroll through the captured packets. You will most likely have quite a few, so we have to filter the results. Enter the following value into the Filter field on top using the IP address of your Ubuntu Server VM

ip.dst==192.168.x.x && icmp

We are telling Wireshark only to show ICMP packets with the destination IP or our Ubuntu Server. Click Apply. We can see the difference right away:

Packet length is 60 for the ping that came from Nmap and 74 for the regular one. Click on the Nmap packet and scroll all the way to the bottom of the middle pane. Now do the same for any of the regular ping packets. You will see that there is no payload (Data) in ICMP Echo request packet generated by Nmap. We can use that finding for our rule. Bring up the local.rules file, copy the very first rule and paste it into a new line on the bottom. Comment out the first rule again. Now modify our new rule as follows:

alert icmp any any -> $HOME_NET any (msg:"Possible Nmap ping sweep"; dsize:0; sid:1000005; rev:1;)

Save the file. Start Snort in IDS mode (you may need to open another terminal shell). Now let's re-issue our pings but do it in reverse order: first ping from the Windows Server 2012 R2 and check your Snort output. You shouldn't see any alerts. Now perform the Nmap ping sweep from Kali Linux and look at the Snort output. Our rule is working.

Exercise 2: Port scanning with Nmap

In this exercise, we will do basic port scanning. These exercises are designed to get you more familiar with the process of port scanning using Nmap. Here's the definition of connecting scanning from the Nmap website:

"This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn't reachable. One strong advantage to this technique is that you don't need any special privileges. Any user on most UNIX boxes is free to use this call."

Reference: http://nmap.org/nmap_doc.html

Go to your Kali Linux VM and enter the following command to scan your Windows Server 2012 R2 VM. Observe the output.

nmap -sT 192.168.x.x –-packet-trace

As for the results you should see a pretty long list of open ports. Most of these ports are standard ports for a Windows 2012 Active Directory Services Domain controller, which is what your Windows Server 2012 R2 VM is. Some common ones are 21 for FTP, 23 Telnet, 53 DNS, 80 HTTP, 88 Kerberos, 135,139, and 445, which are common Windows ports, 389 LDAP, and several others for Global Catalog services.

Now try running a TCP Connect scan against two devices in your network. Use your Windows Server 2012 R2 VM and your Kali Linux VM (yes, Nmap can even scan the server from which it's running!) See the example scan below.

nmap -sT 192.168.x.y,z

In the above example, we're scanning the IP addresses of 192.168.132.136 and 192.168.132.133, which are Windows Server 2012 R2 VM and Kali Linux VM. It's important to note that Nmap is not attempting to scan all ports. The ports scanned by default are the 1000 most commonly used ports. You should see that for your Windows Server 2012 R2 VM IP address, all the ports you saw earlier are open. On the Kali Linux VM, you should see that it reports all ports as closed.

The reason you don't see any open ports on our Kali Linux VM is because there are no common services listening on any ports. Let's start a common daemon and see if it changes our scan results. On the Kali Linux VM, click the Applications dropdown at the top of the screen. Now select Kali Linux > System Services > HTTP > apache2 start.

This starts up an Apache server which will listen on port 80. Now do the scan we just did again. Do you see any ports show up as open for the Kali Linux VM IP now? You should see port 80 show as open now. See below.

This should give you a clear illustration of how running services or daemons relate to open ports. Go ahead and stop the Apache server now: Applications > Kali Linux > System Services > HTTP > apache2 stop.

Since this scan uses TCP against common ports, we can detect it by writing a rule that detects an attempted TCP connection with a port we know is closed. In our case, we can use port 23, which is telnet. Bring up (or reopen as root) the local.rules file and add the following rule on a new line:

alert tcp any any -> $HOME_NET 23 (msg:"TCP Port Scanning"; sid:1000006; rev:1;)

Save the file and start Snort in IDS mode. Now go to your Kali Linux VM and scan your Windows Server 2012 R2 VM again.

nmap -sT 192.168.x.x

Check your Snort output. You should see alerts generated (some of them will be for the FTP connection rule we created earlier):

Another way to detect port scanning is by alerting on an unusual number of connection requests within a short period. For that, we can use Snort's detection_filter rule option. Bring up the local.rules file. Copy our last "TCP Port Scanning" rule and paste it into a new line. Now modify it as follows:

alert tcp any any -> $HOME_NET any (msg:"TCP Port Scanning"; detection_filter:track by_src, count 30, seconds 60; sid:1000006; rev:2;)

Here we are using detection filter to generate an alert whenever there are more than 30 TCP connections are attempted within a 60-second interval.

Next, let's comment out our "TCP Port Scanning" rule rev:1 and the "FTP connection attempt" rule to reduce our output a bit. Save the file and start Snort in IDS mode. Go to your Kali Linux VM. First, let's try a scan that shouldn't generate any alerts with our revised rule. Issue the following command only to scan port 21 on the Windows Server 2012 R2 VM:

nmap -sT 192.168.x.x -p 21

Check your Snort output. You shouldn't see any alerts (if you disabled the "FTP connection attempt" rule). No go back to Kali Linux and remove the port option.

nmap -sT 192.168.x.x

Check the Snort output now.

Our rule is working. However, you can see the issue here. Alerts are being generated for every connection attempt. Imagine if a large network is being scanned. We need to find a way to limit the number of alerts generated by this rule. We cannot do it in the rule itself; we need to do something a little more complicated. Stop Snort (Ctrl+C) and open the threshold.conf file in a text editor as root:

sudo gedit /etc/snort/threshold.conf

(If you have the local.rules file open; it will open as a new tab in the same window.) Scroll all the way to the bottom, and add the following code on a new line:

event_filter gen_id 1, sig_id 1000006, type limit, track by_src, count 1, seconds 60

See below.

This command tells snort to limit the alerts for the rule with the sid of 1000006 to 1 per every 60 seconds. Save the file. Let's see if it works. Start Snort in IDS mode, then go to Kali Linux and reissue the TCP port scan command. Check Snort output.

Now, that's better (we get two alerts because the attacking machine is on the HOME_NET as well, so packets received by it are being looked at as well). Stop Snort. You can use Snort filters to drop packets when a suspected attack is detected, but we will look at that later when we talk about Session Sniping.

So far we've been examining reliable scanning techniques that aren't concerned with being discovered. Let's move on to the next exercise, which involves stealthy scanning.

Exercise 3: Stealthy scanning

Step1 - Timing

As we just saw, one of the first things that sets off an IDS when scanning is the number of packets sent in a short amount of time. Nmap is known for being a very fast port scanner, and ironically, this speed is sometimes the very thing that makes a scan detectable.

Nmap has several "canned" speed adjustment options. If we wanted to slow our scan down we could use the -T option to specify one of these canned speeds. Go to your Kali Linux VM and scan your Windows Server 2012 R2 VM for ports 80 and 135 with a speed timing option of sneaky. Enter the following command:

nmap -sT 192.168.x.x –p 80,135 –T sneaky

Take note of the time it takes for this scan to finish (in the example, it took about 45 seconds). See below.

Now repeat the scan, except this time use the timing option of insane, which is much faster.

nmap -sT 192.168.x.x –p 80,135 –T insane

Much faster, right? Which scan do you think is less likely to set off an IDS? As we can see the –T option changes the rate at which the scan finishes. This is because it's slowing down the speed at which the probing packets are being sent. The canned speeds are paranoid, sneaky, polite, normal, aggressive, and insane. If this is not granular enough, Nmap allows you to specify your scan delay speed using the --scan-delay option. Go ahead and enter the command below to send a probe every 5 seconds.

nmap –sT 192.168.x.x –p 80,135 --scan-delay 5s

That's about 5 seconds per port which in this case was two ports + an initial five delay. That means 15 seconds. Now change the scan delay speed to 1 second.

nmap –sT 192.168.x.x –p 80,135 --scan-delay 1s

It should be noticeably faster, somewhere around 3 seconds. We can also pass the speed argument in the form of milliseconds. Try this:

nmap –sT 192.168.x.x –p 80,135 --scan-delay 5ms

That is five milliseconds, and you should notice it finishes much faster. The actual speeds could vary based on network conditions, configurations, etc. So if you speeds don't match the ones you see above, it's all good. Keep this in mind when configuring your Snort detection filters.

Step 2 - Stealth TCP scanning

Nmap provides several methods to perform stealth TCP scanning. We'll be taking an in-depth look at several of them. First up is the most popular SYN Scan. Let's see what the Nmap man page has to say about the SYN Scan:

"This technique is often referred to as half-open scanning because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and then wait for a response. A SYN/ACK indicates the port is listening (open), while a RST (reset) is indicative of a non-listener. If no response is received after several retransmissions, the port is marked as filtered. The port is also marked filtered if an ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, or 13) is received. The port is also considered open if a SYN packet (without the ACK flag) is received in response. This can be due to an extremely rare TCP feature known as a simultaneous open or split handshake connection."

Reference: https//svn.nmap.org/nmap/docs/nmap.1

Try performing a SYN Scan against your Windows Server 2012 R2 VM:

nmap –sS 192.168.x.x

Results should be the same as we saw earlier with the basic TCP Connect Scan. Our "TCP Port Scanning" rule will detect this scan. Try it if you want.

Next, we'll look at Stealth FIN, Xmas Tree, and Null scans. They all exploit subtle behaviors in the TCP protocol if the protocol is implemented based on the RFC.

Page 65 of the TCP RFC document says the following

"if the [destination] port state is CLOSED .... an incoming segment not containing a RST causes a RST to be sent in response."

Then the next page discusses packets sent to open ports without the SYN, RST, or ACK bits set, stating that:

"you are unlikely to get here, but if you do, drop the segment, and return. When scanning systems compliant with this RFC text, any packet not containing SYN, RST, or ACK bits will result in a returned RST if the port is closed and no response at all if the port is open."

So the prototypes for the following scans are: Null has no bits set; FIN has just the FIN bit set, and Xmas is all bits set. Going back to the excerpt from the manual, all three scans sets of responses will be treated similarly.

RST received ==closed

ICMP unreachable == filtered

Other == open or filtered

These scans can be a bit more error prone since operating systems implement RFC 793 differently. Referring to the Nmap man pages we find the following:

"A number of systems send RST responses to the probes regardless of whether the port is open or not. This causes all of the ports to be labeled closed. Major operating systems that do this are Microsoft Windows, many Cisco devices, BSDI, and IBM OS/400."

It goes on to explain that this scan type does work against most UNIX based systems.

Identifying signatures for these scans should be easy. Fire up Wireshark on your Ubuntu Server (sudo wireshark) and start capturing traffic as we did in Exercise 1. No go to your Kali Linux VM and try the FIN scan against your Windows Server 2012 R2 VM.

nmap -sF 192.168.x.x

Does it appear to work properly? If you notice, it came back and said all ports are closed. And we know for a fact this is not true concerning the Windows Server 2012 R2 VM. So basically, we can say that it doesn't. We'll see the same results with a Xmas scan and Null scan. Run them both against the Windows Server 2012 R2 VM, and you should notice that all ports come back as closed.

nmap -sX 192.168.x.x

nmap –sN 192.168.x.x

Go back to Ubuntu Server and stop the Wireshark capture. Let's filter the results only to show TCP packets coming from Kali Linux to Windows Server 2012 R2 port 21. Enter the following into Wireshark's Filter field (x.x is the Kali Linux IP, and y.y is the Windows Server 2012 R2 IP):

ip.src==192.168.x.x && ip.dst==192.168.yy && tcp.port eq 21

Click Apply. You should see the results clearly representing the three scan types we just performed:

Click on each packet and examine the information in the middle pane. What's important to us is to see which flags are set. We can now write our rules. Let's just write one for the Xmas Tree scan; the other two will only differ in the flags values. Bring up or open the local.rules file and add the following rule to a new line:

alert tcp any any -> $HOME_NET any (msg:"Nmap XMAS Tree Scan"; flags:FPU; sid:1000007; rev:1;)

Save the file and start Snort in IDS mode. Go to your Kali Linux VM and run an XMAS Scan against your Windows Server 2012 R2 VM (let's just scan one port to reduce the output):

nmap -sX 192.168.x.x -p 80

Check your Snort output. The scan was easily detected.

Step 3 - Decoy scans

In this step, we will be examining a decoy scan or what is also called a spoof scan. The general idea behind the decoy scan is to forge the source addresses to add other origin points for the scanning activity. This is essentially making logs more difficult to parse and the scanning more difficult to attribute. There are active response methods to defeat this, but they aren't implemented. The reasoning there is, once you cross a certain threshold, the traffic log becomes noise. An important note, also from the manual, is the use of the "ME" keyword. Some logging products start filtering the logging output after a certain number of concurrent scans are detected. This is an attempt to reduce noise in the logs. The manual recommends placing the "ME" keyword in the sixth or later position to try and take advantage of this behavior. Otherwise, Nmap will insert your real IP randomly. First, let's set start Wireshark on our Ubuntu Server VM so that we can prove the IP addresses that are doing the scan from the victim's perspective.

Start Wireshark as we previously did by entering sudo wireshark and start capturing traffic on eth0. Now go back to your Kali Linux VM and type the following command to do a decoy scan against your Windows Server 2012 R2 VM:

nmap -sS 192.168.x.x -D10.10.10.10,11.11.11.11,1.1.1.1,8.8.8.8

You should see that your scan results come back accurately based on previous scan results. More importantly, check your Wireshark capture. You should be able to find packets which indicate that the IP addresses we entered after the –D option have been scanning. See below.

Nmap sends packets that spoof each of the IP addresses entered after the –D option. Additionally, it sends a packet with the source being the true IP address, since we do need responses back to determine the port state.

For obvious reasons, it is harder to detect decoy scans. In addition to some of the methods we used earlier, we can write a rule that alerts on connections coming from outside the predefined IP range. Let's try it, limiting legitimate connections to our class C subnet. Add the following rule to our local.rules file (let's limit alerting to one port number this time):

alert tcp !192.168.x.0/24 any -> $HOME_NET 80 (msg:"Suspicious IP address"; sid:1000008; rev:1;)

The "!" option tells Snort to generate an alert for all connections, except for ones coming from within this subnet. Save the file, start Snort in IDS mode, and perform the same decoy scan from Kali Linux again. Check Snort output. You will see alerts generated for each one of the spoofed addresses.

Press Ctrl+C to stop Snort.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

These are just some basic techniques that can be done using Snort rules for recon detection. Since we are focusing on writing rules, we are not going to cover Snort preprocessors created specifically for this purpose (such as sfPortscan), but it will be worthy of your time to look into those on your own.

End of lab