Welcome back, my novice hackers!
My recent tutorials have been focused upon ways to NOT get caught. Some people call this anti-forensics—the ability to not leave evidence that can be tracked to you or your hack by the system administrator or law enforcement.
One the most common ways that system admins are alerted to an intrusion on their network is with a Network Intrusion Detection System (NIDS). The most widely used of these is Snort.
I already did an Introduction to Snort, and now I want to delve deeper to show you how the rules in Snort are designed to detect your intrusion. The more we know about Snort and other NIDS, the better we can evade them.
Step 1: Finding the Snort Rules
Snort is basically a packet sniffer that applies rules that attempt to identify malicious network traffic. These rules are analogous to anti-virus software signatures. The difference with Snort is that it’s open source, so we can see these “signatures.”
We can see the Snort rules by navigating to /etc/snort/rules on our Kali install. Let’s go to that directory and take a look.
kali > cd /etc/snort/rules
Now, let’s do a listing of that directory to see all of our rule files.
kali > ls -l
As we can see in the screenshot above, there are numerous Snort rules files. Each of these files contains a category of rules, some with hundreds of rules.
Step 2: Viewing Snort Rules
The Snort rules files are simple text files, so we can open and edit them with any text editor. I’ll be using leafpad , but you can use vi, gedit, or any text editor you prefer.
Let’s open the file sql.rules. This set of rules is designed to detect SQL attacks on the wire. This is a rather old set of rules and most system admins no longer use it.
kali > leafpad /etc/snort/rules/sql.rules
We can see that these rules are designed to detect a variety of SQL attacks.
Step 3: Examining a Rule
Let’s take a simple rule and dissect it. Let’s open the file scan.rules.
kali > leafpad /etc/snort/scan.rules
I have highlighted a simple rule we will use to understand how snort rules are written and read.
Step 4: Dissecting the SF Scan Rule
Let’s start by examining the first part of that rule from the beginning to the first starting parenthesis. This initial part of the rule is referred to as the header, and ours looks like this:
alert tcp $EXTERNAL_NET any -> $HOME_NET any
This rule is designed to detect scans by scanning tools such as nmap and hping3. One of those scans is called a SYN-FIN scan. This scan sends TCP packets with both the SYN and the FIN flags set to attempt to determine what ports are open on the target system. A packet with both of these flags set should never appear–except for malicious purposes–as these two flags simultaneously open and close a TCP connection.
Therefore, it’s easy to see that any packet with these flags set must be an attempt to do recon on the system and the sysadmin should be alerted.
Step 5: Rule Header
Let’s start by examining the header of this rule.
Step 6: Snort Rule Options
Now let’s take a look at the part of the rule that falls between the parentheses. This is referred to as the rule options. This part of the Snort rule is comprised of a couplet with a keyword, a colon, and the argument.
keyword:arguments
Our example rule options look like this:
(msg:”SCAN SYN FIN”; flow:stateless; flags:SF,12; reference:arachnids, 198; classtype:attempted-recon; sid:624; rev:7;)
Breaking Down the Rule Options
msg – This is the message that’s sent to the sysadmin if the rule is triggered. In this case, Snort reports to the sysadmin “SCAN SYN FIN”.
flow – This option allows the rule to check the flow of the traffic. It can have a number of values including established (TCP established), not established (no TCP connection established), stateless (either established or not established), etc. In our example, the rule is triggered on traffic with or without an established TCP connection.
flags – This couplet checks for TCP flags. As you know, TCP flags can be SYN, FIN, PSH, URG, RST, or ACK. This rule is looking for traffic that has both the SYN and FIN flags set (SF) and in addition, has the two reserved bits in the flags byte set (12).
reference – This section is for referencing a security database for more information on the attack. In our example, we can find more info on this attack in the arachnids database, attack 198.
classtype – All the rules are classified into numerous categories to help the admin understand what type of attack has been attempted. In our example, we can see that it is classified as an “attempted-recon”.
sid – this is the Snort ID. Every rule has a unique ID. In this case, the rule ID is 624
rev – as rules are revised there are assigned revision numbrs just like software. This one is the 7th revision of this rule.
Step 7: Evade & Disable
Now that we understand how the Snort rules work, we can design our attack to evade these rules. If we can get to the NIDS server, we can disable or edit the rules that might alert the sysadmin to our attack.
In my next Snort tutorial, we’ll delve deeper into the complexities of some of more sophisticated Snort rules, so stay tuned. If you have any questions or comments on Snort, please post them below.
