Views: 7
Snort Rules
Each rule should have a type of action, protocol, source and destination IP, source and destination port and an option. Remember, Snort is in passive mode by default. So most of the time, we will use Snort as an IDS. We will need to start “inline mode” to turn on IPS mode.
The Snort rule structure is easy to understand but difficult to produce. We should be familiar with rule options and related details to create efficient rules.
Rules cannot be processed without a header. Rule options are “optional” parts. However, it is almost impossible to detect sophisticated attacks without using the rule options.
Action | There are several actions for rules. Make sure you understand the functionality and test it before creating rules for live systems. The most common actions are listed below.alert: Generate an alert and log the packet.log: Log the packet.drop: Block and log the packet.reject: Block the packet, log it and terminate the packet session. |
Protocol | Protocol parameter identifies the type of the protocol that filtered for the rule.Note that Snort2 supports only four protocols filters in the rules (IP, TCP, UDP and ICMP). However, we can detect the application flows using port numbers and options. For instance, if we want to detect FTP traffic, we cannot use the FTP keyword in the protocol field but filter the FTP traffic by investigating TCP traffic on port 21. |
IP and Port Numbers
IP Filtering | alert icmp 192.168.1.56 any <> any any (msg: “ICMP Packet From “; sid: 100001; rev:1;) This rule will create an alert for each ICMP packet originating from the 192.168.1.56 IP address. |
Filter an IP range | alert icmp 192.168.1.0/24 any <> any any (msg: “ICMP Packet Found”; sid: 100001; rev:1;) This rule will create an alert for each ICMP packet originating from the 192.168.1.0/24 subnet. |
Filter multiple IP ranges | alert icmp [192.168.1.0/24, 10.1.1.0/24] any <> any any (msg: “ICMP Packet Found”; sid: 100001; rev:1;) This rule will create an alert for each ICMP packet originating from the 192.168.1.0/24 and 10.1.1.0/24 subnets. |
Exclude IP addresses/ranges | “negation operator” is used for excluding specific addresses and ports. Negation operator is indicated with “!” alert icmp !192.168.1.0/24 any <> any any (msg: “ICMP Packet Found”; sid: 100001; rev:1;) This rule will create an alert for each ICMP packet not originating from the 192.168.1.0/24 subnet. |
Port Filtering | alert tcp any any <> any 21 (msg: “FTP Port 21 Command Activity Detected”; sid: 100001; rev:1;) This rule will create an alert for each TCP packet sent to port 21. |
Exclude a specific port | alert tcp any any <> any !21 (msg: “Traffic Activity Without FTP Port 21 Command Channel”; sid: 100001; rev:1;) This rule will create an alert for each TCP packet not sent to port 21. |
Filter a port range (Type 1) | alert tcp any any <> any 1:1024 (msg: “TCP 1-1024 System Port Activity”; sid: 100001; rev:1;) This rule will create an alert for each TCP packet sent to ports between 1-1024. |
Filter a port range (Type 2) | alert tcp any any <> any :1024 (msg: “TCP 0-1024 System Port Activity”; sid: 100001; rev:1;) This rule will create an alert for each TCP packet sent to ports less than or equal to 1024. |
Filter a port range (Type 3) | alert tcp any any <> any 1025: (msg: “TCP Non-System Port Activity”; sid: 100001; rev:1;) This rule will create an alert for each TCP packet sent to source port higher than or equal to 1025. |
Filter a port range (Type 4) | alert tcp any any <> any [21,23] (msg: “FTP and Telnet Port 21-23 Activity Detected”; sid: 100001; rev:1;) This rule will create an alert for each TCP packet sent to port 21 and 23. |
Direction
The direction operator indicates the traffic flow to be filtered by Snort. The left side of the rule shows the source, and the right side shows the destination.
- -> Source to destination flow.
- <> Bidirectional flow
Note that there is no “<-” operator in Snort.
Snort Rule Options
There are three main rule options in Snort;
- General Rule Options – Fundamental rule options for Snort.
- Payload Rule Options – Rule options that help to investigate the payload data. These options are helpful to detect specific payload patterns.
- Non-Payload Rule Options – Rule options that focus on non-payload data. These options will help create specific patterns and identify network issues.
General Rule Options
Msg | The message field is a basic prompt and quick identifier of the rule. Once the rule is triggered, the message filed will appear in the console or log. Usually, the message part is a one-liner that summarises the event. |
Sid | Snort rule IDs (SID) come with a pre-defined scope, and each rule must have a SID in a proper format. There are three different scopes for SIDs shown below. <100: Reserved rules 100-999,999: Rules came with the build. >=1,000,000: Rules created by user. Briefly, the rules we will create should have sid greater than 100.000.000. Another important point is; SIDs should not overlap, and each id must be unique. |
Reference | Each rule can have additional information or reference to explain the purpose of the rule or threat pattern. That could be a Common Vulnerabilities and Exposures (CVE) id or external information. Having references for the rules will always help analysts during the alert and incident investigation. |
Rev | Snort rules can be modified and updated for performance and efficiency issues. Rev option help analysts to have the revision information of each rule. Therefore, it will be easy to understand rule improvements. Each rule has its unique rev number, and there is no auto-backup feature on the rule history. Analysts should keep the rule history themselves. Rev option is only an indicator of how many times the rule had revisions. alert icmp any any <> any any (msg: “ICMP Packet Found”; sid: 100001; reference:cve,CVE-XXXX; rev:1;) |
Payload Detection Rule Options
Content | Payload data. It matches specific payload data by ASCII, HEX or both. It is possible to use this option multiple times in a single rule. However, the more you create specific pattern match features, the more it takes time to investigate a packet. Following rules will create an alert for each HTTP packet containing the keyword “GET”. This rule option is case sensitive! ASCII mode – alert tcp any any <> any 80 (msg: “GET Request Found”; content:”GET”; sid: 100001; rev:1;) HEX mode – alert tcp any any <> any 80 (msg: “GET Request Found”; content:”|47 45 54|”; sid: 100001; rev:1;) |
Nocase | Disabling case sensitivity. Used for enhancing the content searches. alert tcp any any <> any 80 (msg: “GET Request Found”; content:”GET”; nocase; sid: 100001; rev:1;) |
Fast_pattern | Prioritise content search to speed up the payload search operation. By default, Snort uses the biggest content and evaluates it against the rules. “fast_pattern” option helps you select the initial packet match with the specific value for further investigation. This option always works case insensitive and can be used once per rule. Note that this option is required when using multiple “content” options. The following rule has two content options, and the fast_pattern option tells to snort to use the first content option (in this case, “GET”) for the initial packet match. alert tcp any any <> any 80 (msg: “GET Request Found”; content:”GET”; fast_pattern; content:”www”; sid:100001; rev:1;) |
Non-Payload Detection Rule Options
There are rule options that focus on non-payload data. These options will help create specific patterns and identify network issues.
ID | Filtering the IP id field. alert tcp any any <> any any (msg: “ID TEST”; id:123456; sid: 100001; rev:1;) |
Flags | Filtering the TCP flags. F – FIN S – SYN R – RST P – PSH A – ACK U – URG alert tcp any any <> any any (msg: “FLAG TEST”; flags:S; sid: 100001; rev:1;) |
Dsize | Filtering the packet payload size. dsize:min<>max; dsize:>100 dsize:<100 alert ip any any <> any any (msg: “SEQ TEST”; dsize:100<>300; sid: 100001; rev:1;) |
Sameip | Filtering the source and destination IP addresses for duplication. alert ip any any <> any any (msg: “SAME-IP TEST”; sameip; sid: 100001; rev:1;) |
Once we create a rule, it is a local rule and should be in the “local.rules” file. This file is located under “/etc/snort/rules/local.rules”. A quick reminder on how to edit the local rules is shown below.
sudo gedit /etc/snort/rules/local.rules
That is the contents of “local.rules” file.
http://manual-snort-org.s3-website-us-east-1.amazonaws.com/
Note that there are some default rules activated with snort instance. These rules are deactivated to manage your rules and improve your exercise experience. For further information, please refer to the Snort manual.
Quick Summary
Main Components of Snort
- Packet Decoder – Packet collector component of Snort. It collects and prepares the packets for pre-processing.
- Pre-processors – A component that arranges and modifies the packets for the detection engine.
- Detection Engine – The primary component that process, dissect and analyse the packets by applying the rules.
- Logging and Alerting – Log and alert generation component.
- Outputs and Plugins – Output integration modules (i.e. alerts to syslog/mysql) and additional plugin (rule management detection plugins) support is done with this component.
There are three types of rules available for snort
- Community Rules – Free ruleset under the GPLv2. Publicly accessible, no need for registration.
- Registered Rules – Free ruleset (requires registration). This ruleset contains subscriber rules with 30 days delay.
- Subscriber Rules (Paid) – Paid ruleset (requires subscription). This ruleset is the main ruleset and is updated twice a week (Tuesdays and Thursdays).
You can download and read more on the rules here.
Note: Once you install Snort2, it automatically creates the required directories and files. However, if you want to use the community or the paid rules, you need to indicate each rule in the snort.conf file.
Since it is a long, all-in-one configuration file, editing it without causing misconfiguration is troublesome for some users. That is why Snort has several rule updating modules and integration tools. To sum up, never replace your configured Snort configuration files; you must edit your configuration files manually or update your rules with additional tools and modules to not face any fail/crash or lack of feature.
- snort.conf: Main configuration file.
- local.rules: User-generated rules file.
Overview of the main configuration file (snort.conf)
sudo gedit /etc/snort/snort.conf
“Step #1: Set the network variables.” section
This section manages the scope of the detection and rule paths.
TAG NAME | INFO | EXAMPLE |
---|---|---|
HOME_NET | That is where we are protecting. | ‘any’ OR ‘192.168.1.1/24’ |
EXTERNAL_NET | This field is the external network, so we need to keep it as ‘any’ or ‘!$HOME_NET’. | ‘any’ OR ‘!$HOME_NET’ |
RULE_PATH | Hardcoded rule path. | /etc/snort/rules |
SO_RULE_PATH | These rules come with registered and subscriber rules. | $RULE_PATH/so_rules |
PREPROC_RULE_PATH | These rules come with registered and subscriber rules. | $RULE_PATH/plugin_rules |
“Step #2: Configure the decoder.” section
In this section, you manage the IPS mode of snort. The single-node installation model IPS model works best with “afpacket” mode. You can enable this mode and run Snort in IPS.
TAG NAME | INFO | EXAMPLE |
---|---|---|
#config daq: | IPS mode selection. | afpacket |
#config daq_mode: | Activating the inline mode | inline |
#config logdir: | Hardcoded default log path. | /var/logs/snort |
Data Acquisition Modules (DAQ) are specific libraries used for packet I/O, bringing flexibility to process packets. It is possible to select DAQ type and mode for different purposes.
There are six DAQ modules available in Snort;
- Pcap: Default mode, known as Sniffer mode.
- Afpacket: Inline mode, known as IPS mode.
- Ipq: Inline mode on Linux by using Netfilter. It replaces the snort_inline patch.
- Nfq: Inline mode on Linux.
- Ipfw: Inline on OpenBSD and FreeBSD by using divert sockets, with the pf and ipfw firewalls.
- Dump: Testing mode of inline and normalisation.
The most popular modes are the default (pcap) and inline/IPS (Afpacket).
“Step #6: Configure output plugins” section
This section manages the outputs of the IDS/IPS actions, such as logging and alerting format details. The default action prompts everything in the console application, so configuring this part will help you use the Snort more efficiently.
“Step #7: Customise your ruleset” section
TAG NAME | INFO | EXAMPLE |
---|---|---|
# site specific rules | Hardcoded local and user-generated rules path. | include $RULE_PATH/local.rules |
#include $RULE_PATH/ | Hardcoded default/downloaded rules path. | include $RULE_PATH/rulename |
Note that “#” is commenting operator. You should uncomment a line to activate it.
Sample Snort Rules
Snort rule to detect all TCP port 80 traffice
alert tcp any any -> any 80 (msg:"TCP traffic on port 80 detected"; sid:1000001; rev:1;)
Printig the first 63 packets from snort.log.1717890906
to the screen and looking up the value at the end of the output:
sudo snort -r snort.log.1717890906 -A full -n 63