In the previous article, we installed and configured Snort, and understood its basic functionalities. Today, we will explore Snort’s primary feature in respect to blue team operations, i.e. Snort as an Intrusion Detection System by writing effective rules. Snort’s ability to detect or prevent security incidents depends upon rules. Today we will see how to write effective rules to detect malicious or unintended traffic on a network. If you haven’t already read the previous article, please find it below:
Understanding Snort Rules Structure
Understanding Snort rules is essential to writing them. Snort rules follow a basic structure that must be adhered to while writing snort rules.
.png "snort rules structure")
The rule structure is explained below:
- ACTION: Defines action to perform when the rule is matched. In context to Intrusion Detection, it is usually “alert”. If used as an Intrusion Prevention System, the “drop” or “reject” option is used. The difference between drop and reject options is that the drop option only terminates the specific packet for which the rule is matched, while the reject option terminates the entire connection with the host.
- PROTOCOL: Defined the type of traffic. At present, Snort supports TCP, UDP, ICMP, and IP traffic.
- SOURCE IP
- SOURCE PORT
- DIRECTION: The direction operator indicates the orientation of the traffic to which the rule applies. It is either “<>” which indicates bidirectional flow, or “→” which indicates source to destination flow.
- DESTINATION IP
- DESTINATION PORT
- RULE OPTIONS: The rule options define all other necessary details which make the rules more robust and meaningful. At the very least; Message, SID, and Revision Number have to be defined in rule options.
Anatomy of a Snort Rule
Now that we understand the rule structure, let’s take a look at a simple rule that detects ICMP Pings on the network.
alert icmp any any -> $HOME_NET any (msg:"ICMP Ping Detected"; sid:"1000001", rev:1)
Let’s break down the rule syntax bit by bit:
- alert: The rule will generate alerts when matched.
- icmp: Since we want to detect Ping requests, we choose the ICMP protocol.
- any: Requests coming from any host from any network.
- any: Requests coming from any port. Since Ping requests are not made from a standard port, we leave it to any.
- <>: Monitor all traffic, whether coming to or going from the internal network.
- any: Response sent from any port. Since Ping responses are not sent from a standard port, we leave it to any.
- msg: Specified alert message will be shown when the rule is matched.
- sid: Defines rule id. Each SID needs to be in the proper format. The format is mentioned below:
- <100: Reserved rules
- 100-999,999: Rules came with the build.
- >=1,000,000: Rules created by the user.
- rev: Defines revision id. Revision ID indicates the maturity of rules.
Let's see this rule in action with Intrusion Detection. First, we need to write our new rule in local.rules file and then start Snort in Intrusion Detection mode. If you haven't already read the previous article where we walked through Snort modes and Configurations, please read it before proceeding any further:
Intrusion Detection with Snort
Now we will see Live Intrusion Detection with Snort with our new rule. First, disable all community rules in the snort.conf file by commenting them out.
Then edit the local.rules file and add the custom rule.
Now we will start Snort in Intrusion Detection mode with alerts set to Terminal mode.
sudo snort -q -c /etc/snort/snort.conf -i eth0 -A consoles
Writing Custom Snort Rules
Snort rules are not limited to detecting simple network behavior. Snort rules are very powerful in respect to how they detect and prevent security incidents. Rules can be made more robust when written efficiently and combined with the right options. In this section, we will see some of the rule options that we can leverage to write effective rules.
We will write the following rules as part of our practice exercise to demonstrate how effective Snort rules are:
- Snort Rule to detect FTP connection on a network
- Snort Rule to detect Failed FTP connections
- Snort Rule to detect TCP flags.
All 3 rules are practically demonstrated in a virtual network comprised of 2 virtual machines. One is Kali Linux 2022.3, and the other is Ubuntu Server 18.04. An FTP server is active on the Ubuntu server. Please remember the virtual network for the rest of the article.
#1 Snort Rule to Detect FTP Connections
Let's start with a basic rule. The target is to write a rule that will generate an alert whenever someone tries to authenticate with an FTP (File Transfer Protocol) server in our network, whether the connection is established or failed.
alert tcp any any <> $HOME_NET 21 (msg:"FTP authentication attempt made"; sid:10000002; rev:1)
- alert: Generate an alert when the rule is matched.
- tcp: Since FTP is part of the TCP protocol suite.
- any: any host
- any: any port
- <>: bidirectional flow
- 21: Since FTP connections are established at port 21.
- msg: Display the specified message when the rule is matched.
Let's see this rule in action. We will connect to the FTP server (which is active on Ubuntu VM) from the Kali Linux VM.
#2 Snort Rule to Detect Failed FTP Connections
Alerting for every authentication attempt will create a heap of alerts. So let's write a rule to log only failed attempts. The target is to write a rule that will generate alerts whenever a failed authentication attempt is made. To achieve this, we need to perform content matching on the authentication failure errors. Since FTP is a plain-text protocol and communication is not encrypted, this can be performed with content rule option.
First, we need to create an authentication failure error and copy the error message for writing the rule. We can do this by trying to connect with the FTP server and using a random wrong password to generate the error.
Now we will use this error to write the desired rule with content matching.
alert tcp any any <> $HOME_NET 21 (msg:"FTP authentication attempt failure"; content:"Login incorrect."; sid:1000003; rev:1;)
Let's see this rule in action. First, we will connect to the FTP server with the right password to ensure that alerts are not generated for successful authentication attempts. Then, we will try to connect with an obviously wrong password to confirm that our rule is working and generate alerts for only failed authentication attempts.
NOTE: Make sure to comment out the previous rule.
#3 Snort Rule to Detect TCP Flags
Let's write a different rule this time. How about detecting TCP flags and generating alerts when someone tries to do a port scan on your network? Sounds amazing. The target is to generate alerts when a certain TCP flag is found in a packet, warning us about a potential port scan. We can achieve this by using the flags option.
Let's see how we can detect SYN Scans made by Nmap.
alert tcp any any -> $HOME_NET any (msg:"SYN Scan attempt"; flags:S; sid:1000004; rev:1;)
The value "S" with flags option is to define the SYN packet. Let's see this rule in action. First, start snort in intrusion detection mode. Then perform a Nmap Syn Scan to generate the alert.
Here is a list of other values you can use with the flags option:
| Value | TCP Flag |
|---|---|
| F | FIN |
| S | SYN |
| R | RST |
| P | PSH |
| A | ACK |
| U | URG |
That's it for this article. We wrote some powerful rules to demonstrate what Snort is capable of doing, and its ability to perform intrusion detection. Showing all options is not possible in one article, thus explore more by understanding different rules. You might find more interesting rules in Github, or have a look at default community rules to do so. In later article we will see Snort's Intrusion Prevention power. Keep learning at Security Bytes.
