0% found this document useful (0 votes)
47 views39 pages

Lab 2 Solution

This document outlines a lab focused on using Snort, a network intrusion detection system, to monitor and analyze network traffic. It details the setup involving Docker machines for Snort, Scapy, and a user machine, and describes tasks such as sniffing traffic, saving logs in text and binary formats, and creating custom detection rules. The document also explains Snort's architecture, including its components like preprocessors and the detection engine, and provides insights into using Scapy for generating network traffic and performing attacks.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
47 views39 pages

Lab 2 Solution

This document outlines a lab focused on using Snort, a network intrusion detection system, to monitor and analyze network traffic. It details the setup involving Docker machines for Snort, Scapy, and a user machine, and describes tasks such as sniffing traffic, saving logs in text and binary formats, and creating custom detection rules. The document also explains Snort's architecture, including its components like preprocessors and the detection engine, and provides insights into using Scapy for generating network traffic and performing attacks.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

College of Technological Innovation

Introduction
In this lab, we explore the functionality and capabilities of Snort, a network intrusion detection system
(NIDS) tool. The primary objectives of this lab are to use Snort as a sniffer, configure and utilize Snort
preprocessors, and construct detection rules for identifying specific network events. The lab setup
involves three docker machines: one running Snort to monitor traffic, another with Scapy for launching
attacks, and the third as the user or victim machine. The initial setup includes configuring the docker
containers and establishing the network environment. We begin by using Snort commands in dump mode
to observe network traffic. Subsequently, we explore Snort's logging feature to save traffic data in text
and binary formats for analysis. We then employ Scapy, both with Python scripts and the interactive
Scapy interpreter, to generate ICMP packets and perform various network attacks, including ARP
spoofing and scanning. Throughout the lab, we create custom Snort rules tailored to detect specific attack
patterns and test them using various scenarios. Additionally, we configure Snort's network settings and
preprocessors to enhance its detection capabilities. Finally, we analyze the effectiveness of Snort in
detecting and mitigating network attacks, including IP fragmentation techniques. Through these tasks, we
aim to gain practical experience in using Snort as an essential tool in network security and intrusion
detection.

Lab Setup Environment:

Snort should listen to the interface docker0 to be able to intercept the traffic exchanged between different
docker images that will be created in the lab.

User
Scapy
Machine
Machine
172.17.0.3
172.17.0.2
02:42:ac:11:00:03
02:42:ac:11:00:02

Snort
Machine
172.17.0.1
02:42:12:c4:fd:82

2
SEC515
College of Technological Innovation

Snort machine
docker run --net=host -ti alpine

apk add snort

snort -i docker0

3
SEC515
College of Technological Innovation

Scapy machine
docker run -ti alpine

apk add py3-pip

apk add scapy

4
SEC515
College of Technological Innovation

User machine
docker run -ti alpine

Checking all containers:

Note: As we tried to attempt some commands with snort, we got several errors as seen below. So we
created another docker image with ubuntu and repeated the previous steps.

What is Snort
Intrusion detection is a set of techniques and methods used to detect suspicious activity on a network and /
or terminal equipment. Intrusion detection systems fall into two detection categories:

- systems that base their analysis on signatures, and


- systems that detect protocol anomalies.

The first category uses the fact that an intrusion has a signature (specific ports, keywords in useful data,
etc.) in the same way as malwares. The signature-based intrusion detection system attempts to find these

5
SEC515
College of Technological Innovation

particular signs in the examined packets. The systems of the second category detect anomalies in the
headers of network packets with regards to standard protocols.

SNORT is an open source IDS. It allows to analyze data flows against a signature database, but also to
detect network protocol anomalies.

Architecture of Snort
SNORT is made up of several logical components. These components make it possible to detect a particular
attack and generate an alert in the desired format as an output. The main components of SNORT are packet
decoder, preprocessors, detection engine, logging and alerting system, and output modules.

The packet decoder retrieves packets from different types of network interface and prepares it for
preprocessors or the detection engine. Network interfaces can be Ethernet, SLIP, PPP, etc.

Preprocessors are plug-ins for arranging or modifying data packets before the detection engine kicks in.
Some preprocessors also detect anomalies in the packet headers and then generate alerts. Preparing packets
for the discovery engine is very important in the context of IDS. Indeed, attackers use different techniques
to fool IDS. For example, if you create a rule to find the signature “scripts / iisadmin” in HTTP packets.
The detection engine looking for exactly this character string can be tricked by an attacker who modifies
the character string slightly. For example: “scripts /./ iisadmin”, “scripts \ iisadmin”, “scripts /. \ iisadmin”.
To complicate the task a bit, the attacker can also insert in the URI (Uniform Resource Identifier)
hexadecimal or unicode characters which are legal. The preprocessor can rearrange the character string so
that it can be detected by the IDS.

Preprocessors are also used for reassembly of IP fragments. When a large amount of data is transferred, the
packets are often fragmented. For example, the maximum length of packets on an Ethernet type network
cannot exceed 1500 bytes (value defined by the MTU). This implies that a packet of a greater length is
divided into several packets of length equal to or less than 1500 bytes. The terminal system which receives
the data can reassemble the original packet. To be able to detect signatures, an IDS positioned on an
intermediate device must do the same to thwart attacks from attackers who use this fragmentation technique.

The included SNORT preprocessors allow packets to be defragmented, decode HTTP URIs, reassemble
TCP streams, and more. However, it is possible to write your own preprocessor. Now we will explain some
important preprocessors.

Frag3
The frag3 preprocessor allows SNORT to counter attacks of the IP fragmentation type. This type of attack
involves fragmenting IP packets in order to hide certain information. For example, it is possible by this type
6
SEC515
College of Technological Innovation

of attack to segment the TCP information on several packets (Tiny Fragments attack, first 8 bytes of TCP
in the first IP packet, ie source and destination ports + sequence number, and the rest in the second IP
packet, ie flags syn / ack / fin) or falsify information by playing on the offset (Fragment Overlapping attack,
first IP packet with flag syn = 0 and second packet with connection information which overrides the flags
TCP with syn = 1 and ack = 0).
Stream5
The Stream5 preprocessor provides mechanisms to monitor TCP and UDP sessions. It also scans ICMP
messages to check for unreachable and unavailable messages. This preprocessor also allows:
• the reassembly of TCP streams of the same session. If an attacker tries to attack a system by
introducing elements into the payload of several TCP packets in a Telnet session, this module by
assembling this payload allows the signature to be recovered.
• and stateful inspection. This module allows you to keep in memory the state of a TCP connection.
Thus, this preprocessor is able to detect irregularities in TCP flows. For example, the “TCP stealth” method
is to never completely complete the process of establishing the TCP connection.
sfPortscan
The first step in an attack process is most often determining which services are running on a network using
tools such as nmap. Once this step is carried out, attacks on the known vulnerabilities of the detected
services are launched. This preprocessor can detect scans of IP addresses and TCP / UDP ports. Different
types of scans are concerned: One -> several hosts (search for a particular service), one -> several ports
(search for services on a device).
http_inspect
Many attacks on WWW servers are carried by using hexadecimal characters in URIs. For example,
considering the SNORT rule which must recognize the character string “/wwwboard/passwd.txt”, an
attacker can bypass it by sending the request to obtain the URI “%2Fwwwboard%2Fpasswd.txt”. The
http_inspect preprocessor normalizes the requests in order to allow their analysis by the detection engine.
Smtp
This preprocessor is used to analyze SMTP messages.
ssh
The ssh preprocessor can detect the following exploits Challenge-Response Buffer Overflow, CRC 32,
Secure CRT, and the Protocol Mismatch.
ssl
The ssl preprocessor is used to analyze the SSL negotiation phase.
ftp_telnet
This preprocessor works only on the telnet and ftp protocols. It decodes or removes binary telnet control
codes randomly inserted in a telnet or ftp stream. This technique is often used by hackers to execute system
commands over, for example, an ftp connection.
rpc_decode
The rpc_decode preprocessor normalizes RPC connections. Attackers exploit this protocol to do remote
discovery or exploitation by establishing dynamic links with remote services.
arpspoof
ARP (Address Resolution Protocol) is used to determine the MAC address associated with an IP address.
This protocol is the basis of several eavesdropping (for example the dsniff package) or “spoof” attacks (for
example, redirecting traffic from one host to another destination).
The arpspoof preprocessor detects anomalies in ARP messages, for example:
• For ARP requests: if the Ethernet source MAC address and that contained in the ARP message are
different, if the source MAC addresses do not match the IP address
• For ARP responses: the MAC addresses in the Ethernet frame and in the ARP message are different
• Unicast requests.

