Lab 8 - Intrusion detection using Snort

Purpose

In this lab, we will explore a common free Intrusion Detection System called Snort. Snort was written initially for Linux/Unix, but most functionality is now available in Windows. We will both Linux and Windows versions of Snort

Background - what is a network intrusion detection system?

The idea of a network intrusion detection system is to have a device of some sort that can ’hear’ all the traffic on its part of the network. It listens to this traffic, and based on a set of defined rules, it will trigger an action of some kind on packets that match one of the defined rules. One could think of its functionality as very
similar to that of antivirus software - scan content for stuff considered malicious, and take action. An example rule might, in common language, be: ”All packets sent on the http port to a webserver on the network, that contain the string ’cmd.exe’”. Snort’s default ruleset has an implementation of this rule - the reason we want to watch out for this is it might imply that an attacker is trying to execute a command shell on a webserver running Windows. We will look into exactly what this rule looks like in Snort’s rule format later. Snort is a very powerful IDS that in later versions can act like an IPS. Snort is free to download and use in the personal environment as was as in the business environment. In fact Snort is used by many Enterprises as a very effective option for their business because not only is it free but it is one of the most powerful IDS’s out there is you know what you are doing when you configure it.

Snort can be created as a program that you run when you want on a personal computer or it can be setup to run when your OS starts and protect all computers on your network from attacks.

If you want to use Snort to protect your entire network it will need to be placed in line with your internet connection. So as an example lets say that you have a business internet account with your local cable company and you want to protect it with a computer runing Snort. The computer running Snort needs to be placed between the cable modem and the router, this way Snort is able to monitor every peice of traffic that comes into your network and is in the best place to discover possible attacks

Part 1 - Snort on Linux

Tools required for this lab:

  • Root-level access to a Linux VM with snort installed on on. We will be installing Snort on Kali Linux.
  • VMWare setup to run in promiscuous mode

Pre-lab Background:

The suggested background reading may help you complete the questions..

The writing snort rules document is an especially helpful reference for writing the snort rules needed for this lab.

Install Snort on Linux:

We are going to be installing Snort on Kali Linux. There are two ways to install Snort onto a Ubuntu Distribution and the easiest is to do it through a command line. If your computer is up to date you can simply type:

sudo apt-get install snort

This will then download and install the newest version of snort on your computer through command line. As soon as it is done you will be ready to use snort. But if you run into an error or cannot install Snort through command line you can always go to the Snort website and download the newest version, but make sure that you are downloading the tar.gz file and follow their installation guide to completly setup Snort.

Networking Setup on VMWare

Because the Linux will need to access the networking promiscuous, you will need to run it as root. (There are other ways but this is the simplest at this point). This can be done with:

sudo vmware

At the command prompt. Next we need to set up snort so it will monitor the traffic of your host Linux, or of another virtual machine. The easiest way to do this is to set up the VM's to use "bridge" mode.This will mean (at SHJC) that the VM will not access the Internet, but this should be okay as long as you can monitor the "tap" on the host system.

Try out Snort

Once installed you can run snort as just a sniffer and have all packets captured logged but that will create an enormous log file that you would then have to view. Snort works so well because of its use of rules to know which traffic to log and which traffic to ignore.

How Snort runs depends on the flags that you specify when you launch Snort from command line.

Flag Function

-v View packet headers at the console.
-d View application data with IP headers.
-D Run Snort as a daemon.
-e Show data-link layer headers.
-l Run in packet logger mode.
-h Log information relative to the home network.
-b Log information to a single binary file in the logging directory.
-r Read packets contained in a log file. N Disable packet logging.
-c Specifies which file will be used to provide a ruleset for intrusion detection.
-i Specifies which port you would like Snort to look at when running.

As you can see from above we have a few different options when it comes to flags used with Snort. Lets start with just viewing IP packet headers by using the command

sudo snort -v

Be sure to use the sudo command before snort so that is runs in administrative mode, this is needed to open the appropiate port. Now since we did not specify a port for snort to look at it is going to use the eth0 port by default, If you are using a wireless card then eth0 port is not the right port, but the wlan0 port which is the wireless card. We will need to us the -i flag to tell Snort to watch the VM ethernet card to check for traffic,

sudo snort -v -i eth0.

Now Snort will run and display on the screen every packet header that comes accross the eth0 virtual adpater in Kali. This should be bridged to the host adapter on the host machine. This is very useful if you want to monitor all traffic across your network but very impractical if you want to protect your network. To end the application once it has started you can simply hit CTRL+C to end the program and bring you back to a command prompt.

