1. Learning Snort Rules by Capturing Intrusions In Live Network Traffic
Dr. Jinsheng Xu
Triveni Gadipalli
North Carolina A&T State University

2. Introduction
Snort is a leading open source network intrusion detection system (NIDS)
It is ranked as one of the top network security tools by sectools.org
Snort components
Sniffer, Preprocessor, Detection Engine, Alert/Logging
Rules are the key!
Sourcefire Rules
Free Community Rules

3. Motivations Snort Rules are complex
Understanding a rule is not easy
Writing correct rules are even harder
Snort tutorials do not have hands-on experiments

4. Goals Develop a hands-on lab for learning snort rules
Rules are tested against the live traffic
Learn various features of Snort rules

5. Lab Components Snort Wireshark Traffic Generator
It is a program that broadcasts packets to the LAN continuously
The packets contains 11 intrusions
All components are packaged into a single Windows XP VM

6. Implementation Real captured traffic found on the Internet
Selected individually and combined into a single capture file
Requires from easy rules to more advanced rules
To broadcast to the network, destination MAC address is changed to broadcast address by the traffic generator
Traffic generator is implemented using WinPCap library

7. Instructions Sending traffic Running Snort Editing Rules
Goto cygwin home directory
./traffic.exe
Running Snort
Goto c:\snort\bin
./snort.exe –c ../etc/snoft.conf –l ../log/ -i 2 –A console
Editing Rules
Goto c:\snort\rules
Edit local.rules

8. Rule Structure Snort rules have two logical parts
Rule Header
Rule Options
Rule Options follow the Rule header and they are enclosed in closed braces
Example of a simple rule
Action Source Address Direction Destination port
alert IP any 21 -> any (msg:”IP packet is detected”; sid: ;)
Protocol Source Port Destination Address
Action
Protocol
Source Address
Source Protocol
Direction
Destination address
Destination Protocol

9. Action
Purpose of this field is to show what action will be taken when rule conditions are true
There are five predefined actions
Pass: Tells snort to ignore the packet (why do we need pass action)
Pass icmp any any -> any (msg:” pass example”; sid:123938;)
Log: Used to log a packet
Log tcp any any -> any (msg:” log example”; sid: ;)
Alert: An alert message is generated when the rule conditions are met
Activate: Used to create an alert and then to activate another rule for checking more conditions
Dynamic: These are invoked by other rules using activate action
Activate tcp any any ->any 143 (msg:”IMAP buffer overflow”;content:”\bin”;flags:PA;activates:1;)
Dynamic tcp any any -> anyh 143 (activated_by:1; count:50)
In addition to these actions you can define your own actions
This is an example to defining your own actions and this will create a rule type “alertdata “ that will log to MySQL database
ruletype alertdata {
type alert
output database: log, mysql, user=snort dbname=snort host=localhost }

10. Protocol
This part shows on which type of packet the rule will be applied.
These are the protocols used in snort, IP
ICMP
TCP
UDP
Log udp any any -> any any (msg:”udp packet detected”; sid: ;)
Alert tcp any 21-> any (msg: “Tcp packet”; sid: ;)

11. Address There are two address parts in a snort rule
The address may be single IP address or a network address. Keyword “any” is used for all addresses
You can also specify list of addresses in a Snort rule
These addresses can be separated by comma included in square brackets
These specifications are applied to both source and destination addresses
Negation symbol is used to exclude the address
Alert tcp ! any -> [ , ] any (msg: example
for range of address”; sid:129845;)
Alert ip /24 any -> /16 any (msg:”example for netmask”; sid:198749;)
/24 would signify the block of addresses from to
/16 would signify the block of addresses from to

12. Port Number
Port number is used to apply a rule on packets that originate from or go to a particular port or a range of ports
Keyword “any” is used to apply the rule on all packets irrespective of the port number
Range of ports is specified by using a colon to separate starting and ending port numbers
Log tcp any any -> :1024 (msg:”port range example”;
sid:124353;)
Log tcp any any-> : (msg:”another example”; sid: ;)
Question? Does port number apply to IP, ICMP?
Port number doesn’t apply to Ip or ICMP

13. Direction There are three symbols you can use.
-> : source is on left hand side of the symbol
<- : source in on right hand side of the symbol
<>: packets traveling on either direction