7
SEC515
College of Technological Innovation

The detection engine


The SNORT detection engine is the heart of the IDS. It is responsible for detecting any intrusion activity
in the data streams. It uses rules which consist in defining a set of criteria on the packets. If a packet matches
a rule, an action is taken (logging, triggering an alert).
Depending on the power of the equipment where SNORT is installed and the number of rules defined, the
number of packets analyzed may be more or less.

The logging and alert system


Depending on the decisions made by the detection engine, the packets can be logged or generate an alert.
Logging can be done by simple text files, files in the tcpdump format, or in other forms.

Output modules
The output modules can perform different operations depending on how you want to save the information
generated by the logging and alerting system:
• Simple recording in a file (like / log / snort / alerts),
• Send SNMP event notifications,
• Save in a database like MySQL,
• Transform into an XML format,
• Send SMB (Server Message Block) messages in the case of Windows machines,
• Email, SMS, etc.

8
SEC515
College of Technological Innovation

Using SNORT as a simple sniffer


In network sniffer mode, SNORT captures and displays packets at different levels of detail. No
configuration file is required.
Screen display
snort -v: Print the information contained in the TCP / IP headers

snort -dv: Print the information contained in the IP / UDP / TCP / ICMP headers

9
SEC515
College of Technological Innovation

snort -edv: Print information from MAC headers

snort -edv proto: Print only PROTO protocol messages (i.e., ip, tcp, udp, icmp)

10
SEC515
College of Technological Innovation

snort -h: help

Snort –help-options

the –I option allows you to specify the listening interface


Ctrl-C: Stop SNORT
In our case, we were able to stop snort with Ctrl-Z only.

11
SEC515
College of Technological Innovation

Task1
Objectives:
- Test the commands and find the different header fields by launching different applications (www, ftp,
mail…).
- Limit the display of data streams received to tcp protocol

In Scapy machine, we generated application traffic using “curl” tool

Using snort we sniffed tcp traffic. We are able to see source and destination IP and mac
addresses. We can also see protocol information and header values with snort sniffing mode.
We noticed TCP connection with the three-way handshake flags (syn, syn-ack and ack)

12
SEC515
College of Technological Innovation

Save to a file

- Watch how SNORT saves data in text format


- The same goes for the binary format. Use the command to read binary files
- What is the advantage of binary format over text format?
1- Binary logs are more efficient in terms of storage space compared to text logs, especially when
dealing with large volumes of data.
2- Reading and writing binary logs can be faster than text logs, especially when the logs are large.
3- Binary logs are more reliable than text logs because they are less likely to get messed up by
formatting mistakes or accidental changes.
Saving in text format
Packages can be saved to text mode files by adding the option “-l <directory name>”.
Create a log directory in your current directory, by running the following command:

mkdir log

snort -dev -l ./log -K ascii : Save the displays in files in the "log" directory

Several directories are created in the target directory. Each of these directories corresponds to a host and
contains several files. Each directory is identified by the IP address of the associated host. The files contain
data about different connections and different types of network data.

13
SEC515
College of Technological Innovation

The following displays the content of one of the logs