Operation as a IDS

In order to run as an IDS we only want to record alert, not everything. We thus need to specify a both a rules file and a log file location. Note that /etc/snort/snort.config contains a reference to all the rule files already, using the "include" directive. If we want to test snort with a very simple rule set, we can make our own config file, such a mysnort.conf. Thus we could create a file mysnort.conf, and put a reference to a rule file with a single rule.

The rule files are usually stored in the /etc/snort/rules/ directory.

For example create a rule file, such as:

root@kali:/etc/snort# more mysnort.conf

include /etc/snort/rules/icmp2.rules

Then create a config file, in /etc/snort, such as:

root@kali:/etc/snort# more rules/icmp2.rules

alert icmp any any -> any any (msg:"ICMP Packet"; sid:477; rev:3;)

Now we can run it with the command:

root@kali:/etc/snort# snort -c /etc/snort/mysnort.conf -l /var/log/snort/

Running in IDS mode

= -- Initializing Snort --=

Initializing Output Plugins!

Then we can do some pings, and see the results in the /var/log/snort/alert file.

Writing Snort Rules

Begin by reviewing the follow chapter on Snort Rules: How To Write Snort Rules.

Snort Rules


Snort allows you to write rules describing

  • well-known and common vulnerability exploitation attempts
  • violations of your security policy
  • conditions under which you think a network packet(s) might be anomalous
Through the use of an easy-to-understand and lightweight rule-description language, Snort rules can be both flexible and robust; written both for protocol analysis and content searching and matching.

Two basic guiding principles must be kept in mind when writing Snort rules:
  1. Rules must be completely contained on a single line.
  2. Rules are divided into two logical sections, the rule header and the rule options. The rule header contains the rule's action, protocol, source and destination IP addresses and CIDR (Classless Inter-Domain Routing) block, and the source and destination ports information. The rule option section contains alert messages. It also contains information about which parts of the packet you should inspect to determine if you should take the rule action.

An example rule:

alert tcp any any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg: "mountd access";)

[Example 1 - Sample Snort Rule]

This rule describes an alert that is generated when Snort matches a network packet with all of the following attributes:

  • TCP packet
  • Sourced from any IP address on any port
  • Destined for any IP address on the 192.168.1.0 network (24 describes the CIDR block and netmask used) on port 111.
The text up to the first parentheses is the rule header:

"alert tcp any any -> 192.168.1.0/24 111"

The section enclosed in parenthesis is the rule options:

"(content:"|00 01 86 a5|"; msg: "mountd access";)"

The word(s) before the colons in the rule options section are called option keywords. These keywords may appear once, as with ‘content’ in Example 1 above, or multiple times, as shown in Example 2 below:

