Weekly Tasks – Week 5

Rich Macfarlane 2013

Week Date Teaching Attended

5 Feb 2013 Lab 7: Snort IDS Rule Development

Aim: The aim of these labs are to further investigate the Snort, network IDS, and methods
for detection rule development, on both a Windows and a Linux platform

Time to complete:
4 hours (Two supervised hours in lab, and two additional hours, unsupervised).

Activities:
 Complete Lab 7: Snort
.pdf from WebCT or http://www.dcs.napier.ac.uk/~cs342/CSN11102/Lab7.pdf
(Use Unit 2 – IDS for reference)
Optional PartB:
.pdf from WebCT or http://www.dcs.napier.ac.uk/~cs342/CSN11102/Lab7B.pdf
(Use Unit 2 – IDS for reference)

 The End Of Unit Tutorial Questions for the Authentication chapter (from the unit pdf).

 Take some End Of Unit Online Tests for the Authentication chapter at:
http://www.asecuritysite.com/security/tests/tests?sortBy=sfc04

Learning activities:
At the end of these activities, you should understand:
 How to perform deep packet inspection of data packets, using Snort.
 How develop Snort rules, by analyzing protocol traffic.
 How the NMap network scanner is used to scan networks and systems, and how to
detect scans using Snort.
 How to use the Windows Superscan network scanner.

Reflective statements (end-of-exercise):

How is it possible to match on data inside the data packet?
Why is it important to tune IDS Sensors?
What are the main uses of a network scanner, such as Nmap?

References:
Course Handbook - Unit 2 IDS
Online: Snort User Manual, NMap User Manual.

Snort IDS Rule Development –Rich Macfarlane 1

Lab 7: Snort IDS - Detection Rule Development
Rich Macfarlane 2013

7.1 Details
Aim: To develop the use of the Snort IDS software, to create NIDS Sensors capable of
detecting unwanted network traffic, as well as report on possible intrusions.

7.2 Overview
Employing Network IDS (NIDS) sensors
around an organisations network, means
traffic can be monitored for intrusions and
security policy breaches. IDS sensors can be
used to report on insider attacks, misuse of
network resources, and intrusions from
outside the organisations network
perimeter.

IDS can be compared to a burglar alarm

system, with sensors around an
organisation’s premises. Similar to an IDS, it
can raise the alarm if intruders are detected,
but cannot stop the attack from proceeding.

This lab gives further IDS development using the Snort IDS, including application level
analysis, rule development, and network reconnaissance detection. Use the previous lab or
online materials as reference for Snort configuration.

Snort documentation, including the Snort Users Manual can be found at:
http://www.snort.org/docs

7.3 Lab Setup

The majority of this lab can be run on a standalone machine. Some of the later sections need
a second machine, so using the Napier Windows server 2003 Virtual Machine with the Snort
IDS sensor running on it, and a second VM such as the Napier Ubuntu VM, is recommended
(it can be started later, when needed, to save host resources)

The hosted virtualised lab architecture, using VM Workstation to run the Windows2003
Server VM, is shown below.

Snort IDS Rule Development –Rich Macfarlane 2

 Host PC

DESKTOP
Host OS - Windows7
VM Workstation

Host OS Virtual NIC VMnet VM Workstation

192.168. .1 Virtual Switch

Virtual NIC
192.168.
VMNet Gateway Web Server
Physical NIC 192.168. .2 FTP Server
VM Workstation
146.176. Telnet Server

WINDOWS2003
Virtual NIC Server
192.168.

UBUNTU
Linux VM

From VMWare Workstation open the guest Windows Server 2003 VM WINDOWS2003. Log
into the Windows server as User name: Administrator, Password: napier. (In VMWare
CTRL+ALT+INS can be used to send a CTRL+ALT+DEL)

Within the virtual image WINDOWS2003, run a Command Prompt Window and determine
the servers IP Address using ipconfig.

Complete the IP Addressing diagram above.

Snort IDS Rule Development –Rich Macfarlane 3

Run the Linux virtual image UBUNTU. Log into the Linux server as User name: napier,
Password: napier123).

Within the virtual image UBUNTU, open a Terminal Window (Applications->Accessories-

>Terminal) and determine the servers IP Address using ifconfig.