14. Exercise #1a Learning Objective
Basic Protocol Header Fields
A list of header options in snort (in note section)
How to send a send an alert when someone is pinging with ttl 255?
IP header has TTL field. Snort has “ttl” option
alert icmp any any -> any any (msg:"pinging with TTL=255";ttl: 255; sid: ;)
In the above rule there are three rule options
“msg” tells the snort to print the message that we give
“ttl” checks for the protocol field with ttl=255
“sid” is used to uniquely identify snort rules
The action in the rule header is invoked only when all criteria in the options are true
All options are defined by keywords and arguments
Arguments are separated from option keyword by a colon
Two different options are separated by a semicolon
There are many types of keywords
How can we write a rule to send an alert when source and destination are same?
Sameip is used
Alert ip any any -> any any ( msg:”destination and source are same” ; sameip; sid: ;)

15. Exercise #1b
How can we write a rule to send an alert when source and destination are same?
Use sameip keyword
Alert ip any any -> any any ( msg:”destination and source are same” ; sameip; sid: ;)

16. Exercise #2a Learning Objective
Checking the content in payload
How to use hexadecimal
“content” option in snort
How to send an alert when someone tries to use “show databases” command in MYSQL
alert tcp any any -> any 3306 (msg:"MYSQL show databases attempt“; flow:to_server,established; content:"|0F |show databases“; classtype:protocol-command-decode; sid:1776; rev:3;)
Above rule sends an alert when a tcp packet is sent to port 3306(mysql) and the options included are true
The flow keyword is used in conjunction with TCP stream and it allows rules to only apply to certain directions of the traffic flow and established will let the snort to check only established TCP connections
“content” will check for the content specified in the packet payload. It can search for text and binary or both
“classtype” is used to categorize a rule as detecting an attack that is part of a more general type of attack class
The rev keyword is used to uniquely identify revisions of Snort rules

17. Exercise #2b
How can we write a rule to detect an SNMP connction over UDP using the default “public” is made?
We have to generate an alert and the protocol used is “udp” , source address can be any computer outside your network, source port can be anything, destination address is your network and the destination port is 161 and we have to check for the content “public”
alert udp any any -> any 161 (msg:"SNMP public access udp"; flow:to_server; content:"public";classtype:attempted-recon; sid:1411; )