14
SEC515
College of Technological Innovation

Saving in binary format


On high-speed networks, saving data in ASCII format in a large number of different directories can place
a very heavy load on the system. SNORT can save the data to a binary file in tcpdump format (sniffer on
UNIX), and then watch it.

snort -l ./log -b: Save data to a binary file

snort -dev -r ./log /snort.log.xxxx : Read data to a file in binary format (find the xxxx under log directory)

15
SEC515
College of Technological Innovation

Task2

SCAPY
Scapy is an interactive package manipulation tool written in python. It is capable, among other things, of
intercepting traffic on a network segment, of generating packets in a large number of protocols, of taking
an imprint of the TCP / IP stack, of making a traceroute, of analyzing the computer network, etc. Scapy can
be used through a command interpreter using the scapy command or through python scripts.

It will allow us to perform penetration tests in the rest of the labs.

The documentation for scapy can be found at the following address:


http://www.secdev.org/projects/scapy/doc/usage.html#interactive-tutorial
It is possible to have documentation on the various scapy functions in the command interpreter using the
help () function (for example, help (IP)). To have all the fields of a protocol header, it suffices to display
the fields_desc attribute (for example IP.fields_desc).

For example, the following commands are used to create an IP datagram with a TTL of 123 and containing
as payload "HELLO" to 127.0.0.1 and send it to the network:

>>>ip=IP()
>>>ip.ttl=123
>>>ip.dst= «127.0.0.1 »
>>>ip.payload=« HELLO »
>>>ip
<IP ttl=123 dst=127.0.0.1 |<Raw load='HELLO'|>>
>>>send(ip)
.
sent 1 packets.
16
SEC515
College of Technological Innovation

Note: By using the commands provided to us in this lab, we were getting an error while trying to
send our crafted IP datagram. The error was related to ‘str’ object which most likely is the
payload.
So we attempted to craft it using another method as seen below

17
SEC515
College of Technological Innovation

Another way to do the same in a script:


#!/usr/bin/python
from scapy.all import *

ip=IP(dst="172.10.0.3", ttl=123)/"HELLO"
send(ip)

Task3
Start SNORT to display ICMP messages. Start SCAPY as a command interpreter. Recreate the ping
command with SCAPY. The generated ICMP message will contain as data "AAAABBBBCCCCCCCC".
Check with Snort that the message is worded correctly by looking at the ping response.

First, we used snort to sniff ICMP packets as seen here, we specified “docker0” interface and “icmp”
protocol to narrow down the traffic

To recreate the ping command using Scapy, we have to send an ICMP echo request (ping) packet to a
target IP address. We recreated ping command and added "AAAABBBBCCCCCCCC" as payload

18
SEC515
College of Technological Innovation

We checked the values of our packet through ls() command

We sent the packet and observed the traffic through snort. We were able to observe the request and
response as seen below.

19
SEC515
College of Technological Innovation

We also used python script and scapy module to create our own ping tool. It sends ICMP echo request
and displays the response (echo-reply) if any.

20
SEC515
College of Technological Innovation

OR using the following script:


This script sends an ICMP echo request packet to the target IP address and waits for a response. If a
response is received, it prints "host is up"; otherwise, it prints "host is down".

We sent the ICMP echo request to the user machine from Scapy machine and we received a response
which indicates that the user machine is up. Which is true in our case.

Using the fragment () function, split your ping into 8-byte fragments. Send the fragments and verify that
the ping response is correct.

The following commands will split the ICMP echo request packet into 8-byte fragments using Scapy's
fragment() function and send each fragment individually.

We can list all the three fragments using the following command

21
SEC515
College of Technological Innovation

We prepared snort to sniff for ICMP packets to observe the fragments sent.

The ICMP echo request packets are properly reassembled by the target machine and a response is sent
back, we can see the corresponding ICMP echo reply packets being captured by Snort, indicating that the
ping was successful.

We also used a python script to perform the same task.

22
SEC515
College of Technological Innovation