7.4 Activities
7.2.1 Snort as Packet Sniffer
On WINDOWS2003 change to the directory Snort is installed in, typically c:\snort
Check the interfaces available to Snort with:
C:\Snort> snort -W

Run the Snort IDS sensor as a packet sniffer to test it can inspect traffic, using:
C:\Snort> snort -dev -i 3

Test by creating ICMP traffic from UBUNTU.

7.2.2 Snort as an IDS Sensor – Configure Detection Rules

To run Snort as an IDS Sensor, a Snort Detection Rules file is used as input to the Snort
software to specify the traffic to detect and report on, as shown below.

Network Traffic Snort Sensor

Logs

Decoder & Detection Logging &

Preprocessors Engine Alerting Alerts
Rules

Figure 1 - Snort Sensor Architecture

Snort can be used as a signature-based IDS, with signatures defined in the rules. Signature-
based IDS can compare signatures against each packets application protocol data (the packet
payload). This is sometimes called deep packet inspection.

Firewalls tend to filter at lower levels as inspecting deep inside each packet can reduce
throughput. As IDS sensors are inspecting copies of the packets off-line, there is no effect on
throughput. This means IDS sensors can inspect packets much more thoroughly than most
firewalls.

Snort IDS Rule Development –Rich Macfarlane 4

7.2.3 Create Snort Detection Rules for Facebook Traffic
On WINDOWS2003 using Windows Explorer and a text editor, create a Snort Detection
Rules file c:\snort\rules\rules.txt where our Snort rules will be created.

To detect Facebook use by employees, an IDS detection rule can be created which will detect
the text “facebook.com” in the payload of HTTP packets being downloaded from a web
server.

alert tcp any 80 -> any any ( \

msg:"Facebook web traffic detected"; \
content:"facebook.com"; sid:10000; )

Note: The \ character is used to split rules over multiple lines.

Test Detection Rules

From the c:\snort directory, run the Snort IDS sensor using the rules.txt file as input
detection signatures, and logging alerts to the default Snort log folder, using:
snort -dev -i X -p -c rules\rules.txt -l log -K ascii -k none

Where X is the interface to capture on.

Now monitor the output folder c:\snort\log folder with Windows Explorer. Right click
the file panel and select View>Details, as shown below. The timestamp and size of the file
can now be viewed, and used to check if a rule has caused an alert to be raised, and packet
details to be logged.

To test, run a web browser.

Resize/rearrange your windows, so you can see the output alert.ids file in explorer, the
console window running snort, and the web browser window.

Snort IDS Rule Development –Rich Macfarlane 5

Use the web browser to navigate to the default Facebook login page, as shown below.

Check if an alert has been generated, by checking the log folder, as shown below. Stop Snort
running with <CTRL+C>, and open the alert file in an editor.

Snort IDS Rule Development –Rich Macfarlane 6

Q: Has an alert been generated for the facebook traffic?
YES/NO

Q: What is the IP Address of the facebook server, which the packet came from?

The alert file should look similar to the following:

From the Windows command line, use nslookup (name server lookup tool) to check for
DNS information on the server such as with the following:
C:\> nslookup serverIPAddress

Q: Does it confirm the server from the facebook.com domain?

YES/NO

The output should be similar to shown below:

7.2.4 Create Detection Rules for Job Searching

Create another Snort detection rule to detect employees doing internet searches for the word
“jobs” (add it to the rules.txt file). The alert should be “Job searching found in Web traffic”.

Note: Each snort rule must have a unique SID.

Test Detection Rules

Test the rule, by using a search engine to search for the string “Security jobs”.

Q: Does the Snort IDS Sensor detect the job search, and produce an alert?
YES/NO

Snort IDS Rule Development –Rich Macfarlane 7

Q: What is the working Snort rule?

Q: Can you locate and view the associated packet logged by Snort, and can you identify the
search string in the payload of the packet.
YES/NO

The packet details file should look similar to the following:

7.2.5 Developing Snort Detection Rules - Methods

As well as developing your own detection rules, peer reviewed Snort detection rules can be
downloaded and used from the Internet, such as from the Snort web site. These can then be
tailored quickly to specific needs.

To develop your own Snort rules, it is recommended that the vulnerability be researched or
the intrusion traffic generated in a controlled environment while Snort or another packet
sniffer capture the network traffic. The traffic should then be analysed, along with
researching any protocols involved, and a Snort rule(s) created based in any triggering
conditions (Roesch, 1999).

