In this article, we will learn the makeup of Snort rules and how we can we configure them on Windows to get alerts for any attacks performed. There are various intrusion detection system (IDS) and intrusion prevention system (IPS) methods available to use, but one of the best and most common method is Snort.
What is Snort?
Snort is a free and open-source network intrusion prevention and detection system. It uses a rule-based language combining signature, protocol, and anomaly inspection methods to detect malicious activity such as denial-of-service (DoS) attacks, Buffer overflows, stealth port scans, CGI attacks, SMB probes, and OS fingerprinting attempts. It is capable of performing real-time traffic analysis and packet logging on IP networks.
Uses of Snort rules
- Snort uses the popular libpcap library (for UNIX/Linux) or winpcap (for Windows), the same library that tcpdump uses to perform packet sniffing.
- Snort’s Packet Logger feature is used for debugging network traffic.
- Snort generates alerts according to the rules defined in configuration file.
- The Snort rule language is very flexible, and creation of new rules is relatively simple.
- Snort rules help in differentiating between normal internet activities and malicious activities.
A simple syntax for a Snort rule:
An example for Snort rule:
log tcp !192.168.0/24 any -> 192.168.0.33 (msg: "mounted access" ; )
The direction operators
-> indicate the direction of interest for the traffic. This means traffic can either flow in one direction or in bi-directionally. The keyword
any can be used to define any IP addresses, and numeric IP addresses must be used with a Classless Inter-Domain Routing (CDIR) netmask. In Snort rules, the port numbers can be listed in many ways, including
any ports, negation, etc. Port ranges are indicated with Range operator
Example of multi-line Snort rule:
log tcp !192.168.0/24 any -> 192.168.0.33 \ (msg: "mounted access" ; )
Usually, Snort rules were written in a single line, but with the new version, Snort rules can be written in multi-line. This can be done by adding a backslash
\ to the end of the line. This multiple-line approach helps if a rule is very large and difficult to understand.
Example of a Port negation
log tcp any any -> 192.168.1.0/24 !6000:6010
For better understanding, refer to this table:
|Protocols||Ip Address||Action performed|
|*log tcp any :1024 ->||192.168.1.0/24 400:||It will log traffic from various ports and will go to ports which are greater than or equal to 400|
|log udp any any ->||126.96.36.199/24 1:1024||It will log traffic from any port and destination ports ranging from 1 to 1024|
Snort rules must be contained on a single line. Unless the multi-line character
\ is used, the snort rule parser does not handle rules on multiple lines. Usually, it is contained in
snort.conf configuration file.
This comes with two logical parts:
- Rule header: Identifies rule actions such as alerts, log, pass, activate, dynamic and the CDIR block.
- Rule options: Identifies the rule’s alert messages.
Snort rules must be written in such a way that they describe all the following events properly:
- The conditions in which a user thinks that a network packet(s) is not same as usual or if the identity of the packet is not authentic.
- Any violation of the security policy of the company that might be a threat to the security of the company’s network and other valuable information.
- All well-known and common attempts to exploit the vulnerabilities in the company’s network.
The rules defined to the system should be compatible enough to act immediately and take necessary remedial measures, according to the nature of the intrusion. Snort does not evaluate the rules in the order that they appear in the snort rules file. By default, the order is:
- Alert rules: It generates an alert using alert method.
- Log rules: After generating alert, it then logs the packet.
- Pass rules: It ignores the packet and drops it.
As we know, IP is a unique address for every computer and is used for transferring data or packets over the internet from one network to the other network. Each packet contains a message, data, source, destination address, and much more. Snort supports three IP protocols for suspicious behavior:
- Transmission Control Protocol (TCP) Connects two different hosts and exchanges data between them. Examples include HTTP, SMTP, and FTP.
- User Datagram Protocol (UDP): Broadcasts messages over the internet. Examples include DNS traffic.
- Internet Control Message Protocol (ICMP): Sends network error messages in Windows. Examples include Ping and Traceroute.
Installing and configuring Snort rules on Windows
As we have discussed earlier, Snort rules can be defined on any operating system. Here, we will configure Snort rules on Windows.
The first step is to download Snort itself. After you have downloaded Snort, download Snort rules. Because these rules are community rules, you can download without having to sign up. If you go for subscription rules (which will cost you around $30 a year for an individual), you can expect the greatest Snort rules and updates for new sets of rules. There is not much difference between the community rules and the subscribers' rules—they have the same structure, but you will get updates for new Snort rules very quicly if you are a subscriber.
When installing Snort in root directory, a popup will appear for installing Winpcap. Install it if its not already installed in your Windows.
To check whether Snort has successfully installed, Open Command Prompt and go to Snort Directory.
Check if there is a bin directory created under directory folder. Now, go to Bin directory and check Snort version.
Extract all the Snort rules folders that you downloaded before, and from there, copy all the content from the folder to
Similarly, copy all the content from the
preproc_rules folder to
If it asks to overwrite the files, say yes to all. It will replace all the old versions with new preproc rules.
After you have copied all the contents, the main task starts here. Go to
c:/Snort/etc and open
Snort.conf with wordpad. CONF stands for configure.
Snort.conf has nine different sections. First, we will set the variables. The first variable we have is
HOME_NET. You can leave this to any, but it is preferred to put your machine IP address. In my case, the IP is
EXTERNAL_NET any line as it is.
If you have a DNS SERVER, make changes in the
DNS_SERVERS line by replacing
$HOME_NET with your DNS server IP address. Otherwise, leave it blank.
Now, scroll down to
RULE_PATH, and replace
c:\Snort\rules and replace
c:\Snort\so_rules. At last, replace
Also, change the
Now, navigate to
c:\Snort\rules and create two text files named whitelist andblacklist and change their file extension from .txt to .rules,. If a pop up appears, click yes.
That’s all for step one, and there is nothing much to do in step two but set
#config logdir: to
config logdir:c:\Snort\log. This will help Snort write the output in a particular location.
Now, straightaway go to step four. In this, we have to configure dynamic loaded libraries. At path to dynamic preprocessor libraries, replace
usr/local/lib/snort_dynamicpreprocessor with your dynamic preprocessor, which is
usr/local/lib/snort_dynamicengine/libsf_engine.so with your base preprocessor engine, which is
Comment (#) the dynamic rule libraries line, as we have already configured the libraries.
Now, we are on step five. Add a comment(#) before all the listed preprocessors under inline packet normalization. They do nothing but generate errors at the runtime.
In step six, configuring output plugins, provide the location of the classification.config and replace it with
C:\Snort\etc\classification.config. Similarly, provide the location of the reference.config and replace it with
In the next line, add
output alert_fast: alert.ids for snort to dump all logs in
In Snort.conf file, find and replace
var. By default, the string ipvar is not recognized by snort, so we replace it with var. To find and replace, press
Ctrl + H. In the "find what" field, write "ipvar," and in the replace field, write "var." Then, click Replace all.
The last step is to remove the backslash and add comment characters
# on lines 501–507. These lines can be found above step six.
Save the snort.conf file and close the window.
Now it's time to set the Snort rule. Go to
icmp-info.rules in wordpad.
At the end, add a rule (required), such as:
alert tcp any any -> any any(msg: "Testing Alert" ; sid:1000001)
In my case, I don’t have any criteria, so it will load on any ICMP packet it receives. In the above rule, we have also provide a signature id (sid), which is highly required. By convention, when you write your own Snort rules, you have to start above 999999.
To verify the snort is actually generating alerts, open the Command prompt and go to
c:\Snort\bin and write a command.
snort -iX -A console -c C:\snort\etc\snort.conf -l C:\Snort\log -K ascii
Here, X is your device index number. In my case, it's 1. Hit Enter, and you are all set.
If Snort occupies high CPU usage without high amounts of traffic to analyze, it may be indicative of too high a volume of traffic, insufficient system resources, or some other process that is consuming most of the CPU. Sometimes, too many rules are added, which means the packet queue drops the packet because it fills before Snort has a chance to look at them. Best practice is to only enable rules you need so Snort can spend more time grabbing packets from the queue.
Never enable all rules, or you will most likely experience performance issues. For example, if you are in a Windows-only environment, only enable Windows-related rules. In addition, use Berkeley Packet Filters (BPF) to limit traffic to machines or ports that need to be inspected. For example, if you have a network backup server, it’s best to tell Snort to ignore traffic from it, since it will generate a large amount of traffic. BPFs are added as the last command-line options to Snort:
snort -iX -A console -c C:\snort\etc\snort.conf -l C:\Snort\log -K ascii 'not host 192.168.1.100' --== Initializing Snort ==-- Initializing Output Plugins! Snort BPF option: not host 192.168.1.100
Another performance consideration is to only log alerts in the unified2 binary format rather than ascii. This will speed up the process of writing out logs.