Signature based Intrusion detection using Snort


First, save the “snort.conf” file and rename it to snort.conf.bak.

Then, to improve Snort’s performance and avoid raising too many alerts, remove all rules, except
the one to local.rules.

23
SEC515
College of Technological Innovation

You must create your own rules (e.g., to detect a ping to google from scapy machine)

We added the following rule to detect a ping to google from scapy machine to “myrules.rules”
file which we created.

To test the rule, we sent a ping to google.com.

This rule will generate an alert whenever an ICMP packet is sent from the IP address 172.17.0.2
(scapy machine) to google.com, it will display the message (msg:"Ping to Google from 172.17.0.3")

Running snort in IDS mode

The -A console option in Snort specifies the alert output mode. In this case, it directs Snort to
output alerts to the console. When an alert is triggered by a packet matching a rule, Snort will
display information about the alert on the console, including details such as the timestamp,
source and destination IP addresses, protocol, and alert message. The -c snort.conf option
specifies the path to the Snort configuration file (snort.conf).

We can see that our rule was triggered, and an alert is displayed by Snort.

24
SEC515
College of Technological Innovation

In IDS mode, SNORT does not log all captured packets as the sniffer mode but enforces a set of
rules on each of them. If a packet matches a rule, then the packet is logged or an alert is raised.
Otherwise, the package is deleted. To do this, you must specify when starting SNORT a
configuration file for the various SNORT components (preprocessors, detection engine rules, etc.).

With snort.conf, the name of the Snort configuration file. This will apply the set of selected rules
to the analyzed packets to decide if an action should be taken or not. If an output directory is not
specified, the default is /etc/log/snort. If the Snort probe is operating for a long time, it is not
necessary to have an on-screen display which consumes time and power. It is also not necessary
to save headers for most applications. So, without the -e and -v options. Using the -A option, it is
possible to redirect screen alerts.

snort -i docker0 -A console -l monrepdelog -c /etc/snort/snort.conf

Configuring Snort
All the Snort parameters to be adjusted are in the snort.conf file located in the “etc” directory. In
this file, a large amount of information is provided in comments to allow the user to know the
usefulness of each section, of each variable and to be able to make a correct configuration.

We will now describe the most important sections of the snort.conf file.

Network configuration
The configuration of an Intrusion Detection System on a network naturally depends on the
topology of this network, its address ranges, the servers with which it is equipped, etc. By default,
Snort will analyze all the packets of all IP addresses on the network. This setting choice is made
using the homenet variable that should be set as follows: var $HOME_NET$ any (beware of
Debian you must modify /etc/snort/debian.snort.conf because the values of the variable
$Home_Net takes priority in this file)
If the user only wants to analyze the packets from certain IP addresses, he can enter address ranges,
particular IPs, etc.

Editing $HOME_NET$ in snort.conf file:

Editing $HOME_NET$ in /etc/snort/debian.snort.conf

25
SEC515
College of Technological Innovation

Preprocessors configuration
Preprocessors were introduced in the version 1.5 of Snort (and are present in the version we are
using). Preprocessors extend the functionality of Snort by allowing users and programmers to add
or remove modules.
From a technical point of view, the preprocessor is executed before the detection engine is called,
but after the packet has been decoded. Preprocessors are loaded and configured using the
preprocessor keyword. The directive format of a preprocessor in a snort rule is of the form:

preprocessor <name> : <options>

The different options specific to each preprocessor are given in the manual at the following address
http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node17.html

Task4
Now you are going to test two preprocessors.
Please uncomment the include lines in snort.conf that reference the rules files:
include $PREPROC_RULE_PATH/preprocessor.rules
include $PREPROC_RULE_PATH/decoder.rules

If you are using Alpine, you need to download the files preprocessor.rules and decoder.rules
from here https://github.com/gruberasheridc/snort-2.9.8.0/tree/master/preproc_rules and add
them to the folder preproc_rules that you need to create if not existing.

We downloaded the missing files and created preproc_rules directory.

