snort signatures create lots of false positives

Hi All,

Just want to share your opinion abt snort Inline mode.the snort signatures are not accurate and using them in Inline mode??
I have seen some IPS companies using snort signatures.

please share your thoughts.

thank you
ratna

The published Snort signatures are usually quite accurate but you need to understand that they are tested as well as they can be and fine tuned as needed but there is no way they can fit _every_ single network out there. That's why the rule writing language is so accessible and relatively simple so that you can fine tune them yourself to better fit your network. If there are a lot of FP's on your network for a certain rule you need to determine whether you even need the rule or not. If you need the rule because there is a potential threat to your network within it then you can look at the rule and fine tune it yourself to better fit your network. If you don't need the rule then comment it out... The more you comment out because they pose no threat the more efficient the detection engine will be.

Sourcefire is traveling around right now offering classes for open Snort. I haven't gone but have been wanting too.

i agree with u regarding commenting the unwanted rules.but what if is a critical vulnerability
we can't just comment it out.
i have also noticed lots of snort signatures are generic in nature

Generally you will find that only certain machines will cause a significant number of false positives so you can often negate the IP address or range. If you can't negate it within the rule itself you can create a "Pass" rule for the offending IP(s). However, you need to be _very_ careful how you use "Pass" rules because you can drop traffic that you might want.

In order to make a "pass" rule do the following. Let's say the rule causing the false positives is:-

alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg: "Internet Use"; Flags: S;)

Obviously this rule is going to catch you surfing your pr0n which we don't want... (Let's assume that you have very disciplined users and they never try to break policy so your box is the only one causing the FP's <LOL>)

Copy and paste the rule and change "alert" to "pass", change "$HOME_NET" to your box's IP address and alter the comment so you know why you are "passing" this traffic. It should now look like this:-

pass tcp [your_IP] any -> $EXTERNAL_NET 80 (msg: "My pr0n Surfing"; Flags: S;)

Done... Well, nearly...

Even though the rule is in place it won't "pass" your traffic until the mechanism Snort uses for rules processing is altered to accept the "Pass" rule. Stop Snort and add "-o", (without the quotes), to the command line and restart Snort. This allows Snort to first check traffic using the "Pass" rule first and then move on to the "Alert" rules and it will stop reporting your pr0n surfing making you look like that fine, upstanding young man you clearly are... <VBG>

Obviously you want to write "Pass" rules that are as _specific_ as possible. The more detail you can force it to match yet still not cause FP's on the "alert" rule the better. The broader you leave the "match pattern" the more likely you are to make a mistake and "pass" traffic that you really needed to see...

*Any* signature based solution will generate false positives, period. No matter what vendors tell you, or open source developers, there is no way to weed out 100% of the false positives that are flagged.

That said, you've already gotten the best advice out there for signature based solutions. Tune, tune, tune. This is the only way to get the rate down to an acceptable level. One thing that I'd like to add is that tuning is a never ending process. There is no, "set it and forget it".

--Th13

Don't forget you can also threshold the signatures, so that if one is alarming too frequently you can back off so that it only alerts once over the specified time period (thus combining them all).

Look in your threshold.conf file for a decent explanation of how it works...

(i.e., from the file):

Quote:

---

# Limit to logging 1 event per 60 seconds
# threshold gen_id 1, sig_id 1851, type limit, track by_src, count 1, seconds
# 60

---

EDIT: Would also like to add that you should be extremely careful with supression, thresholds, and pass rules...poorly written or conceived changes may utterly nerf the ability of snort to be useful as an IDS (for example, if you were to implement TigerShark's example, you'll miss ALL alerts/alarms for _ANY_ outbound HTTP connection from your PC to an external network...So while messing around with these, make sure they are exceptionally specific...

Quote:

---

There is no, "set it and forget it"

---

Oh yes there is... We have one... It cooks a great leg of lamb!!!! Here :D

I've been writing Snort rules professionally for over 6 years now. I'm not going to say who I work for, but you can probably guess.

Feel free to shoot any Snort questions my direction, or Check out the Snort-users and Snort-sigs mailing lists on www.snort.org