0

I am a relatively new Snort user with years of sys admin experience. I feel that I must be missing something, because I find Snort rules to be completely undocumented and incomprehensible. Because of this, there's no course of action that I can take based on the rule alert to address the problem.

Example: My Snort alerts include the following today: "SID 2016847: ET INFO Possible Chrome Plugin install"

Okay, Snort finds it very important to tell me that there's a Chrome Plugin install. Does that mean an existing plugin install? Or a newly downloaded install? Who knows.

I find the following Wiki on the Emerging Threats website, which is supposed to "document" what the Snort rules mean. Here's the entry for SID 2016847:

http://doc.emergingthreats.net/bin/view/Main/2016847

Amazingly, no documentation. Not a stitch. There's a URL embedded in the rule: http://blogs.technet.com/b/mmpc/archive/2013/05/10/browser-extension-hijacks-facebook-profiles.aspx

Okay, great. Finally someone is describing what the threat is, two levels of indirection later. While the author describes some of the symptoms of the plugin trojan, there's not a word of how to address the problem. Am I supposed to update my browser? Which ones? Which versions? What's the name of the evil extension to purge? Will purging be sufficient? Do I need to restart my computer? Should I burn my hard drive in a flaming pentagram?

I was really hoping that Snort would be helpful, and not just spit out tons of alerts that are not actionable. I'm hoping some seasoned security expert here can enlighten me on the correct way to respond to these alerts. If your answer is, "suppress every alert that you don't understand", then you are not answering the question. There should be a way for any reasonably adept computer administrator to read these alerts, figure out what they need to check or do, and address the root problem.

Improve this question
4
  • Thanks for the reply, schroeder. I've seen links like that on rare occasions. The majority of rules don't have any documentation, let alone a description of how to actually respond to the alert.
    – taltman
    Jun 15, 2015 at 20:55
  • I just downloaded the community rules set, and it looks like every rule has a reference. The reference is rarely a link, but most often a reference to an authoritative source (Nessus, Metasploit, CVE, etc.).
    – schroeder ♦
    Jun 15, 2015 at 21:01
  • Maybe I'm using the wrong terminology. Just as a hyperlink is not an acceptable answer on SE, I don't consider a link in a rule "documentation". Also, perhaps there's confusion because I'm referring to the ET ruleset, and you're referring to the community rule set? I'm new to this, so I might be confused.
    – taltman
    Jun 15, 2015 at 21:10
  • This is where "suppress every alert that you don't understand" comes in to play. Snort feels the responsibility to detect the traffic signature so that admins have the option to deal with it or not, they do not feel the responsibility to determine how to fix it. It is a packet analysis and alert tool, not a diagnostic tool.
    – schroeder ♦
    Jun 15, 2015 at 21:22

2 Answers 2

Reset to default
2

If you want something that provides advice targeted to your specific needs and environment, then a free Snort or Suricata install without a support contract from an established vendor or good consultant is probably not the best solution for your desires, though it may fit your budget.

In general, start off with the default SNORT rulesets you use - the community rules and/or Emerging Threats Open or Pro, and/or one of the SNORT rulesets.

See what alerts it pings, to where, and from where.

  • You may need to enable SNORT on a LAN interface to get a better view of where they're coming from. Alternately, assign a 1:1 NAT to one or more suspect internal IP's so the external IP address is meaningful in some way.
  • Read the rules! Follow the links! Use your search engines!
  • Learn!
    • Just last night I enabled some Confiker-C rules that immediately alerts on an app I expected was good, and which turned up clean on multiple antivirus scans.
  • Experiment!
    • In your example, try a Chrome plugin update, see if it alerts. Then try a new install, see if it alerts.
  • Enable or Disable! The most efficient course of removing a rule is disabling it.
  • Suppress!
    • Suppressing rules to specific IP's allows "whitelisting" rule+IP combinations, which is quite useful.
    • Every time you suppress, open up the suppress file and add a comment about why you suppressed the rule in that case. This will be useful later when you're evaluating your suppress list, and to anyone else that inherits what you've done.

SNORT rules aren't supposed to inform you of what you should do about them; for instance, my favorite recurring alert is "ET POLICY Outdated Windows Flash Version IE" - Obviously, you should uninstall Flash entirely! - Wait, no, you should update Flash! - Hey, this is for a particular mission critical business app that doesn't work on new Flash, and you should suppress the alert ONLY for this particular IP address.

There's no way someone else can know your business.

There's no way the rule writers can predict future false positives, even if they had the time, budget, and inclination to look hard for false positives across all possible legitimate traffic in the first place.

To sum up, you have three major choices: Hire an expert to do this for you, learn about each alert type using the data provides and some research, or disable blindly.

If it helps, the learning curve does even out, until the next issue shows up (SNORT blocking a particular Blu-Ray player from accessing Netflix because it's vulnerable to POODLE and the maker didn't patch it then or ever, for instance), and then the research should be easier.

Improve this answer
1

Typically, each rule includes a reference to the problem. In your specific case, the rule directly states:

reference:url,blogs.technet.com/b/mmpc/archive/2013/05/10/browser-extension-hijacks-facebook-profiles.aspx

This line is directly in the rule itself and serves as the explanation.

The rule exists to alert you to suspicious traffic. You need to determine what your risks and actions are to be. Snort is not a full-feedback-loop end-user problem-solving tool; it inspects traffic and alerts based on signatures. The intent isn't for it to tell you how to fix your problem, just to alert you to a potential problem. It's the "check engine" light on your dash. When it lights up, you need to launch an investigation.

Improve this answer
1
  • 1
    Again, thanks for your reply! I see your point about the "check engine light" analogy. But in my specific example, the analogy would be that my car manufacturer had an engineer who put in a diagnostic sensor, that triggered a light appearing on my dash. Upon looking up the meaning of the light on my dash in the user manual, it told me that badness might be happening, but refuses to say where to find the faulty part, despite the fact that the engineer at the car manufacturer knows perfectly well what the bad part looks like. This is effectively like an undocumented exit code.
    – taltman
    Jun 15, 2015 at 21:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .