I see all these examples. Now, how do I create my own rules?

This is a rough example of the Snort rule language and its capabilities. We’ll take some generic rules from the official Snort rules so that you can look them up later when you want to try them on your network. These examples will demonstrate a simple protocol identifier, port usage, and finally, packet details for application data.

alert ip any any -> any any (msg:"Bad-traffic IP Proto 55 IP 
Mobility"; ip_proto:55; reference:bugtraq,8211; reference:cve,
2003-0567; classtype:non-standard-protocol; sid:2187; rev:3;)

Alert tcp $HOME_NET any -> any 6667 (msg:"IRC port in use"; 
flow:from_client,stateless; sid:10550; rev:1;)

var IRC_PORTS 6667:7001

Alert tcp $HOME_NET any -> any $IRC_PORTS (msg:"IRC ports in use"; 
flow:from_client,stateless; sid:10550; rev:2;)

Alert tcp $HOME_NET !21:23 -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES 
Microsoft cmd.exe banner"; flow:from_server,established; content:
"Microsoft Windows"; content:"|28|C|29| Copyright 1985-"; distance:0; 
content:"Microsoft Corp."; distance:0; reference:nessus,11633; 
classtype:successful-admin; sid:2123; rev:2;)

Having seen the previous examples, you should realize that the rules language is rich with options to use for detecting traffic on your network. One caveat is that any encrypted traffic—such as HTTPS traffic—can’t be unencrypted with Snort. You can work around this if you encrypt the connections to the border of your network but keep the link to the web servers inside the network unencrypted. This could be accomplished through use of a secure proxy or SSL accelerator card. This might also make it easier to determine the cause of issues with any of your web-based applications. You might be thinking that rules can get quite complicated. One of the nice things about a tool as popular as Snort is that there is a large community of people willing to help answer questions and problems. Local Snort user groups and the Snort-sigs mailing list are just a few of the possible sources of help.

The Snort rules have a basic format that expands for more specific needs.

<snort action> <protocol> <src IP> <src PORT> <direction> <dst IP> 
<dst port> (msg:"Tell the user what I'm tracking"; <optional 
classtype> ;<optional snort ID (sid)>; <optional revision (rev) 
number>;)

This can be broken down and identified as shown in Table 3-1.

Table 3-1 lists only a core set of keywords. There are more language keywords that allow for a much more granular level of analysis and detection into network traffic.

Snort user groups

Snort-sigs

Snort users’ mailing lists

Snort documentation for the most current rule language changes

In the current Snort build, there are about 3,500 rules. How do I make sure I have the most current rules to protect my network?

