[3] Snort Configuration : Refinement

Rule Refinements

This section is the fun part of tweaking specific rules to match your environment. We recommend a regular strategy of nosing through your Snort output. As time passes, the composition of your network changes, and the minefield of vulnerabilities expands.

Trimming the fat

Likely the first refinement that any IDS guru recommends, almost to the point of being a broken record, is to reduce your false positives by stripping the dead wood from your rules files.

We recommend that you sit down with a map of your network and a list of your network connected assets (operating systems and exposed services are the most critical) and build a table of your computer resources that can be attacked. From there you comment out those rules that just don’t matter. If you have ten Windows NT servers running MS Project Server and nothing else, there’s little need for a thousand Linux/Unix rules.

Commenting out unneeded rules is a simple matter: Just edit the file containing the rule and place a “#” before the first character of the rule type (generally “alert”).

Chapter 9 includes more tuning methods that reduce false positives and the reasons why removing the extra noise keeps your Snort a-snorting.

Making adjustments

Small changes to the rules files of your setup can keep your Snort installation running at peak efficiency. By refining the rules that you are already running with Snort, you generate better reports, waste less time reviewing them, and react faster.

 Warning   Before editing any Snort rule file, it’s highly recommended that you do the following:

• Always make a backup of that rule file.

• Make sure that you use a plain text editor that doesn’t add any funky formatting or characters when you save the file. The vi program in Linux and Notepad in Windows are good examples.

Start by finding a rule that can use some tweaking. Maybe this DNS rule was misclassed:

alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"DNS SPOOF query response 
PTR with TTL\: 1 min. and no authority"; content:"|85800001000100000000|"; content:
"|c00c000c00010000003c000f|"; classtype:bad-unknown; sid:253; rev:2;)

Out of the box, it’s classified as a “bad-unknown” alert. Maybe it should be reclassified as a reconnaissance or information probe, consistent with an “attempted-recon” tag. To change the rule, just edit the dns.rules (the file that contains the rule we’re modifying) and change it to something like

alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"DNS SPOOF query response 
PTR with TTL\: 1 min. and no authority"; content:"|85800001000100000000|"; content:
"|c00c000c00010000003c000f|"; classtype:attempted-recon; sid:253; rev:3;)

 Technical Stuff  We bumped up the revision number to 3 so that another person can see that something’s changed.

 Tip  If you plan on making lots of changes to the base rules that come with Snort, keep a local backup copy of the original version outside of the directory that Snort uses to manage its configuration. If you upgrade Snort without keeping copies of all your custom tweaking, you may accidentally overwrite the whole lot with one punch of the enter key!

Building a rule from whole cloth

In some cases, a new rule is needed. Situations that might require a new rule include:

• Some sort of odd behavior on the network has been noticed: Maybe an abnormal amount of data is transferred on the network after hours, or a particular server is rebooting for no apparent reason. An investigation begins to determine what these oddities mean, and based on captured network data, you can create a rule that matches the odd event.

• A new attack hits the Internet. There are no existing Snort rules that match the attack, so you decide to create a rule on your own.

 Tip  For almost all configurations, the standard set of rules (if regularly updated) can be just what the doctor ordered. The need to build a whole rule from scratch isn’t an everyday occurrence.

Here’s a real-world situation that we can use as an example. While on-site at a customer’s facility, we heard that its network was acting irrationally and that the customer needed our help in isolating the cause of it. After an hour of tracking back a huge amount of network bandwidth coming from two workstation computers, we found that they were infected with some sort of virus. We diagnosed a virus by running a packet sniffer and capturing all of those workstations’ network communications.

All of that techno-sleuthing work we did can be best summarized into a packet capture, or at least a fair approximation of one. What follows is a snippet of what we were looking at:

15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376