7.2.6 Develop a Snort Rule to Detect Ping Traffic

Ping is a utility, which is typically used to test connectivity. To capture the traffic, run
Wireshark, and listen on an interface which you can send packets though. (see previous
Wireshark lab for details)

Snort IDS Rule Development –Rich Macfarlane 8

From the local command line, open a new command windows, and Ping a neighbouring
machine, an internet server, or another VM, as shown below.

Stop the wireshark capture, and scroll up to the Ping packets, as shown.

Select some Ping packets and review the details.

Q: What is the protocol of the packets generated by the ping tool?

Q: Which Wireshark display filter can be used to filter out these packets?

Q: What is the payload (data) within the packet?

Q: Is this the same for all the Ping packets? (research online)
YES/NO

Create Snort Detection Rule

Create a new Snort rule (add it to the rules.txt file) to detect Windows Ping. The alert should
be “Windows Ping Detected – Possible Reconnaissance”

Test the rule

First delete everything in the log folder c:\snort\log with Windows Explorer.
Then run Snort, while monitoring the output log directory as before.
Generate traffic using ping from the command line, while monitoring the log file for alerts.

Snort IDS Rule Development –Rich Macfarlane 9

Q: What is the working Snort rule?

Q: How might this signature differ for Ping traffic from a Linux OS?

Q: How many alerts did the ping generate?

Q: Why this many alerts?

The alert file should look similar to the following:

Change the Snort ICMP detection rule to only alert on Pings which are outgoing from your
host system. The alert should be “Windows Ping Detected - Outgoing”
Test the changed rule.

Q: How many alerts did the ping generate?

Q: What is the working Snort rule?

Add a new Snort ICMP detection rule to only alert on Pings which are generated within the
local network network, but are destined for an external IP Address. (Hint: the CIDR /24 and
the negation operator ! might help)
The alert should be “Windows Ping Detected – Inside to Outside Net”
Test the rule DOES NOT fire for Pings on the local network first. Ping a single packet to a
device on the local network, such as shown below.

Snort IDS Rule Development –Rich Macfarlane 10

Q: Which rule fired, and how many alerts were generated?

Now test the rule for Pings from the local network to an external network. Ping a single
packet to a server on the internet, such as google.com.

Q: What is the working Snort rule?

The alert file should look similar to the following:

Snort IDS Rule Development –Rich Macfarlane 11

7.2.7 Developing Snort Detection Rules – Network Scanning
Typical network Reconnaissance involves Network Scanning. Host Scanning where hosts
are located on a terget network, and Port Scanning, where systems are scanned to find
services running on a remote machine. IDS such as Snort can be configured to detect this
type of behaviour.

Open a command window, and using the netstat command, determine your systems
connected ports.

Then using netstat –a –p TCP, determine the all your machines TCP listening ports
(servers running on the local machine).

Note: –n can be used to check port numbers.

Q: List some of the well known TCP-based services running?

7.2.8 The NMap Network Scanner

The Nmap (NetworkMAPper) network scanner can perform a wide variety of network
scans, and can be used for network exploration, network inventory, and network security
auditing and assessments.
A command line nmap executable, or a GUI version Zenmap can be used.
The nmap users manual is available at:
http://nmap.org/book/man.html

A typical scan would be a Port Scan which is used to determine the network services which
are running on a specific target machine.

Eve

Scanning … TCP SYN

Port 21 - closed
Port 22 - closed
Port 23 – closed
…
Port 80 - open TCP SYN ACK
…
Port 65,000

This is performed by sending packets to ports, on the target machine, and checking which
services respond. A good example, and the default Nmap scan, is a TCP SYN scan, or Half-
open scan, were TCP SYN packets are crafted by Nmap, and sent to the target, and the SYN
ACK response packets show that TCP services are running on the target.

Snort IDS Rule Development –Rich Macfarlane 12

Note: DO NOT port scan any machines out with the local subnet. (Most ISPs prohibit port
scanning and maintain the right to disconnect customers who perform such activities)
If nmap is not on your system, the latest version can be downloaded from:
http://nmap.org/download.html

A basic nmap port scan (TCP SYN scan) against a single system should look something like
the below:

