Snort IDS: Rules, Signatures & Analytics

SNORT IDS

Cyber actors have demonstrated their continued willingness to conduct malicious cyber activity against critical infrastructure by exploiting Internet-accessible and vulnerable Operational Technology (OT) assets[1]. On October 12th, 2023, the National Security Agency released a repository for OT Intrusion Detection System (IDS) signatures and analytics to GitHub. The capability, known as ELITEWOLF, can enable asset owners, operators, and defenders of critical infrastructure to identify potentially malicious and/or nefarious activity in their OT environment(s).

WHAT IS SNORT WHEN IT COMES TO CYBERSECURITY

These released signatures and analytics are based on Snort. At its core, Snort is an open-source network intrusion detection system. This means that Snort is designed to monitor network traffic in real-time, performing protocol analysis, content searching and matching, and detect a variety of attacks and probes and alert you to any suspicious or nefarious activity. In analogical terms, think of it as a security camera for your network, constantly on the lookout for any potential threats it is configured to monitor for.

HOW IS SNORT VALUABLE?

There are many things about Snort that make it valuable for defenders, but to summarize at a high-level:

• Real-time Monitoring: Snort analyzes network traffic in real-time, giving immediate insights into potential threats.
• Flexibility: With a vast library of rules available by default and the ability to write custom rules, Snort can be tailored to fit the specific needs of almost any network environment.
• Open Source: Being open source means that it’s not only free to use, but it also benefits from the contributions of a global community of developers and security experts.

While Snort is open source, many paid products on the market even have Snort as a detection component under the hood for detecting anomalies and threats.

SNORT COMMANDS & SNORT RULES

As mentioned, a Snort rule defines what to look for in network traffic and what action to take when a match is found. The structure of a Snort rule is easier than it sounds or may look. Think of it like a firewall rule when reading it from left to right.

The rule header contains the rules action, protocol, source and destination IP address(es) and netmasks, and the source and destination ports information.

Action – The first item in a Snort rule is the action of the rule. This tells Snort what to do when it finds a packet that matches the criteria of the defined rule. There are (5) available default actions in Snort, with an option to create custom ones in the form of plugins:

• Alert – generate an alert using the selected alert method, and then log the packet.
• Log – log the packet.
• Pass – ignore the packet.
• Activate – alert and then turn on another dynamic rule.
• Dynamic – remain idle until activated by an activate rule, then act as a log rule.

Protocol – The next item in the rule is the specification of the protocol. There are (4) protocols that Snort can currently analyze for suspicious behavior; TCP, UDP, ICMP, and IP.

SourceIP – Following the protocol specification is the specifying of an IP address or variable defining where the traffic is coming from.

SourcePort – Once the IP address(es) have been specified, then the port numbers will be referenced. This can also a variable in addition to literal.

Direction Operator – The direction operator is what indicates the orientation or direction of the traffic that this rule will apply to. There is a bi-directional operator, and it can be indicated by using <> respectively.

DestinationIP – Similar to SourceIP, DestinationIP also supports variables containing multiple addresses defining where the traffic is going to.

DestinationPort – Similar to the SourcePort, the destination port can also be a variable in addition to literal.

Once the traffic criteria for the Snort rule have been set, it’s time to specify the rules options. Rule options are commonly referred to as the heart of Snort’s intrusion detection engine. There are quite a few different options when it comes to the types of options supported by Snort. This blog will not uncover all the options available, but the general rules options include, but are not limited to the following:

• Message – specifying a message can be extremely helpful and is typically included of what the rule is detecting. This tells Snort what to output when the rule matches and is a simple text string.
• Flow – flow is used in conjunction with TCP stream reassembly, and it allows rules to only apply to certain directions of the traffic flow.
• Reference – reference allows the rules to include references to external sources of information. This can be helpful in knowledge sharing activities and determining the validity or context of a rule before it is implemented.
• Classtype – classtype is how Snort shares what the effect of a successful attack would be.
• Sid/rev – each Snort rule needs a unique identifier so that there are no conflicts. In the event plugins are used, revision can also be helpful when troubleshooting for revision information to review previous states of rules for troubleshooting or debugging purposes.

In addition to rule options, there are also detection options as well. These options include, but are certainly not limited to:

Content – content essentially allows users to set rules that search for specific content in the packet payload and trigger response based on that data. This data can contain both mixed text and binary data.

• Distance/Offset – this specification allows the rule writer(s) to specify where to start searching relative to the beginning of the payload or the beginning of a content match.
• Within/Depth – this specification allows the rule writer(s) to specify how far forward to search relative to the end of a previous content match and, once that content match is found, how far to search for it.

Byte_test – the byte_test specification allows a rule to test a specific number of bytes against a specific value in binary.

Putting these things into context, a very simple example rule can be found below:

This rule will generate an alert for any TCP traffic headed to any IP address in the 192.168.1.1/24 range on port 80, which is typically the port used and seen in HTTP traffic. If detected, the message will display “Potential HTTP Traffic” to the reader(s).

CONSIDERATIONS TO MAKE BEFORE DEPLOYING SNORT

In the world of OT environments, it’s not uncommon to have a resource-constrained environment with multiple networks to monitor as it poses several challenges. However, with careful planning, it can be done efficiently. Some considerations to make are:

Optimized Hardware Placement

• Centralized Monitoring: If possible, try to identify a central point where traffic from multiple networks converges. By placing Snort at this point, you can monitor multiple networks without deploying separate Snort instances.
• Distributed Monitoring: If a centralized monitoring point is not possible, consider deploying Snort sensors at critical points in each network.