alert tcp any any -> any 21 (content:"site exec"; content:"%"; msg:"site
exec buffer overflow attempt";)


[Example 2 - Sample Snort Rule]

The above rule illustrates an FTP vulnerability. The keyword "content" appears twice because the two strings that "content" describes are not concatenated but appear at different locations within the packet(s). For this rule to be violated, the content of a packet(s) must contain both character strings, "site exec" and "%".

The rule options section is not specifically required by any rule; it is used for the sake of making tighter definitions of packets to collect or to issue an alert.

Elements of an individual rule are treated as forming a logical AND statement. The complete collection of rules in a Snort rules library file (i.e., snort-lib) are treated as forming a larger logical OR statement.

Basics in Writing Snort Rules

Rule Actions:

alert tcp any any -> any any (msg:"My Name!"; content:"Skon";sid:1000001;rev:1;)


The rule header contains the information that defines the "who, where, and what" of a packet, as well as what to do when a packet occurs with all the attributes indicated in the rule. The first field in a rule is the rule action. The rule action tells Snort what to do when it finds a packet that matches the rule criteria. There are three available actions in Snort - alert, log, and pass.

  • alert - generates an alert using the selected alert method, and then log the packet
  • log - logs the packet
  • pass - drops (ignore) the packet

Protocols:

The next field in a rule is the protocol. There are three IP protocols that Snort currently analyzes for suspicious behavior, TCP, UDP, and ICMP. In the future there may be more, such as ARP, IGRP, GRE, OSPF, RIP, and IPX.

IP Addresses:

The next portion of the rule header deals with the IP address and port information. The keyword "any" may be used to define any address. Snort does not have a mechanism to provide host name lookup for the IP address fields in the rules file. The addresses are formed by a straight numeric IP address and a CIDR block. The CIDR block indicates the netmask that should be applied to the rule's address and any incoming packets that are tested against the rule. A CIDR block mask of /24 indicates a Class C network, /16 a Class B network, and /32 a specific machine address. For example, the address/CIDR combination 192.168.1.0/24 would signify the block of addresses from 192.168.1.1 to 192.168.1.255. Any rule that used this designation for, say, the destination address would match on any address in that range. The CIDR designations give us an easy way to designate large address spaces with just a few characters.

In Example 1 (above), the source IP address was set to match for any computer communicating, and the destination address was set to match on the 192.168.1.0 Class C network.

A negation operator can be applied to IP addresses. This operator tells Snort to match any IP address except the one indicated by the listed IP address. The negation operator is indicated with a "!". For example, an easy modification to the initial example is to make it alert on any traffic that originates outside of the local network with the negation operator as shown in Example 3.

alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111
(content: "|00 01 86 a5|"; msg: "external mountd access";)

[Example 3 - Example IP Address Negation Rule]

This rule's IP addresses indicate "any TCP packet with a source IP address not originating from the internal network and a destination address on the internal network".

Port Numbers:

Port numbers may be specified in a number of ways, including "any" ports, static port definitions, ranges, and by negation. "Any" ports is a wildcard value, meaning literally any port. Static ports are indicated by a single port number, such as 111 for portmapper, 23 for telnet, or 80 for http. Port ranges are indicated with the range operator ":". The range operator may be applied in a number of ways, such as in Example 4.

log udp any any -> 192.168.1.0/24 1:1024

Log UDP traffic coming from any port and destination ports ranging from 1 to 1024.



log tcp any any -> 192.168.1.0/24 :6000

Log TCP traffic from any port going to ports less than or equal to 6000.



log tcp any :1024 -> 192.168.1.0/24 500:

Log TCP traffic from privileged ports less than or equal to 1024 going to ports greater than or equal to 500.

[Example 4 - Port Range Examples]

The negation operator, "!", may be applied against any of the other rule types (except "any", which would translate to none). For example, if for some reason you wanted to log everything except the X Windows ports, you could do something like the rule in Figure 5.

log tcp any any -> 192.168.1.0/24
!6000:6010

[Example 5 - Example of Port Negation]

Direction Operator:

The direction operator "->" indicates the orientation, or "direction", of the traffic that the rule applies to. The IP address and port numbers on the left side of the direction operator designate traffic coming from the source host, and the address and port information on the right side of the operator designate destination host. There is also a bi-directional operator, which is indicated with a "<>" symbol. This tells Snort to consider the address/port pairs in either the source or destination orientation. This is handy for recording and analyzing both sides of a conversation, such as telnet or POP3 sessions. An example of the bi-directional operator being used to record both sides of a telnet session is shown in Example 6.

log 192.168.1.0/24 any <> 192.168.1.0/24 23
[Example 6 - Snort rules using the Bi-directional Operator]

In Example 6, any traffic on any port originating from outside the internal network (192.168.1.x) with a destination of the internal network on the telnet port (23) is logged. Reciprocally, any telnet traffic originating from the internal network with a destination outside the internal network to any port is logged. Therefore, both sides of a telnet connection are logged.

Snort Alerting

Snort Alerts and How We Trust Them

Alerting, part of the Alerting and Logging subsystem, is activated at run-time through the use of command-line options. In this section, we do not discuss these options, as they are detailed in documentation on the Snort web site. Instead, we describe how you, the system administrator, can verify that a Snort-generated alert is valid.

To fully trust an intrusion detection system alert, you must be able to examine three complementary data points: a rule representing behavior you know or suspect of being anomalous, an alerting message warning you of a rule violation or of particular behavior, and a network packet (or series of packets) causing the rule violation. In lieu of having all three components, you must be able to relate the network packet to at least one of the following:

  • the alerting message (of the proposed intrusion or intrusion attempt)
  • the rule violated (of the proposed intrusion or intrusion attempt)
If neither of these relationships occur, you are precluded from characterizing the security event as a positive or negative. The network packet(s) is a critical point-of-examination, and without the actual, tangible packet(s) we cannot investigate whether a rule is violated or an alerting message displays a positive occurrence of violation to our security policy. Therefore, because Snort allows you to configure various levels of alerting and logging, we recommend that Snort be set up to log the offending packets causing the rule violation and to record the alerts, in separate files.
Snort Alerts and Logs

When Snort inspects a network packet and detects a match between a rule (describing a violation) and the network packet, Snort sends an alerting message to the user-defined facility and/or logs the packets causing the rule violation. The alerts "may either be sent to syslog, logged to an alert text file in two different formats, or sent as WinPopup messages using the Samba smbclient program. The syslog alerts are sent as security/authorization messages that are easily monitored with tools such as swatch [SWT93]. WinPopup alerts allow event notifications to be sent to a user-specified list of Microsoft Windows consoles running the WinPopup software. There are two options for sending the alerts to a plain text file; full and fast alerting. Full alerting writes the alert message and the packet header information through the transport layer protocol. The fast alert option writes a condensed subset of the header information to the alert file, allowing greater performance under load than full mode. There is a fifth option to completely disable alerting, which is useful when alerting is unnecessary or inappropriate, such as when network penetrations tests are being performed."

Similarly, logging can be set up to "log packets in their decoded, human-readable format to an IP-based directory structure, or in tcpdump binary format to a single log file. The decoded format logging allows fast analysis of data collected by the system. The tcpdump format is much faster to record to the disk and should be used in instances where high performance is required. Logging can also be turned off completely, leaving alerts enabled for even greater performance improvements."

To put this into perspective, let’s examine the logging and alerting areas of a system. For this discussion, the system sends alerts to the syslog facility and the offending network packet(s) to an IP-based directory structure. All alerts are logged via syslog to a file called "alerts" in the file /var/adm/snort/alerts. Any alerting message found in this file will have corresponding offending network packets logged in the same directory as the alert file but under the IP address of the source packet.

Using the rule in Figure 1, from above:

alert tcp any any -> 192.168.1.0/24 111
(content:"|00 01 86 a5|"; msg: "mountd access";)


When Snort inspects and matches the above rule to an offending network packet(s), an alerting message is sent to syslog stating that a "mountd access" violation has occurred. This message is recorded in the file /var/adm/snort/alerts and the actual network packet(s) causing the alert is recorded in a file based on the source IP address of the offending packet(s), (i.e. /var/adm/snort/a.b.c.d).

Some problems may occur when filtering log entries into an IP-named file. For one, multiple alerts may involve one IP address. Under this condition, the offending packets violating each unique rule are sent to the same IP-named file; and mapping the specific alert to the offending packet(s) then demands a search and locate approach that could be time consuming.


Lab Exercises

Do the following exercises, capturing the associated terminal I/O and log entries, and placing in a single Word document, along with comments and andswers to questionss.

Step 1 - Find your last name

Consider the following simple rule:

alert tcp any any -> any any (msg:"My Name!"; content:"Skon";sid:1000001;rev:1;)

Question 1: What does this rule do?

Note the sid:1000001;rev:1 in the rule. This is required to keep Snort happy. each rule you write should have a unique SID.

Use and editor to create a file "myrules.rules" in your home directory. Then create a rule like the one above, only with your last name.

Try it out with the command:

sudo snort -c myrules.rules -i eth0

Question 2: What do you see when the program starts to run? What does it mean?

Go to a web page that includes you last name in the text.

Control-C

Question 3: What do you see?

Go to the directory /var/log/snort. Open the file "alert" file. Varify that there are alerts for your name.

Question 4: What does the alert look like? What does each field mean?

Step 2 - detect a visit to Wikipedia

Write a rule that logs (not alerts) a message whenever Wikipedia is visited FROM YOUR station. Do not use a string or content matching rule.

Question 5: What is your rule? Where did the message get logged? What got logged?

Step 3 - detect a ping from another system

Write a rule that alerts whenever your systems is pinged from another. Make sure it does NOT alert when you ping out.

Question 6: What is your rule? How dod you make it only log incoming pings? Where did the message get logged? What got logged?

Step 4 - detect a login attempt from SSH

In this step you will need 2 computers. Cooperate with the person next to you to do this.

First enable SSH on your system. Follow the instructions HERE.

Varify that you can log in from the next computer over.

Now bring up WireShark . Watch capture the packets as an SSH sessions starts.

Try to write a rule to Alert you that an SSH session has been attempted.

Question 7: What is your rule? Show the rule, and explain how it works. Show the resulting alert message in the alert file.


References

  1. http://oreilly.com/pub/h/1393
  2. http://linuxaria.com/article/snort-ids-linux?lang=en
  3. A quick overview of Snort; Patrik Israelsson. Jerker Karlsson, Guillaume Giamarchi
  4. http://www.cse.sc.edu/~okeefe/tutorials/cert/i042.14.html
  5. Snort Tutorial
-- JimSkon - 2012-03-01
Topic revision: r4 - 2014-04-12 - JimSkon
 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback