Hack Like a Pro: How to Read & Write Snort Rules to Evade an NIDS (Network Intrusion Detection System)

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 BackTrack install. Let's go that directory and take a look.

• cd /etc/snort/rules

Now, let's do a listing of that directory to see all of our rule files.

• 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 KWrite. Let's open the file porn.rules. This set of rules is designed to detect pornography on the wire. This is a rather old set of rules and most system admins no longer use it.

• kwrite /etc/snort/porn.rules

We can see that these rules are designed to detect a variety of pornography. If you ever wondered how your sysadmin knew you downloaded porn, now you know!

Step 3: Examining a Rule

Let's take a simple rule and dissect it. Let's open the file scan.rules.

• kwrite /etc/snort/scan.rules

Let's copy that highlighted rule to a separate text file and dissect it now.

Step 4: Dissecting the SF Scan Rule

This rule is designed to detect scans by scanning tools such as nmap and hping. 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.

This type a packet should never be seen in the wild as a packet with both the SYN and the FIN flags set would be asking the system to open a connection (SYN) and close a connection (FIN) simultaneously.

It's rather 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 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:

Breaking Down the Rule Header

• alert - This the action. It can be alert, log, or pass (drop).
• tcp - This the protocol of the traffic the rule is looking for. It can be tcp, udp, and icmp.
• $EXTERNAL_NET - This the source IP or network of the malicious packets. It can be set as a variable in the snort.conf.
• any - This the source port of the malicious traffic. This can set as a single port, multiple ports, or a range of ports.
• -> - This is the direction of the traffic. In this case, we are looking for traffic moving from the EXTERNAL_NET to the internal or HOME_NET.
• $HOME_NET - This the destination IP address that the traffic is moving to. As with the EXTERNAL_NET, it can be set as a variable in the snort.conf.
• any - This the destination port. It can also contain specific ports, like 80, or a variable containing a list of ports.

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:

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".

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. If you have questions on a different topic, visit the Null Byte forum for help.