The defacto Snort rule updater is Oinkmaster (http://oinkmaster.sourceforge.net). It allows for scripted and automatic rule updates. This runs as a command-line tool for ease of scripting, but it does have an add-on component for GUI management. The recommended way to use Oinkmaster is to determine when rules have changed, without having it automatically update your rules. If you allow Oinkmaster to update your rules automatically, you open up a big can of trouble for change management and rule management within a security team. However, it’s useful if you just want to have a daily comparison between your currently running rules and the rules on www.snort.org.

Download Oinkmaster:

mkdir /opt/oinkmaster 
mkdir /opt/oinkmaster/CURRENT_RULES
mkdir /opt/oinkmaster/NEW

Copy your currently running rules to CURRENT_RULES and compare them with the www.snort.org official rules:

perl oinkmaster.pl -o /opt/oinkmaster/CURRENT_RULES -c -C 
oinkmaster.conf

As you might have noticed, you don’t see the results as they scroll by, so from a Bourne shell, try the following:

# sh>perl oinkmaster.pl -o /opt/oinkmaster/CURRENT_RULES  
 -c -C oinkmaster.conf > OINK_Report.txt 2>&1

For those readers who might convert this to a daily report to show any changes in the official rules, the following script should work:

!#/bin/sh
##### 
# Checks daily for changes to the currently running Snort rule set 
# 
# Runs from cron every 24 hours 
# EXAMPLE CRONTAB LOG 
# * 23 * * * /bin/sh /opt/DAILY_SNORT_RULES.sh 
# 
##### 
   
# Variables 
   
# Date of the report 
mydate='date "+%c"' 
   
# Run oinkmaster Capturing all of the output 
perl /opt/oinkmaster -o /opt/oinkmaster/CURRENT_RULES -c 
-C /opt/oinkmaster/oinkmaster.conf > /opt/oinmaster/OINK_Report.txt 
2>&1
   
# Create a function report 
   
echo " Snort Rule Change Report " > /opt/oinkmaster/Daily_report.txt
echo " " >> /opt/oinkmaster/Daily_report.txt
echo "   For Date: $mydate " >> /opt/oinkmaster/Daily_report.txt 
echo " " >> /opt/oinkmaster/Daily_report.txt 
cat /opt/oinkmaster/OINK_Report.txt >> 
/opt/oinkmaster/Daily_report.txt 
   
# Use mutt to send our emails 
mutt -s "Daily Snort Changes" IDS_TEAM@organization < /opt/oinkmaster/OINK_Report.txt
   
# FUTURE/ IMPROVEMENTS
# Push to web server for a web portal ?
# Future? 
# Other ideas ? 
   
# Done !! 
   
##### END OF SCRIPT

You can configure several options in the oinkmaster.conf file to enable OinkMaster to change your rule sets. With the oinkmaster.conf file, you can specify such things as:

# find the line in the conf file 
# titled "update_files = .rules$|.config$|.conf$|.txt$|.map$"
# then change it to 
"update_files = .rules$

# find the line in the conf file 
# titled "skipfile=local.rules" 
# If you are following the above statement then uncomment 
# This line by removing the "#"

For example, to modify one or more Snort rules, edit the oinkmaster.conf file. You will need to specify the rule number and the change you want to make such as in the following example, which would be a good reference.

# modifysid 1378 "^alert" | "pass"

This changes Snort rule number 1378 from an alerting rule to a pass rule that will ignore the traffic.

If, however, you want to forcibly enable or disable specific rules, that’s possible as well. Use the enablesid and disablesid commands in the oinkmaster.conf file.

To enable a specific rule that was disabled in the official www.snort.org distribution, you would use something like the following:

# enablesid 1325

You can also disable a specific rule that was enabled by www.snort.org’s distribution. For example, you could disable a rule that, on your network, is quite noisy with false positives with the following:

# disablesid 1325

So as you can see, Oinkmaster offers quite a bit of functionality for an organization’s IDS team.

Finally, if you want a functional GUI for Oinkmaster, an oinkgui.pl file comes with the Oinkmaster distribution under the contrib directory. However, to run this under *nix systems, you will need to have Perl/Tk installed.

To install a new Perl module on a system, if you have root access, download Tk from this site, as found in the Oinkmaster documentation.

Once downloaded, the simplest way to install a new Perl module is to extract and compile the source code into your local Perl library.

# EXAMPLE tk800.024 
perl Makefile.PL 
make 
make test 
make install

If you are on a windows system and want to use the GUI, just download and install the ActivePerl Windows distribution. This build comes with all the components necessary to run the GUI.

# http://www.activestate.com 
# 
# Run the GUI  
perl oinkgui.pl

Once in the GUI, you will need to specify the location of several key components, such as the following:

Path to your Oinkmaster.conf file: 
C:snort22xOinkmasterOinkmaster.conf
Path to your oinkmaster.pl file 
C:snort22xOinkmasteroinkmaster.pl
your output directory 
C:snort22xOinkmasterlogs

For an example of GUI, see Figure 3-1, as you might find it easier to use than editing the config file itself.

Figure 3-1. Oinkmaster GUI examples

http://oinkmaster.sourceforge.net

Oinkmaster mailing list

With so much flexibility and so many predefined rules, how do I choose? Are there any rules that an organization should always have in its toolbox?

This is largely a matter of preference for each organization’s IDS team personnel, but a few rules are accurate indicators of potential problems on a network and well worth keeping around.

The most noticeable of these rules would be cmd.exe, which detects the automated Unicode and nimda-style attacks.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 
(msg:"WEB-IIS cmd.exe access"; flow:to_server,established; 
content:"cmd.exe"; nocase; classtype:web-application-attack; 
sid:1002; rev:6;)

Another one for helping find the virus/Trojan of the week is a custom rule that triggers on client machines acting as mail servers. We have found this rule very effective.

alert tcp !$SMTP_SERVERS any -> !$SMTP_SERVERS 25 (msg:"Possible 
virus Mailing";flags:A+;classtype:policy-violation;sid:11111; 
rev:1;)

This rule triggers on mail not sent from our mail servers to outside mail servers. However, with the most recent mydoom family of viruses (a family of viruses that spread via email rapidly), we have one word of advice: use the threshold.conf for this rule unless you want to have a flooded database. :) As this rule will be fired for every packet on port 25/tcp that wasn’t sent or received by your list of mail servers, it has the potential to generate lots of alarms. For organizations plagued by Instant Messenger, this might be helpful.

alert tcp $HOME_NET any -> $AIM_SERVERS any (msg:"CHAT AIM login"; 
flow:to_server,established; content:"*|01|"; depth:2; 
classtype:policy-violation; sid:1631; rev:6;)