26
SEC515
College of Technological Innovation

Arpspoof
Via SCAPY, build an ARP request to retrieve the MAC address of another machine connected to
your local machine. Check the result.

Using Scapy, we crafted and sent an ARP request to the user machine and waited for a response.
The received response contains the MAC address which was displayed to us as seen below.

OR, a second method is by using arping function in scapy

We can also provide a subnet, to get all the MAC addresses in the network. We found the mac
addresses of snort machine and our target machine

27
SEC515
College of Technological Innovation

We then created this script to get a formatted output (our own created version of arping)

The output:

To verify, we launched “ifconfig” command in our target machine/use machine

One of the techniques for listening for traffic is to modify the ARP cache of a machine. Reproduce
this type of attack with SCAPY which has the arpcachepoison function. The arpcachepoison
syntax (@IP of the machine to attack, @IP that you want to associate with your @MAC). By
analyzing with snort explain how this attack works. http://en.wikipedia.org/wiki/ARP_spoofing

ARP cache poisoning, also known as ARP spoofing, is a type of attack where an attacker sends
falsified Address Resolution Protocol (ARP) messages over a local area network. These messages
associate the attacker's MAC address with the IP address of a legitimate device, such as the user
machine. As a result, network traffic intended for the user machine is redirected to the attacker's
machine. This allows the attacker to intercept, modify, or block the traffic, potentially leading to
unauthorized access to sensitive information or the ability to conduct further attacks. Detecting
ARP cache poisoning attacks can be challenging, but monitoring network traffic and using
Intrusion Detection Systems (IDS) like Snort can help identify and mitigate these threats.

28
SEC515
College of Technological Innovation

To know more about the “arpcachepoison” function we used the help command in Scapy

We analyzed the traffic using tcpdump (we were not able to see the traffic using snort in sniffing
mode). We can see arp requests and responses sent using arpcachepoison method.

Victim ARP table before the attack

Victim ARP table After the attack

To reset the arp table with the legitimate mac address, we can simply ping the ip address of
172.17.0.1

29
SEC515
College of Technological Innovation

Reproduce the same attack without using the arpcachepoison () command, i.e., just with ethernet
and arp entities. You must use sendp () to send a frame.

We created the following script that reproduce the same attack. It uses “get_mac” function that
sends arp requests and retrieves mac addresses of the victim machine from the response, which we
will need to perform the attack. It then uses “spoof” function that performs arp spoofing attack.
The function takes two arguments, target ip and machine ip, to send forged ARP packet to a victim
machine. sendp() is used to send packets at Layer 2 (Data Link Layer) of the OSI model. This
function allows us to craft and send packets directly onto the network without relying on the
operating system's network stack.

30
SEC515
College of Technological Innovation

User machine ARP() table after using the script

Using snort, we were getting these warning messages:

Configure the arpspoof preprocessor to detect this type of message. Test with scapy that snort
detects this type of message.

In snort.conf, we configured arpspoof preprocessor as seen below

After enabling arpspoof preprocessor and launching the attack again with scapy, we used snort in
IDS mode. we were able to detect the attack and receive alerts as seen below

31
SEC515
College of Technological Innovation

Scanning
One of the scanning techniques is to send a TCP segment with the SYN bit set to 1 over a range
of ports (for example from 1 to 1024)

• Determine the potential preprocessor that can help with detection of scans

As mentioned earlier in the explanation of this lab report of different preprocessors used by
snort, we learned that the sfPortscan preprocessor is designed to detect various port scan
attacks, including SYN scans. We modified the preprocessor sensitivity to “high” in snort.conf

• Test with scapy by sending such segments with your PC as destination address.

To test, I opened python server on my PC then created a script to scan for open ports using
scapy.

This Scapy code performs a SYN scan on a target machine (IP address: 192.168.0.182) to
discover open ports. It iterates over a range of ports (1 to 1024) and crafts TCP SYN packets
for each port. These packets are sent using sr1() and the responses are analyzed. If a response
is received and it has a TCP layer with the SYN-ACK flag set, the code determines that the
port is open and prints a message indicating so.

