Basic Rules You Shouldnt Leave Home Without

Basic Rules You Shouldn t Leave Home Without

Problem

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?

Solution

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

Discussion

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.

See also

Recipe 3.6

http://www.bleedingsnort.com

Snort-sigs mailing list

Dynamic Rules