This will trigger a lot if you have IM users on your network. However, when combined with session logging and other tools, you will have a nice evidence log of a clear policy violation. This is also helpful in the case of a financial organization, which, according to SEC mandate, must log and analyze all IM communications with external investment banking clients so they may detect potential securities trading violations.

The following triggers an alarm of the IE browser exploit from the MS04-013 vulnerability for the ms-its sub-protocol.

alert tcp any any -> any any (msg:"Possible browser hijacking"; 
content:"ms-its:mhtml:file"; content:"chm"; flags:A+; 
classtype:bad-unknown; rev:4;)

This will capture a user browsing or getting through email the exploit for this vulnerability. The file is hidden from IE by using a Microsoft compiled help (.chm) file to load. However, it is actually loading an .exe file that IE will helpfully execute locally on a user’s machine.

The following rule, which triggers on 403 errors coming back from your web servers, can be invaluable, especially if you are dropped into a new network as a consultant.

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any 
(msg:"ATTACK-RESPONSES 403 Forbidden"; flow:from_server,
established; content:"HTTP/1.1 403"; depth:12; 
classtype:attempted-recon; sid:1201; rev:7;)

This can help you identify what kind of traffic is affecting a client’s web servers. For example, if you walk into an organization and turn on this rule to get something like:

HTTP/1.0 403 Access denied to <webserver_IP>../../../winnt/system32
/repair/sam._

It would tell you that either the organization’s web server is still vulnerable to the directory traversal attack or that outside attackers are trying to exploit the system.

Hopefully, you will realize that there is no silver bullet set of rules to use in any organization. But this discussion should give you an idea of where to start and the broad scope of the rules.

If you are just coming into an organization, you can turn on the default Snort rules and tune down to a more manageable ruleset as you have time. Another option would be to tune out the default rules you know are useless.

Finally, if you want to tempt fate, you can get a copy of the rules at the following site: http://www.bleedingsnort.com. They are as close to zero-day rules as we can get, though a BIG word of caution goes out to people who are going to try to run them straight on a core or border sensor.

Recipe 3.6

http://www.bleedingsnort.com

Snort-sigs mailing list

I need to analyze a connection to verify whether it’s an attack or normal traffic. How can Snort help?

Snort has a couple of answers to your question. First, there is a keyword activate and its complementary keyword dynamic. When a rule marked activate is triggered, it turns on a corresponding dynamic rule to capture the exploit, log the next couple of packets, etc.

activate tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT 
expoit";content:"TTYPROMPT";depth:17;content:"|20|63|"; 
flow:to_server,established;sid:10555;reference:url:
packetstormsecurity.org/0210-exploits/telnet.c; rev:1; activates:1;) 
dynamic tcp $EXTERNAL_NET any -> any 23 (activated_by: 1; count:50;)

For example, the previous rule will trigger on a single exploit packet such as most Snort rules. However, this rule then calls its dynamic partner to log the next 50 packets to port 23 tcp, which is useful in capturing the results of a successful exploit of a victim system.

However, as you might have realized that this could get unmanageable with only a few rules. It’s also not very scalable. So Snort is slowly replacing those keywords with the tagging keyword. This provides a much simpler method to log attack responses. Here is the same rule changed to the new keywords.

alert tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT expoit"; 
content:"TTYPROMPT"; depth:17; content:"|20|63|"; flow:to_server,
established; sid:10555; reference:url:packetstormsecurity.org/0210-exploits/
telnet.c; rev:1; tag:session:50,packets;)

This example captures the same event as the activate rules with only one rule. This example uses the tag keyword to capture the next 50 packets over port 23 tcp with one addition, accuracy. The tag keyword tells Snort to log the next 50 packets in the same session between attacker and victim, ignoring other port 23 traffic on the network.

There are several options to the tagging keyword that might be more helpful to some organizations. For example, the ability to log only the attacker side of the connection or to limit the log based on time or number of packets.

This modification of the same rule is going to log only the next 50 packets to our victim machine using some of the options for the tag keyword. The options to the tag keyword are used to create a more accurate and filtered logfile. For example, if you only want to see one side of an attack as in the following, record only one side of the connections.

Alert tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT 
exploit"; content:"TTYPROMPT"; depth:17; content:"|20|63|"; flow:to_server,
established; sid:105556; reference:url,
packetstormsecurity.org/0210-exploits/telnet.c; rev:1; tag:host:50,
packets,dst;logto:telnet_exploit.log;)

This modification of the same rule logs only the next 50 seconds to our victim machine, using some more options to the tag keyword. The following example uses the opposite sub keywords to the previous example to capture only the next 50 packets heading back to the attacker.