32
SEC515
College of Technological Innovation

We can see that the open port was detected using this scanning technique in scapy

Using snort IDS, we were able to detect the scan as seen below

• What is the name of this type of scanning? TCP SYN scan


• Reproduce this scan with nmap
-sS: Performs a SYN scan

Building Snort rules


In this section, we explain the construction of a snort rule. The syntax of Snort rules is relatively
simple and flexible, and allows you to build quite powerful rules. A rule is written completely on
a single line (Snort does not manage line breaks) and it is divided into 2 main parts:

The rule header that contains as information


• the action of the rule, i.e. the reaction of snort according to the inspected packets;
• the protocol that is used for data transmission (Snort considers three: TCP, UDP and
ICMP);
• the source and destination IP addresses and their mask;
• and the source and destination ports on which to check the packets.

The options of the rule which contains as information


• the alert message.
• alert conditions. All the conditions allowing to accept or reject the packet must be true for
the packet to verify the rule and for the corresponding action to be taken.

The rule header


We define here the action to be taken and the packets that we want to inspect according to their
type, their origin and their destination. We mean by action what Snort will do when it finds a
packet that matches the criteria of the rule provided. There are 5 actions in Snort:
• alert: generates a defined alert and logs the packet.
• log: log the packet.
• pass: ignore the packet.
• activate: make an alert and activate a dynamic rule.
• dynamic: remains passive until activated by an activate rule and then acts as a log rule.

3 protocols can be analyzed using Snort :


33
SEC515
College of Technological Innovation

• tcp;
• udp;
• icmp

We give then the ip address or a list of ip addresses with a subnet mask if necessary. You can also
use a negation operator “!” Which tells Snort to consider all but these ip addresses. We can also
pass it “any” which says to consider all the ip addresses. Then comes the port which can be defined
precisely or over an interval. For example “1: 1024” means that we scan all ports from 1 to 1024.
If we use a single port number with the “:” we specify to check all ports greater or equal or more
small or equal to the given port depending on whether the “:” are in front of or behind the port
number. The operators “!”And “any” can also be used.

The direction of the traffic to which the rules apply is indicated by one of the operators: “->”, “<-
” or ”<>”. The last one being the bidirectional operator.

The options of rules


These options are the heart of the detection. The various options can be combined as desired to
form the most suitable rule for spotting the packages that interest us. Two consecutive options are
separated by “;”. Here is a list of the options available in Snort with a brief description for each
option.
- msg - display a message in alerts and log packets
- logto - log the package to a user-named file instead of standard output
- content - search for a pattern in the load of a packet
- offset - change the content option, set the offset of the start of the pattern match attempt
- depth - change the content option, set the maximum search depth for the pattern match
attempt
- nocase - corresponds to the content string procedure without sensitivity to upper / lower case
differences
- session - displays the application layer information for the given session
- ip_proto - allows to define a protocol above IP
- classtype - assigns a classification to the attack (virus, trojan, ...)
- flow - allows you to set the direction of a flow, the state of the connection, ...
- react - active response (blocks websites)
- …

False negatives & False positives


False negatives occur when the IDS does not detect an attack on the network while it is occurring.
False positives occur when IDS reports an attack on the network when it is authorized activity.

False positives diminish the credibility one can have in an IDS. By tuning Snort specifically to the
network being analyzed, their number can be greatly reduced (hence the importance of configuring
Snort !!). However, an IDS should generally generate a reasonable number of false positives. If it
does not generate any, there is a good chance that false negatives will occur and therefore real
attacks will go undetected. We must therefore find a balance between these two parameters.

34
SEC515
College of Technological Innovation