Note: From the Windows version of nmap, a scan must be performed from another machine,
as it cannot scan the local system.

Scan your machine, by running the nmap scanner from the host machine, or from another
VM (such as The Napier UBUNTU Linux VM):
nmap WindowsPC_IPAddress

Q: List some services and their ports, Nmap reported?

On the Windows machine, determine the TCP services running, and their port numbers:
netstat –a –p TCP -n

Q: Do the services match what Nmap reported?

YES/NO

The output should look similar to the below (based on Windows2003 server VM as target
machine):

Snort IDS Rule Development –Rich Macfarlane 13

Q: Did the Nmap scan report any UDP services running?
YES/NO
Q: Why might this be?

The default Nmap scan is a TCP SYN Scan. Scan your machine again with Nmap, this time
with a UDP scan: (the scan may need sudo from a Linux OS)
sudo nmap –sU WindowsPC_IPAddress

Q: List some services and their ports, Nmap reported?

On the Windows machine, determine the TCP services running, and their port numbers:
netstat –a –p TCP -n

Q: Do the services match what Nmap reported?

YES/NO

Snort IDS Rule Development –Rich Macfarlane 14

The output should look similar to the below (based on Windows2003 server VM as the
target machine):

7.2.9 Create Snort Detection Rule to Detect a SYN Scan Manually

Create a new Snort rule (add it to the rules.txt file) to detect a SYN Scan. The alert should be
“Windows Ping Detected – Possible Reconnaissance”
As before, capture the Nmap port scan traffic, with Wireshark, and analyse for a signature to
detect.
Create a Snort rule which detects the incoming SYN flag from the scanner. (See the Course
Handbook - Chapter 2 or the Snort Manual online on how to detect TCP flags)

Test the rule

Again delete everything in the log folder c:\snort\log with Windows Explorer.
Then run Snort, while monitoring the output log directory as before.
Generate traffic to test the rule using the Nmap TCP SYN Scan, while monitoring the log file
for alerts.

Q: What is the working Snort rule?

Q: How many alerts did the test scan generate?

Q: How many alerts per port scan would be ideal?

Q: Would this rule generate false positives? Why?

Snort IDS Rule Development –Rich Macfarlane 15

The Snort alerts should be similar to those shown below:

7.2.10 Detecting Network Scans using Snort IDS Pre-Processor

Rules cannot detect scans easily, as a scan uses many packets and these can mixed in with
many other packets. Snort has a pre-processor module to help, which groups packets
together into TCP streams (The Snort Manual or the IDS unit notes has more detail on this).

Add the Snort port scan pre-processor and the correct parameters, which allows a port scan
to be detected. (pre-processors have to be the first rules in the rules file)

Test the Preprocessor

Again delete everything in the log folder c:\snort\log with Windows Explorer.
Then run Snort, while monitoring the output log directory as before.
Generate scan traffic to test the rule using the Nmap TCP SYN Scan, while monitoring the
log file for alerts.

Q: Which Pre-processor, and with which parameters, was successful?

Q: Did Snort detect the port scan?

YES/NO

Other tools can be used to perform port scans such as the extremely useful network packet
crafting tool netcat. Netcat is often called the swiss army knife of network tools as it can be
used for many purposes.

Snort IDS Rule Development –Rich Macfarlane 16

From UBUNTU port scan WINDOWS2003 for ports 1 to 100 with:
napier@ubuntu:~$ nc -v -z 192.168.100.133 1-100

Q: Which ports was netcat able to connect to?

Q: Did Snort detect the port scan?

YES/NO

The Snort network scanning detection output should look similar to the below:

7.2.11 IDS Evasion

Try to evade the IDS detection by using stealthy scans, and at the same time tune the IDS
sensor to detect the scans.

This can be done by varying the parameters of nmap (-T parameter), while tuning the Snort
IDS scan detection pre-processor (Sense level).

Q: Can you evade the Snort detection?

YES/NO

Try only scanning small ranges of ports using netcat, such as 21-25

Q: Did Snort detect the smaller port scan?

YES/NO

Try scanning the same small ranges of ports using netcat with Snort still running.

Q: Did Snort detect the second scan?

YES/NO

Snort IDS Rule Development –Rich Macfarlane 17

7.2.12 Snort on Linux
We can also run Snort on the Linux box UBUNTU, and use the WINDOWS2003 VM as the
attacker/security tester machine, as shown below.