18. Exercise #3a Learning Objective
Checking the content in a particular position in the payload
“depth” and “distance” option in snort
Regular Expression
How to send an alert when someone invites for voip-sip connection?
alert udp any > any any (msg:"VOIP-SIP outbound INVITE message“; content:"INVITE"; depth:6; nocase; content:"SIP/2.0"; distance:0; nocase; pcre:"/^INVITE\s+(sips?|tel|https?)\x3A[\w-'"]+\x40[\w-'"\x2E]+\s+/smi“; classtype:protocol-command-decode; sid:12006;)
Above rule has some new keywords
In the above example “depth” will check for the content “INVITE” within the first 6 bytes of payload and “nocase” is used to ignore the case
“distance” will check for the content “SIP/2.0” within 0 bytes after the match of the “INVITE” regardless of the case
The pcre keyword allows rules to be written using Perl Compatible Regular Expressions
The depth keyword allows the rule writer to specify how far into a packet Snort should search for the specified pattern
The distance keyword allows the rule writer to specify how far into a packet Snort should ignore before starting to search for the specified pattern relative to the end of the previous pattern match
In the regular expression ‘^’ is used to check for the INVITE at the beginning of the line and then \s+ is for 1 or more white space character followed by either sip and followed by s o or more times or tel or http followed by s 0 or more times then \x means 3A is hexadecimal number followed by any alphanumeric character or – or ‘ or “ then again the same kind of pattern
/smi: ‘m’ indicates that the whole payload is one big line of character and ‘s’ is used to include newlines in the dot metacharacter and ‘I’ is for case insensitive search

19. Exercise #3b
How to generate an alert for an inbound VOIP-SIP INVITE message?
To generate an alert by checking “udp” packet coming from any destination going to home network and port “5060”
It is checking for the content “INVITE” regardless of the case within the first 6 bytes of the payload and after this match within 0 bytes of the match it is checking for “SIP/2.0” regardless of the case and then it is checking for pcre
alert udp any any -> any 5060 (msg:"VOIP-SIP inbound INVITE message"; content:"INVITE"; depth:6; nocase; content:"SIP/2.0"; distance:0; nocase; pcre:"/^INVITE\s+(sips?|tel|https?)\x3A[\w-'"]+\x40[\w-'"\x2E]+\s+/smi"; classtype:protocol-command-decode; sid:11968;)

20. Exercise #4a Learning Objective
Checking the content in a particular position in the payload
“offset” option in snort is used
How to send an alert when an attempt is made for DNS Zone transfer ?
alert tcp any any -> any 53 (msg:"DNS zone transfer TCP"; flow:to_server,established; content:"|00 00 FC|"; offset:15; classtype:attempted-recon; sid:255; )
In the above rule, a new keyword “offset” is used
The offset keyword allows the rule writer to specify where to start searching for a pattern within a packet
In the above rule it will start searching for the content after the first 15 bytes in the payload
This event is generated when an attempt is made to request a zone transfer from a DNS server
DNS zone transfers are normally used between DNS servers to replicate zone information
This can also be used to gain information about a network
A malicious user may request a zone transfer to gather information before commencing an attack

21. Exercise #4b
How to generate an alert when activity relating to network chat clients is detected?
This is a policy violation and it can allow malicious users to circumvent the protection offered by a network firewall
We have to generate an alert for a tcp packet coming from “any” source to your
home network through port “1863” and checking for content “MSG” in the first “4” bytes of the payload and after this match checking for content “Content-Type|3A|” regardless of the case and after this match checking for content “text/plain” within “1” byte of the previous match.
This event is generated when an attempt is made to request a zone transfer from a DNS seerver
DNS zone transfers are normally used between DNS servers to replicate sone information
This can also be used to gain information about a network
A malicious user may request a zone transfer to gather information before commencing an attack
alert tcp any any <> any 1863 (msg:"CHAT MSN message"; flow:established; content:"MSG "; depth:4; content:"Content-Type|3A|"; nocase; content:"text/plain"; distance:1; classtype:policy-violation; sid:540; )

22. Exercise #5a Learning Objective
Checking the size of the payload
Check the state of the protocol
How to generate an alert when someone want to start skype?
alert tcp any any -> any any (msg:"P2P Skype client login startup"; flow:to_server,established; dsize:5; content:"| |"; depth:4; flowbits:set,skype.login; classtype:policy-violation; sid:5998; )
This rule is used in conjunction with other rules to either reduce the possibility of false positives from occurring or to track the state of a connection
In the above rule there are two new keywords used
“dsize” of “5”bytes is checking for the packet payload size
“flowbits” set indicates that it will set the specified state for the current flow and skype.login is the user defined name
The dsize keyword is used to test the packet payload size.
This may be used to check for abnormally sized packets.
In many cases, it is useful for detecting buffer overflows.
The flowbits keyword is used in conjunction with conversation tracking from the Flow preprocessor.
It allows rules to track states across transport protocol sessions.
The flowbits option is most useful for TCP sessions, as it allows rules to generically track the state of an application protocol.
There are seven keywords associated with flowbits.
Set- Sets the specified state for the current flow.
Unset- Unsets the specified state for the current flow.
Toggle- Sets the specified state if the state is unset, otherwise unsets the state if the state is set.
Isset- Checks if the specified state is set.
Isnotset- Checks if the specified state is not set.
Noalert - Cause the rule to not generate an alert, regardless of the rest of the detection options.
Most of the options need a user-defined name for the specific state that is being checked.
This string should be limited to any alphanumeric string including periods, dashes, and underscores

23. Exercise #5b
How to generate an alert when network traffic that indicates Skype is being used?
This event indicates that Skype is being used on the protected network and this is a possible policy violation
We have to generate an alert for tcp packets coming from any source to any destination with flow to-client with established tcp connection
Payload should be of the size 5 bytes and flowbits should check if skype.login is set
It should check for the content :"| |“ with in the first 4 bytes
alert tcp any any -> any any (msg:"P2P Skype client login"; flow:to_client,established; flowbits:isset,skype.login; dsize:5; content:"| |"; depth:4; classtype:policy-violation; sid:5999; )

24. Exercise #6a Learning Objective
Keep track of the number of packets coming in a time frame
Use “threshold” option in snort
Checking the flags in the packet
How to generate an alert when “syn flood” happens?
alert tcp any any -> any any (msg:"Syn Flooding"; flags:S; flow:to_server; threshold: type threshold, track by_src, count 10, seconds 1; priority:3; sid: ;)
The above rule is checking for tcp packets coming from any source to any destination with synchronization flags are set and the flow of traffic is towards the server
Keyword “threshold” checks to see if more than 10 synchronized packets are coming from the same source in 1 second
Priority indicates the priority level of the attack
Event thresholding can be used to reduce the number of logged alerts for noisy rules. This can be tuned to significantly reduce false alarms, and it can also be used to write a newer breed of rules. Thresholding commands limit the number of times a particular event is logged during a specified time interval.
Limit: Alerts on the 1st m events during the time interval, then ignores events for the rest of the time interval.
Threshold: Alerts every m times we see this event during the time interval.
Both: Alerts once per time interval after seeing m occurrences of the event, then ignores any additional events during the time interval.
We can track it by using source or by using destination(track by_src, track by_dst)