Task5
Start by commenting out or removing all “include $RULE_PATH/*” lines (you are going to create
rules, they should not conflict with those already defined in snort). Create your rules file and add
this file to snort.conf

We started by commenting all “include $RULE_PATH/*” lines.

Creating our own rule file

Adding the file to snort.conf

Running snort in IDS mode to test the rule

35
SEC515
College of Technological Innovation

Question 1: Analysis of simple rules:


Add the following rule to the local.rules file:
alert ip any any -> any any (msg:"BAD-TRAFFIC IP Proto 53 SWIPE"; ip_proto:53; reference:bugtraq,8211;
reference:cve,2003-0567; classtype:non-standard-protocol; sid:2186; rev:3;). Build a packet triggering this rule
and watch the alert issued.

[Analyzing the rule]


alert: Indicates that an alert should be generated when this rule matches.
ip any any -> any any: Matches any IP traffic going from any source to any destination.
msg:"BAD-TRAFFIC IP Proto 53 SWIPE": A descriptive message for the alert.
ip_proto:53: Matches traffic with IP protocol 53.
reference:bugtraq,8211: References a Bugtraq entry related to this rule.
reference:cve,2003-0567: References a CVE entry related to this rule.
classtype:non-standard-protocol: Specifies the class type of the alert.
sid:2186: Specifies the Snort ID for this rule.
rev:3: Specifies the revision number of this rule.

Added the rule to local.rules and enabled local.rules in snort.conf

The following IP packet should trigger this rule

We started snort in IDS mode to see the alert

36
SEC515
College of Technological Innovation

Question 2: Let’s test the IP fragmentation


1) Repeat with scapy the ping exercise by adding a message containing the string
“AAAABBBBCCCCCCCC”

2) Write a rule that detects ICMP echo request messages containing


“AAAABBBBCCCCCCCC”. Check that an alert is generated with scapy.

We added the following rule to local.rules file


alert icmp any any -> any any (msg:"ICMP Echo Request with specific payload";
content:"AAAABBBBCCCCCCCC"; icmp_type:8; sid:100002;)

We sent the crafted ICMP packet with the specific payload and used snort in IDS mode to
detect the packet as seen below:

3) Change the rule to alert when the ICMP message contains BBBBAAAACCCCCCCC.

37
SEC515
College of Technological Innovation

4) Split the ICMP message into an 8-byte IP fragment. Modify the first fragment (index 0) so
that it contains in addition to the ICMP header the data BBBBAAAA. Send all the
fragments and verify that an alert is generated. Notice that the first fragment overwrites the
second when reassembling the final package.

We modifyed the first fragment by adding ‘BBBBAAAA’ to the header. But we were not able
to detect the re-assembeled packet with snort.

We tried to fix it by replacing the payload of fragment[0] with our data as seen below.

We were also not successful, we had to look at the sent re-assembled packet using snort
sniffer and noticed the following.

We realized that we had a mistake in the order of our payload. Our first approach was
correct but we needed to append the data to the payload of index 0 and not before. So we
created the new fragments using the following approach

We observed the traffic again with snort. We can finally see the payload in the correct
order.

38
SEC515
College of Technological Innovation

We used snort now in IDS mode and, finally! The packet was detected successfully.

39
SEC515
College of Technological Innovation

Conclusion

In conclusion, this lab provided a comprehensive hands-on experience with Snort, highlighting
its capabilities as a network intrusion detection system. By using Snort as a sniffer, we were able
to passively monitor network traffic and gain insights into the types of packets traversing the
network. Configuring and utilizing Snort preprocessors allowed us to enhance its detection
capabilities by preprocessing packets before analysis. Building detection rules tailored to specific
network events further demonstrated Snort's flexibility in detecting and alerting on suspicious
activity. The lab environment, consisting of three Docker machines, provided a controlled and
isolated setup for testing and experimentation. Through the tasks performed in this lab, we
gained practical skills in configuring and using Snort, analyzing network traffic, and creating
custom detection rules. Overall, this lab was instrumental in deepening our understanding of
Snort's role in network security and its effectiveness in detecting and mitigating network attacks.

40
SEC515

You might also like