0x0000   4500 0194 bec2 0000 6d11 d406 d963 055d        E.......m....c.]
0x0010   d8ab 0224 1069 059a 0180 6b52 0401 0101        ...$.i....kR....
0x0020   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0030   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0040   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0050   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0060   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0070   0101 0101 0101 0101 0101 0101 01dc c9b0        ................
0x0080   42eb 0e01 0101 0101 0101 70ae 4201 70ae        B.........p.B.p.
0x0090   4290 9090 9090 9090 9068 dcc9 b042 b801        B........h...B..
0x00a0   0101 0131 c9b1 1850 e2fd 3501 0101 0550        ...1...P..5....P
0x00b0   89e5 5168 2e64 6c6c 6865 6c33 3268 6b65        ..Qh.dllhel32hke
0x00c0   726e 5168 6f75 6e74 6869 636b 4368 4765        rnQhounthickChGe
0x00d0   7454 66b9 6c6c 5168 3332 2e64 6877 7332        tTf.llQh32.dhws2
0x00e0   5f66 b965 7451 6873 6f63 6b66 b974 6f51        _f.etQhsockf.toQ
0x00f0   6873 656e 64be 1810 ae42 8d45 d450 ff16        hsend....B.E.P..
0x0100   508d 45e0 508d 45f0 50ff 1650 be10 10ae        P.E.P.E.P..P....
0x0110   428b 1e8b 033d 558b ec51 7405 be1c 10ae        B....=U..Qt.....
0x0120   42ff 16ff d031 c951 5150 81f1 0301 049b        B....1.QQP......
0x0130   81f1 0101 0101 518d 45cc 508b 45c0 50ff        ......Q.E.P.E.P.
0x0140   166a 116a 026a 02ff d050 8d45 c450 8b45        .j.j.j...P.E.P.E
0x0150   c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45        .P........<a...E
0x0160   b48d 0c40 8d14 88c1 e204 01c2 c1e2 0829        ...@...........)
0x0170   c28d 0490 01d8 8945 b46a 108d 45b0 5031        .......E.j..E.P1
0x0180   c951 6681 f178 0151 8d45 0350 8b45 ac50        .Qf..x.Q.E.P.E.P
0x0190   ffd6 ebca                                      ....

That same sequence of bytes was being repeated ad nauseum by the two busted computers. What we didn’t know at the time was that a new worm outbreak had just started to infest the Internet. What we were seeing with that hex dump was the MS-SQL worm (also known as Slammer) in its replication stage. To bandage the situation, we unplugged the two offending computers and ran to our Snort installation, where we chopped a few bytes out of this trace to build a signature and ultimately a Snort rule to catch any more of these instances.

To illustrate, here’s a string of 16 bytes that can represent this novel worm:

c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45

Line number “0x0150” is an example of a segment made into a signature. Now, on to the fun part of making a Snort rule out of that gunk! The first goal is to build an appropriate header. A review of the first line of the trace dump gives all the necessary network information you need to construct a header.

15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376

Table 8-6 identifies the meaning of each of the preceding line’s component elements.

Table 8-6: Components of Packet Trace

Description	Value
Time packet was sent	15.30:05.000913
Source address	10.3.232.38
Source port	1522
Destination address	192.168.4.81
Destination port	1434
Protocol	UDP
Packet size (bytes)	376

All that’s needed from Table 8-6 are the protocol and the destination port. The source IP address, source port, and destination IP address show up differently when coming from and going to different systems. Remember, we’re looking for new instances of this worm, not the infected systems we already know about. Coupled with the signature that was scissored from that big block of packet data, that’s the complete makings of a fledgling Snort rule. All the pieces fit together like this:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"New MSSQL Worm A-Multiplyin’";
 content:"|c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45|"; sid:1000001; rev:1;)

 Technical Stuff  The preceding example highlights the following best-practices in creating a Snort rule:

• We followed the path of the good Snort administrator and made the Snort ID equal to 1,000,000.

• The revision is marked as 1, meaning that this attempt was our first at drafting a rule to achieve the wanted results.

After testing, if our signature isn’t right or other elements need tweaking, we can make the changes and increase the rev number to reflect the changes.