Alert tcp $EXTERNAL_NET any -> any 23 (msg:"Solaris TTYPROMPT 
exploit"; content:"TTYPROMPT"; depth:17; content:"|20|63|"; flow:to_server,
established; sid:105556; reference:url,
packetstormsecurity.org/0210-exploits/telnet.c; rev:1; tag:host:50,seconds,
dst;logto:telnet_exploit.log;)

As you can see, this keyword provides a much easier method for event logging. It also provides a level of granularity and flexibility not found with the activate and dynamic keywords. When combined with the logto keyword, this can help when working with law enforcement and outside agencies/teams. The logto keyword specifies the name of the file to which to write the results of the alert. For this example, we want the traffic related to this specific event to be placed into a file called telnet_exploit.log. This will create and fill a file in the Snort logging directory when this event is seen, while also creating a session log for the tag keyword. These files can then be turned over to law enforcement as both the cause and effect of an attack, where the cause is seen in a full packet dump by the logto keyword file as well as the effect from the tag keywords’ file.

Snort official documentation (http://www.snort.org)

Snort-sigs mailing list

How can I detect when binary content is being used and downloaded on my network(s)?

The content keyword can detect when binary data is traveling over your network. The content keyword matches both ASCII text and HEX-encoded raw packet data.

For example, this rule triggers when the Napster client application is downloaded:

alert tcp $EXTERNAL_NET any -> $HOME_NET 8888 (msg:"P2P napster 
download attempt"; flow:to_server,established; content:"|00 CB 00|"; 
depth:3; offset:1; classtype:policy-violation; sid:551; rev:7;)

For some organizations, going to the Napster site may be allowed as long as files aren’t downloaded. Snort can detect when the policy is actually broken. The following rule triggers on the attempted download of the file itself and its ASCII name:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"P2P Napster
client installer"; flow:established; content:"NapsterSetup.exe"; 
classtype:policy-violation; sid:15543; rev:1;)

While rules that detect ACSII content are easier to write, they’re open to all kinds of IDS evasion attacks such as character encoding, extra spacing, and even other languages. It is in the best interest of the rule writer to try to find a HEX string in the binary content of the packets for accuracy. Not only are HEX strings faster to detect—as Snort doesn’t need to perform ASCII translation on the packet—but they are also more accurate alarms.

Finally, if you need some examples of rules that fire for HEX content with explanations, check out the archives of the Snort-sigs list. The list is a good resource for community-created rules and for help, if you’re having trouble creating rules or detecting traffic.

P2P rules at http://www.bleedingsnort.com

My company is overrun by malware. How can we track users who have malware and where it’s installed?

There is not easy way to detect all malware. However, you can use several methods to try to identify the traffic.

There are several methods with which to track these types of connections.

Gator is only one piece of malware that might be running across your networks. The key to detecting and identifying malware is the same as with other types of traffic. Find some common feature of the traffic, such as a word or phrase, or even the HEX of the packets. Then zero in on that and determine some specifics of the traffic that you can repeat with as much accuracy as possible. The other key is to watch your web traffic very closely. User-agent or browser identification is a great method for searching through the logs to find strange connections from your network. Another suggestion is to use some of Snort’s other tools to find hosts that are generating more traffic than normal or simply talkative hosts. Talkative hosts are usually an indication of a problem, unless they are servers.

Another suggestion is to use the malware ruleset from http://www.bleedingsnort.com. This entire ruleset just targets malware on a network. These rules—though you use them at your own risk—may help you figure out just how much of your total network traffic is used by malware/adware/spyware software. Finally, detecting this type of traffic is really a job for your web proxy server and your DNS server. When you use blocks or denies to hamper this type of traffic, you’ll have a more secure network and visibly better performance.

http://www.squidguard.org for the ideas about blocking malware

http://www.bleedingsnort.com for some malware rules

How can I use Snort to detect viruses, Trojans, and worms?

One way to detect viruses is to use the following rule from 3.x Rules. This will detect when a box has been infected with a virus that spreads via a new email server.

alert tcp !$SMTP_SERVERS any -> !$SMTP_SERVERS 25 (msg:"Possible 
virus Mailing";flags:A+;classtype:policy-violation;sid:11111; rev:1;)

Another rule that helps detect when email messages come through your mail server with “bad” attachments would be this one from the 2.2.0 ruleset. This rule detects 25 attachment types at once!

alert tcp $HOME_NET any -> $EXTERNAL_NET 25 (msg:"VIRUS OUTBOUND bad 
file attachment"; flow:to_server,established; content:"Content-
Disposition|3A|"; nocase; pcre:"/filenames*=s*.*?.(?=[abcdehijlmnoprsvwx])
(a(d[ep]|s[dfx])|c
([ho]m|li|md|pp)|d(iz|ll|ot)|e(m[fl]|xe)|h(lp|sq|ta)|jse?|m(d[abew]|s
[ip])|p(p[st]|if|[lm]|ot)|r(eg|tf)|s(cr|[hy]s|wf)|v(b[es]?|cf|xd)|w(m
[dfsz]|p[dmsz]|s[cfh])|xl[tw]|bat|ini|lnk|nws|ocx)[x27x22

s]/iR
"; classtype:suspicious-filename-detect; sid:721; rev:8;)

Officially, the www.snort.org ruleset carries the previous rule only for detecting viruses. This is because they are more worried about other threats to a network. The other consideration is that there’s no need to detect this type of traffic given the speed and scale of such devices as email gateway virus scanners, and also workstation and server antivirus products that even sweep running memory.

http://www.clamav.com open-source antivirus software

Chapter 7

We have a problem with users chatting over Instant Messenger networks. How can we detect when they are using the applications so that we can catch them in the act?

The following few examples track AOL IM, Yahoo! IM, and MSN IM usage on the network.

# This will detect when the client is logging into AOL 
Alert tcp $HOME_NET any -> $AIM_SERVERS any (msg:"Chat AIM login"; flow:to_
server,established; content:"*01|"; depth:2; classtype:
policy-violation; sid:1632; rev:1;)

Alert tcp $HOME_NET any -> $AIM_SERVERS any (msg:"Chat AIM Message"; 
Flow:from_client,established; content:"*|02|"; depth:2; content:"|00 
04 00 06|"; depth:4; offset:6; classtype: policy-violation; sid:1633;
rev:6;)

# This rule will fire on the binary data from the YIM client itself
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Chat Yahoo IM 
login"; flow:from_client,established; content:"|70 61 74 83 d2 f3 b2 
06 46 f6 d6 61 9e 3d 2e|"; classtype:policy-violation; sid:10570; 
rev:1;)

alert tcp $HOME_NET any -> any any (msg:"Chat Yahoo IM Message"; flow:to_
server,established; content:"YMSG"; dsize:>52; content:
"TYPING"; sid:10571; rev:1;)

Alert tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"Chat MSN IM 
message"; flow:established; content:"MSG"; depth:4; content:
"Content-Type|3A|"; distance:0; nocase; content:"text/plain"; 
distance:1; classtype:policy-violation; sid:540; rev:11;)

alert tcp $HOME_NET an <> $EXTERNAL_NET 1863 (msg:"Chat MSN IM file 
transfer accept";flow:established; content:"MSG"; depth:4; 
content:"Content-Type|3A|"; nocase; content:"text/x-msmsgsinvite"; 
distance:0; content:"Invitation-Command|3A|"; content:"ACCEPT"; 
distance:1; classtype: policy-violation; sid:1988; rev:3;)

Instant Messenger is a part of the normal work flow for some organizations. For example, in the financial world, IM is allowed, provided all communications are logged for SEC records. However, for other corporations, IM is just another way that people avoid work and possibly steal corporate information. It can be threat to your network since new viruses and Trojans have exploits through IM to bypass strict border security measures.

Another threat is that most of the IM services have Java or web clients that require no installation and run entirely from the browser. This makes them much harder to identify. Sites like p2pchat.net may send chills down your spine if you’re concerned about IM security. Some sites allow encrypted access using SSL and anonymous chatting over a web interface. A determined user could use these via a number of proxies to bypass your security measures.

The best hope an organization has for this type of traffic is to use other countermeasures to block it, such as content-based web proxies, DNS blocks of known IM and IM-supporting sites, and perimeter blocking of known IP space for IM servers.

Snort-sigs mailing list

How can I detect when users on my network(s) are using peer-to-peer (P2P) applications, possibly putting our company on the RIAA’s radar for investigation?

Much like the IM problem, P2P applications are hard to detect on your network. Users can choose from dozens of networks and just as many clients. One ideal solution would be to have a default policy of deny first on your firewall’s outbound traffic. However, in the real world of politics, corporate networking policies, and management exceptions, the ideal solution is rarely possible. So, we’ll just try to track the most popular networks: Kazaa, BitTorrent, and Gnutella.

