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

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.


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.

Just updated your iPhone? You'll find new features for Podcasts, News, Books, and TV, as well as important security improvements and fresh wallpapers. Find out what's new and changed on your iPhone with the iOS 17.5 update.

Pig reading image via Shutterstock


please am new to snort, please can i get a sample for a snort rule to detect anyone trying to access a folder in my c:// drive. will really appreciate a response to this because i am stucked


Welcome to Null Byte! Glad you found us.

Snort comes with hundreds of rules. Download the ruleset from snort.org and it will protect you from someone trying to access your c: drive. No need to reinvent the wheel!


Hi, I'm using Snort as part of my final university year project. I'm trying to find exploits Snort doesn't detect and then writing rules for them. I'm finding it difficult to find such exploits. I am wondering if you have any tips?

Thanks Matt


Welcome to Null Byte!

There are new threats coming out daily and the Snort community is always looking for help on rules to detect these threats. I would suggest subscribing to the Snort community listserve and as new threats come out daily, pick one and attack it.


hi OTW, is there a follow up tutorial after this one that i might have missed or it is not yet out?


I do have this tutorial which I'm assuming you have already read.

Its time that I follow up on this article and write a part 2, though.


I got 5 kudos to give away when I just signed up to say 'thank you' to you. I am expecting all 5 kudos to go to you today immediately :D Thank you for writing stuff so clear even a 5 year old can understand it :-)

Thanks for the insights, this is why ict is such a blast

Hi, im using snort on kali linux and im trying to update the snort rules what is the best way to do this?

The easiest way is to install Pulled Pork. It will automatically update your rules. Otherwise, simply go to snort.org and download them manually.

I have tried using pulled pork but seem to be having difficulty, is there any documentation which is useful when trying to set it up on kali?

There is documentation at snort.org

Dont run exploit base rule..signatures base but vulnerability rule base

other big issues is evasion..ids/ips without normalization is bad/false positive..insertion attack..tcp segmentation attack..fragment attack..obsecure protocol..etc2..easy can be done....

thanks a lot man, that was really helpful and elaborate.

Share Your Thoughts

  • Hot
  • Latest