Snort
Snort is one of the most widely used open-source IDS solutions developed in 1998.
- It uses signature-based and anomaly-based detections to identify known threats. These are defined in the rule files of the Snort tool.
- Several built-in rule files come pre-installed in this tool’s package. These built-in rule files contain a variety of known attack patterns. Snort’s built-in rules can detect a lot of malicious traffic for you.
- However, you can configure Snort to detect specific types of network traffic not covered by the default rule files by creating custom rules based on your requirements. You can also disable any built-in detection rules if they don’t point to harmful traffic for your system or network and define some custom rules instead.
Modes of Snort#
| Mode | Description | Use Case |
|---|---|---|
| Packet sniffer mode | This mode reads and displays network packets without performing any analysis on them. The packet sniffer mode of Snort does not directly relate to IDS capabilities, but it can be helpful in network monitoring and troubleshooting. In some cases, system administrators might need to read the traffic flow without performing any detection to diagnose specific issues. In this case, they can utilize the packet sniffer mode of Snort. This mode allows you to display the network traffic on the console or even output it in a file. | The network team observes some network performance issues. To diagnose the issue, they need detailed insights into the network traffic. For this purpose, they can utilize Snort’s packet sniffer mode. |
| Packet logging mode | Snort performs detection on the network traffic in real-time and displays the detections as alerts on the console for the security administrators to take action. However, in some cases, the network traffic needs to be logged for later analysis. The packet logging mode of Snort allows you to log the network traffic as a PCAP (standard packet capture format) file. This includes all the network traffic and any detections from it. Forensic investigators can use these Snort log files to perform the root cause analysis of previous attacks. | The security team needs to initiate a forensic investigation of a network attack. They would need the traffic logs to perform the root cause analysis. The network traffic logged through Snort’s packet logging mode can help them. |
| Network Intrusion Detection System mode | Snort’s NIDS mode is the primary mode that monitors network traffic in real-time and applies its rule files to identify any match to the known attack patterns stored as signatures. If there is a match, it generates an alert. This mode provides the main functionality of an IDS solution. | The security team must proactively monitor their network or systems to detect potential threats. They can leverage Snort’s NIDS mode to achieve this. |
| The most relevant use of Snort as an IDS comes from its NIDS mode. However, Snort can be used in any of the above modes depending upon the requirement. |
Usage#
Capture packets with verbose output:
sudo snort -v -i interfaceplaintext- During Snort installation, you must provide your network interface and range. You can run Snort normally, where it only captures the traffic intended for your host.
- If you want to use Snort to capture and detect intrusions in your whole network, you must turn on the promiscuous mode of your host’s network interface.
- Snort has some built-in rule files, a configuration file, and other files. These are stored in the
/etc/snortdirectory. - In Snort 3, this location is not fixed. It is chosen when Snort is installed, so it can differ between systems.
- A build from source commonly uses
/usr/local/etc/snort. Whichever location is used, you load a configuration by passing its path to the-cflag. - The key file for Snort is its configuration file
snort.lua, where you can specify which rule files to enable, which network range to monitor, and allow other settings. - The rule files are stored in the
rulesfolder.
Rule Format#
A sample rule to detect ICMP packets (usually used when you ping a host) coming from any IP address and port and reaching the home network (the network range is defined in Snort’s configuration file) to any port. Once such traffic is detected, it generates “Ping Detected” alerts.
alert icmp any any -> $HOME_NET any (msg:”Ping Detected”; sid:10001; ”rev:1;)
| | | | | | | | |
Action | Src IP | Dest IP | Message Signature ID(sid) Rule revision (rev)
Protocol Src Port Dest Port Rule MetadataplaintextThe details of the components involved in this rule are given below:
- Action: This specifies which action to take when the rule triggers. In this case, we have the action to “alert” when the traffic matches this rule.
- Protocol: This refers to the protocol that matches this rule. In this case, we use the protocol “ICMP” when pinging a host.
- Source IP: This determines the IP originating from the traffic. Since we want to detect traffic from any source IP, we set this as “any”.
- Source port: This determines the port from which the traffic originates. Since we want to detect traffic from any source port, we set this as “any”.
- Destination IP: This specifies the destination IP to which the matching traffic comes; it generates the alert. In this case, we used “$HOME_NET”. This is a variable, and we defined its value as our whole network’s range in Snort’s configuration file.
- Destination port: This specifies the port the traffic would reach. Since we want to detect traffic coming to any port, we set it to “any.”
- Rule metadata: Every rule has some metadata. That is defined at the end of the rule in parentheses. The following are its components:
- Message (msg): This describes the message displayed when the subject rule triggers. The message should indicate the type of activity detected. In this case, we used “Ping Detected”.
- Signature ID (sid): Every rule has a unique identifier that differentiates it from others. This identifier is called the signature ID (sid). In this case, we set the sid to “10001”.
- Rule revision (rev): This sets the rule’s revision number. Every time the rule is modified, its revision number is incremented, which helps in tracking changes to any rule.
Rule Creation#
Let’s paste the sample rule explained above into the custom “local.rules” file in the Snort rules directory.
sudo nano /etc/snort/rules/local.rulesplaintextNow, add the following rule after the already present rules to the file:
alert icmp any any -> 127.0.0.1 any (msg:"Loopback Ping Detected"; sid:10003; rev:1;)plaintextRule Testing#
Let’s first start the Snort tool to detect any intrusions defined in the rule file.
Running Snort for Detections
sudo snort -q -l /var/log/snort -i lo -A alert_fast -c /etc/snort/snort.luashellAs this rule is designed to alert us on any ICMP packets to our loopback address, let’s try to ping our loopback address to see if our rule works:
ping 127.0.0.1shellExample Snort Output
ubuntu@tryhackme:~$ sudo snort -q -l /var/log/snort -i lo -A alert_fast -c /etc/snort/snort.lua
07/24-10:46:52.401504 [**] [1:1000001:1] "Loopback Ping Detected" [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1
07/24-10:46:53.406552 [**] [1:1000001:1] "Loopback Ping Detected" [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1
07/24-10:46:54.410544 [**] [1:1000001:1] "Loopback Ping Detected" [**] [Priority: 0] {ICMP} 127.0.0.1 -> 127.0.0.1plaintextRunning Snort on PCAP Files#
Snort can also perform detections on PCAP files containing historical network traffic.
snort -q -l /var/log/snort -r log.pcap -A alert_fast -c /etc/snort/snort.luashell