Alert tcp $HOME_NET any -> $EXTERNAL_NET 1214 (msg:"Kazaa port in 
use"; flow:to_server;established; sid:10503; rev:1;)

Alert tcp $HOME_NET any -> $EXTERNAL_NET 1214 (msg:"Kazaa client 
activity"; flow:from_client,established;  content:"GET"; content:
"KazaaClient"; classtype:policy-violation; sid:10561; rev:1;)

Alert tcp $HOME_NET any -> any $HTTP_PORTS (msg:Bit Torrent Client 
download"; uricontent:"BitTorrent"; uricontent:".exe"; classtype: 
bad-unknown; sid:10559; rev:1;)

Alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Bit Torrent client 
usage"; content:"|00 00 40 09 07 00 00 00|"; offset:0; depth:4; 
classtype: policy-violation; reference:url,
www.bleedingsnort.com/bleeding.rules; sid:10560; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"p2p Gnutella client 
request"; flow:to_server,established; content:"GNUTELLA OK"; depth:40; 
classtype:policy-violation; sid:557; rev:6;)

Alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"p2p Gnutella client 
file connection"; flow:from_client,established; content:"X-Gnutel"; 
classtype:policy-violation; sid:10566; rev:1;)

These few specific rules should give you some idea of the range and flexibility of P2P clients to surf your network. More clients and more networks are available to your users. Several options can help you detect and defend against these applications.

Policy solutions:

Snort solutions:

cat session.log | awk '{ print $12 }' | sort | uniq -c | sort -nr >
Top_ports_uniq_connections.txt

cat session.log | awk '{ print $19 }' | sort | uniq -c | sort -nr > 
Top_clients_uniq_connections.txt

Immediately mark out known servers, and you are left with your top talking hosts. With a little scripting, you can determine with what ports and to whom your workstation has been communicating.

One feature of all P2P users on a network is that they will have lots of connections both in and out of your network. So keeping a count of network usage plays a large part in detection, especially on larger networks.

http://www.bleedingsnort.com