Host PC

DESKTOP
Host OS - Windows7
VM Workstation

Host OS Virtual NIC VMnet VM Workstation

192.168. .1 Virtual Switch

Virtual NIC Web Server

192.168. FTP Server
VMNet Gateway Telnet Server
Physical NIC 192.168. .2 VM Workstation
146.176.

WINDOWS2003
Virtual NIC
Server
192.168.

UBUNTU
Linux VM

7.2.13 Snort as Packet Sniffer

On UBUNTU check the interfaces available to Snort with ifconfig.
Run the Snort IDS sensor as a packet sniffer to test it can inspect traffic, against the
appropriate interface (eth1 in the example below) using the following command. (Use CTRL+C to
stop the Snort Sensor running):
napier@ubuntu:~$ sudo snort -dev -i eth6

Snort should run, and you should see the Not Using PCAP_FRAMES msg as shown below

Snort IDS Rule Development –Rich Macfarlane 18

Test by creating ICMP traffic from WINDOWS2003 using ping. You should see the packets
being sniffed in UBUNTU as shown below:

Stop Snort, and scroll back up to the Snort output in the console window, showing the
Packets Detected Totals, and complete the following:
Q: Received Packets Total?

Q: IPv4 Packets Total?

Q: ICMP Packets Total?

7.2.14 Snort as an IDS Sensor – Configure Detection Rules

To run Snort as an IDS Sensor, a Snort Detection Rules file is used as input to the Snort
software to specify the traffic to detect and report on.

Create a snort, and rules and a log directory under the home directory using:
napier@ubuntu:~$ cd ~
napier@ubuntu:~$ mkdir snort
napier@ubuntu:~$ cd snort
napier@ubuntu:~$ mkdir rules
napier@ubuntu:~$ mkdir log

Create a detection rules file in the rules dir with a text editor, such as with:
napier@ubuntu:~$ vi rules/snort.rules
or
napier@ubuntu:~$ gedit rules/snort.rules &

Snort IDS Rule Development –Rich Macfarlane 19

Add the signatures from the WINDOWS2003 server Snort sensor rules file, for Windows
and Linux ping detection, such as the following:

From UBUNTU, in the snort dir, run the snort sensor (against the appropriate interface):
sudo snort -i eth0 -dev -p -c rules/snort.rules -l log -K ascii -k none

To monitor the alerts being generated by the Snort IDS Sensor open a second terminal
window on the Linux VM. The output file can be checked for any lines being appended to it
using the tail command, as shown below.
sudo tail -f log/alert

To test the detection rules, ping the Linux VM UBUNTU from WINDOWS2003.

Q: Did snort detect the ping traffic?

YES/NO
Q: Which rule fired?

From UBUNTU, open another terminal window, and ping the WINDOWS2003.

Q: Did snort detect the ping traffic?

YES/NO
Q: Which rule fired?

The output from the tail command should look something like the following.

Snort IDS Rule Development –Rich Macfarlane 20

7.2.15 The SuperScan Network Scanner
The SuperScan network scanner is a well known Windows only GUI based scanner.
On WINDOWS2003, download the scanner from:
Superscan can be downloaded from:
http://www.mcafee.com/uk/downloads/free-tools/superscan.aspx

Unpack the zip file to the C:\ directory and run the executable superscan.exe. It should look
like the following:

7.2.16 Detecting Network Scans using Snort IDS Pre-Processor

On UBUNTU, edit the detection rules file, and add the pre-processor rule for network
scanning detection from the WINDOWS2003 server Snort sensor rules file:

Test the Preprocessor

Delete everything in the log folder using:
napier@ubuntu:~/snort/log$ sudo rm -r *

Then run Snort, while monitoring the output log directory as before.
Generate scan traffic to test the rule using Nmap, while monitoring the log file for alerts

Snort IDS Rule Development –Rich Macfarlane 21

with:
sudo tail -f alert

And open another terminal window and monitor the scanning log file with:
sudo tail -f portscan.log

From WINDOWS2003, run a default host discovery/port scan against UBUNTU, using the
superscan network scanner.

Q: Did Snort detect the port scan?

YES/NO

The alert should be similar to the following:

Snort IDS Rule Development –Rich Macfarlane 22