Use a Lightweight Operating System

Choose a lightweight Linux-based distribution to ensure minimal overhead. For instance, if you’re looking to use Linux, a lightweight distribution such as Apline or a minimal install of Debian or CentOS would be beneficial.

Hardware Considerations

While Snort can function on a single-core CPU, it is recommended to use at least a dual-core for better performance. The amount of RAM required depends on the rulesets you’ll be using. For smaller rulesets, 512MB might suffice. For larger rulesets, 1GB or more may be necessary. Lastly, use a fast storage medium. Solid-state drives (SSDs) will provide better performance than traditional hard drives.

Selective Ruleset

As Snort comes with an available install of pre-defined rules, and there are many different rulesets out there in the community, only activate rules that are necessary for your use-case. Additionally, periodically review and update the rulesets to eliminate obsolete or unnecessary rules. If using community-provided rules, consider developing custom rules tailored to your specific environment and needs to reduce the overhead.

Interface Bonding/Teaming

If you have multiple networks but limited hardware, consider using Network Interface Card (NIC) bonding or teaming. This allows multiple NICs to be used as a single interface, potentially increasing the bandwidth and providing failover capabilities.

Traffic Sampling & Filtering

If the volume of traffic is too high, consider sampling traffic. Note that this might lead to missing some packets, but it will reduce the load on Snort. One of the ways to accomplish this is to use Berkely Packet Filters (BPF) to filter out traffic that you are certain doesn’t need to be inspected. This can reduce the amount of traffic Snort has to process.

Load Balancing

If traffic volume is still high, consider deploying multiple Snort instances and using a load balancer to distribute traffic among them. This allows you to scale horizontally, although it does require additional hardware.

By carefully positioning your Snort instances, optimizing configurations, and regularly maintaining the implementation, you can effectively monitor multiple networks even in resource-constrained environments. Remember, the key is to minimize the components and rules in use, monitor performance, and adjust as necessary.

INSTALLING SNORT

“Installation steps may vary based on the operating system you are using”

For Debian/Ubuntu

For CentOS/RHEL

After installation, Snort’s configuration files are usually located in /etc/snort

Snort rules are stored in files with a .rules extension, typically located in /etc/snort/rules. The main file that includes all other rule files is snort.conf.

To edit or add rules, navigate to the rules directory:

You can view the list of existing rules files using ls. To edit a specific rules file (for instance, local.rules), use a text editor of your choice.

In this file, paste the rules you want to add to the rules file following the syntax shared earlier.

After editing and saving your rules, it’s a good practice to validate the configuration and rules to ensure there are no errors:

If there are no errors, Snort will indicate that it’s ready to process packets.

MANAGING SNORT RULES

Snort has many rules as you may have noticed, and you might not need all of them. Within the snort.conf file, you can comment out or uncomment specific rules to either activate or deactivate them. Remember to restart Snort sudo service snort restart after making changes to the rules or configurations to ensure that the changes take effect.

VIEWING SNORT ACTIVITY & FORWARDING TO A SIEM

Security Information and Event Management (SIEM) solutions are powerful tools that aggregate, analyze, and present security data from a myriad of sources. Combining the intrusion detection capabilities of Snort with the analytical prowess of a SIEM offers a more holistic view of your network’s security. Here’s how you can achieve this integration.

Pre-Requisites:

• Snort installed and configured to your liking.
• A SIEM solution (for these steps, we will use a generic SIEM, but the steps can be adapted for specific SIEM tools like Splunk, ELK Stack, etc.)

Viewing Snort Activity

Before forwarding data to a SIEM, you must ensure Snort is correctly monitoring and logging activity. By default, Snort logs to /var/log/snort. You can view these logs using the cat or tail commands.

The command above will display Snort alerts in real-time.

Forwarding Snort Logs to SIEM

Configure Snort for Syslog Logging:

Edit the Snort Configuration

Search for the output configurations and add:

This directs Snort to send alert data to the system’s syslog daemon, which can be forwarded to your SIEM.

After making changes, ensure you restart Snort.

Configure Syslog to Forward Logs to SIEM:

Depending on your system, you might be using rsyslog or syslog-ng. For this example, we’ll be using rsyslog.

To forward Snort logs to your SIEM, add the following line:

Replace the SIEM_IP_ADDRESS with your SIEM”s IP address and SIEM_PORT with the listening port of your SIEM for syslog.

Restart Syslog Service

Configuring Your SIEM:

In your SIEM solution, yo need to add a new log source. This process varies depending on flavor of SIEM, but look for options related to Add Data, Data inputs, or Log Sources. Choose syslog as the source type since we’re sending Snort logs via syslog. Based on your SIEM’s capabilities, you can filter, categorize, and index the Snort logs for efficient searching and analysis.

SNORT & NETWORK SECURITY

Integration of Snort with a SIEM offers a streamlined approach to network security monitoring. This combined solution ensures that not only are intrusions detected, but the data is also analyzed, correlated, and visualized effectively.

Remember, the initial setup may seem intricate, but the long-term benefits in terms of enhanced security visibility are invaluable. The digital landscape is always evolving, and threats are becoming increasingly sophisticated. Tools like Snort empower us to safeguard our networks and stay one step ahead.

Happy Monitoring!

Part 2 of the series will cover analyzing network traffic real-time with Wireshark and manually creating relevant Snort rules for inclusion into your configured rule file(s).

[1] NSA releases a repository of signatures and analytics to secure Operational Technology > National Security Agency/Central Security Service > Press Release View