Snort rules and mailing lists (http://www.snort.org)

I have these great rules, but I went to Defcon and saw H.D. Moore (available here: http://www.metasploit.com) use IDS evasion to bypass Snort’s rules. How can I defend against that?

Snort is a signature-based IDS. Most of the methods of evading signature-based IDS systems rely on disguising the attack in a way that doesn’t match the standard signature. There will always be someone who writes some great evasion technology to bypass your signature-based IDS. However, all hope is not lost; Snort has several preprocessors that will help normalize the traffic.

Preprocessors are plug-ins to Snort that take data off the network and reassemble it in a similar format to the way it finally reaches the target. There are a number of ways to attempt to evade a signature-based IDS, and they all rely on making the packets fail to match the signature. Snort has several preprocessors and components that will help detect or ignore several types of IDS evasion tactics. For example, the http_inspect preprocessor can be very useful in fighting attacks that try to obfuscate the attack by hiding in Unicode or other character sets. Snort can also use its stream4 preprocessor to help rebuild packets that try to hide in a flood of seemingly nonessential packets. The frag2 preprocessor attempts to reassemble fragmented packets and detect when they have state problems. The following sections include detailed information on using preprocessors to protect against IDS evasion techniques.

preprocessor stream4: <options>

detect_scans

detect_state_problems

disable_evasion_alerts

ttl_limit

keep_stats

Noinspect

Timeout

log_flushed_streams

memcap

clientonly / serveronly / both

Ports

preprocessor frag2: <option>

Timeout

memcap

min_ttl

ttl_limit

detect_state_problems

preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.0.8 00:09:5B:3B:CE:E6

preprocessor arpspoof: -unicast

GET /default.id%u0061 HTTP/1.0

GET /default.ida HTTP/1.0

preprocessor http_decode

preprocessor http_decode: 80 8080 8000

Unicode

iis_alt_unicode

Double_encode

iis_flip_slash

full_whitespace

Abort_invalid_hex

drop_url_param

internal_alerts

H.D. Moore’s metasploit framework (http://www.metasploit.org) for some tools to test evasion techniques

Snort Users Manual

My web/FTP/SMTP server(s) are logging attack attempts that look like they should be detected by the Snort rules, but Snort isn’t seeing them. What is happening?

This is especially common when detecting HTTP traffic. With the liberal use of utf-8, Unicode, and even FrontPage HTTP extensions, it is child’s play to avoid detection by some rules. For example, the evasion attack in the previous recipe would never have been detected by the default Snort rule without the http_inspect preprocessor.

The preprocessors play an important role in allowing the rules engine to correctly identify attack traffic. Another suggestion, especially for encoded traffic, is to detect variations on an attack using the new rule keyword pcre (Perl-compatible regular expressions). For more information on creating and using regular expressions, check out Mastering Regular Expressions (O’Reilly). This will not only give you several good reference examples, but also devotes several chapters to the use of regular expressions in Perl. The following rule from Bleedingsnort.com detects most variants of Windows shell access:

#alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any 
(msg:"BLEEDING-EDGE Attempt to access SHELL:"; pcre:"/
(((URL|SRC|HREF|LOWSRC)[s]*=)|(url[s]*[(]))[s]*['"]*shell
[:]/i"; classtype:web-application-attack; sid:2001100; rev:1;)

Even using regular expressions, an attacker could still send a packet with %115%104%101%108%108 instead of shell to get past this rule. You can work around this by tuning the Snort sensor beyond the default http_inspect parameters to convert hex to ASCII normalization.

H.D. Moore’s metasploit framework (http://www.metasploit.org) for some tools to test evasion techniques

Koziol, Jack, et al. The Shellcoder’s Handbook. New York: Wiley, 2004.

Snort-sigs mailing list

Friedl, Jeffrey E. F. Mastering Regular Expressions. Sebastopol, CA: O’Reilly, 2002.

I have new rules and ideas for rules I want to test without causing problems for the production deployment. How can I use Snort to test itself?

There are actually a couple of answers to this question.

snort -c /path/to/my/snort.conf -i Sniff_interface -l 
/log/snort/path -T

For a full discussion of how to set up a testing infrastructure for Snort, check out the chapter on keeping Snort up to date in the Snort 2.1 book (Syngress). Solutions for a testing infrastructure for large and small organizations will differ with size, cost, and necessity.

Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.

Open Source Testing Methodology (http://www.osstmm.org/)

How can I speed up my rules to perform better and identify attacks faster?

Snort rules use several recursion loops to detect possible evasion attempts. The trick to optimizing rules is to make them specific enough that they can detect matches with as few passes as possible.

One possible solution is to use several discrete or single hit keywords at the beginning of your rules to help limit the times through the engine. For example, as mentioned before, if you can write your signatures to use the HEX values of the packets rather than the ASCII translations. Then Snort need only run the packet through the engine once the first time through without having to run the packet through the ASCII translation engine, and then pass it back through the rules engine.

We’ll start with a rule to detect the MS-ITS subprotocol exploit, and then optimize it.

alert tcp any any -> any any (msg:"Possible browser hijacking"; 
content:"ms-its:mhtml:file"; content:"chm"; flags:A+; classtype:
bad-unknown; rev:4;)

First, add a filter to the rule so it only examines packets with a large enough payload size. A window of greater than 64-bytes long should only display packets that have a TCP payload.

Alert tcp any any -> any any (msg:"Possible browser hijacking"; 
dsize>64; content:"ms-its:mhtml:file"; content:"chm"; flags:A+; 
classtype: attempted-admin; rev:5;)

Then make the payload a little more accurate, by using the keyword within.

Alert tcp any any -> any any (msg:"Possible browser hijacking"; 
dsize>64; content:"ms-its:mhtml:file"; content:"chm"; within:10; 
flags:A+; classtype: attempted-admin; rev:6;)

Now pull the rule over the flow keyword for one last bit of accuracy.

Alert tcp any any -> any any (msg:"Possible browser hijacking"; 
dsize>64; content:"ms-its:mhtml:file"; content:"chm"; within:10;
flow:established,to_server; classtype: attempted-admin; rev:7;)

Now this rule has several very specific parameters that have to be met on the first pass through the engine, or else the alarm will fail, thus dropping out of the several pass sequence.

Keep in mind when creating rules that the more specific your rules, the faster they will process through the Snort engine and the less load on the Snort engine they will place. If you place less of a load on the Snort engine, it’s less likely to drop connections and logs.

Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.

Snort-sigs mailing list and posts by Brian Caswell

You want to block an attack in real time.

There are two possible solutions. If you wish to terminate a particular connection, you should use the session termination as described in the Recipe 2.27 recipe. If, however, you wish to prevent the attacker from trying again, you should use the inline IDS described in the Recipe 7.4 recipe.

Active response, or intrusion prevention, varies in popularity. You should seriously consider the potential implications of its use, as it can be turned against you to produce a denial of service attack.

A malicious attacker can easily spoof an attack from what would normally be a legitimate IP address—for example, that of a regular customer. This would then be automatically excluded by the firewall, cutting off the legitimate user. This feature, while potentially very useful, can also be very dangerous. Please use with care.

Recipe 7.9

Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.

You want to suppress a rule without permanently removing it from the ruleset.

Use the suppress command to suppress a rule.

suppress gen_id <gen_id>, sid_id <sid-id>

Suppression allows you to deactivate a rule completely. The options are gen_id and sig_id. Gen_id is the generator ID, and sig_id is the Snort signature ID.

To suppress an event entirely:

suppress gen_id 1, sig_id 1234

Snort User Manual

Recipe 3.17

Noisy logs are the bane of every administrator’s existence! How do you reduce the size of your haystack to help find that all-important needle?

Use the threshold keyword:

threshold: type <limit:threshold:both>,  track <by_src:by_dst>, count 
<n>, seconds <n>;

Thresholding is a useful way of thinning down your logs. It also allows you to monitor for other unusual behavior. If you suddenly see a lot of NFS errors—as opposed to one or two every minute—you certainly have a problem, but you won’t want to be alerted for every single NFS error.

To alert the first n times that an event happens during a time interval, use limit. To alert every nth occurrence during the time interval, use threshold.

There is also the combination type of both, which alerts once after n instances of the event.

The track keyword is used to monitor traffic either by source IP address or destination IP address. It provides a method for grouping events to enable thresholding. Tracking is done either by source or destination IP address only; there is no tracking done on ports or any other criteria. The count is the number of events for the threshold and both types, and the number of alerts for the limit type. The seconds option sets the time during which the events should be counted, and, funnily enough, is in seconds.

So to set the threshold of an alert on every ten occurrences of a rule within a five second period from the source for the rule, use the following:

threshold: type threshold, track by_src, count 10, seconds 5;

Snort User Manual

Recipe 2.25

You need to log everything except . . .

Use the suppress keyword, as described in “Suppressing Rules,” but use the additional options to qualify the suppression better.

suppress gen_id <gen_id>, sig_id <sig_id>, track <by_src|by_dst>, ip 
<ip|NetMask>

To be a little more selective with suppress, use the track and ip options. The track option specifies whether you are interested in packets coming or going, and ip specifies either a single IP address or a range.

To suppress an event from a specific IP:

suppress gen_id 1, sig_id 1234, track by_src, ip 192.168.0.8

To suppress an event going to a subnet:

suppress gen_id 1, sig_id 1234, track by_dst, ip 192.168.0.0/24

Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.

Recipe 3.15

Recipe 3.17

You want Snort to alert you to behavior on your network that isn’t normal.

Use the Spade preprocessor S plug-in.

Download a copy of Spade. Its original creators are no longer around, but as it has been released under the GNU Public License, it is still available and is now being maintained again. Download a copy here: http://www.computersecurityonline.com/spade/.

In the top level of your Snort distribution, uncompress and unpack the Spade distribution by typing the following:

tar xzvf Spade-040223.1.tgz

Change into the Spade distribution directory and make the distribution by typing the following:

cd Spade-040223.1
make

Compile Snort as normal according to Recipe 1.n.

To get started quickly, copy the lines included in the spade.conf file into your file snort.conf to enable the preprocessor.

Plenty of tools allow you to do statistical analysis of alerts you’ve already collected. Spade creates an overview of the “normal” behavior of the network based upon observed history. The fewer times a packet of a certain type is seen, the higher its anomaly score. This will very quickly balance out to show the normal behavior of your network (you can also configure Spade to show you what the normal behavior of your network is, which is very useful for capacity planning) and will flash up any “odd” packets. Spade is bright enough not only to spot unusual source and destination ports and IP addresses but also oddly “shaped” packets with odd configurations of flags.

Once you have carried out the installation instructions, you will need to edit your snort.conf file. An example of all the requisite lines for enabling Spade is included in the spade.conf file in the distribution directory.

The following should be added to snort.conf:

preprocessor spade: {<optionname>=<value>}

You can add any of the options listed in Table 3-5.

Logfile

Statefile

Cpfreq

Dest

Adjdest

You then need to give Spade a bit of an idea about the location of the Snort sensor within the network. You do this by inserting the following line:

preprocessor spade-homenet: [<network>,<network>,...]

You’ll need to specify your network using CIDR notation (e.g., 192.168.0.0/24), a specific IP address (e.g., 192.168.0.8), or any (which means everything). The any setting is the default if no other line is specified. The spade-homenet setting is unrelated to any Snort options about the home network.

You’ll now need to set up some detectors. Detectors are the bits that do the work, somewhat like rules, and allow you to create more targeted statistical analysis of your traffic. The format of a detector line is as follows:

preprocessor spade-detect: {<optionname>=<value>}

You can use any combination of the options listed in Table 3-6.

Type

To

From

Proto

Tcpflags

Icmptype

Thresh

Minobs

Wait

Xdips

Xdports

Xsports

Id

Revwaitrpt

Scalefreq

Scalefactor

Scalehalflife

Scalecutoff

Each detector type makes use of the other options in slightly different ways; some options are inappropriate for use with a specific detector type.

to,id

Protocol

Tcpflags

Wait

Revwaitrpt

to,id

Tcpflags

Icmptype

from, id

Protocol

Wait

Revwaitrpt

from, id

Protocol

Maxentropy

To, id

Icmptype

Spade User Manual