Process for investigating alerts

  • When I see a new alert, I enter the rule's msg into my favorite search engine to see what I might learn about it, and I also look to see if the gid:sid are in anyone's favorite disable lists. While I am looking forward to learning more about detection options so that I might be able to better understand why a rule is triggering, I expect there will be too many rules for me to be able to understand what each of the issues are.

    I am probably going to rely heavily on other forum members' recommended disable lists, as much as I would like to know the back story for each rule.

    My goal is to see if I can get snort configured well enough so that it can block, without causing a mutiny :)

    Here is an alert for traffic returning from the printer:
    17:43:28 2 TCP Potentially Bad Traffic
    61854 120:28

    I don't see 120:28 on anyone's favorite disable lists.
    Searching on INVALID CHUNK SIZE OR CHUNK SIZE FOLLOWED BY JUNK CHARACTERS leads me to a lot of rabbit holes (do I take the red pill?).
    I don't know which of the two conditions triggered it; was it the chunk size, or was it chunk size followed by junk characters?
    I also don't know what the chunk size was, or what the junk characters were.

    I would love to learn the steps that you all take to understand if what you are seeing is either malicious, or suspicious enough to deserve a block in IPS mode. Especially when you are not able to find a quorum of members agreeing that it is not something to worry about. Or at least everything that you do before just rolling the dice and disabling :) (or suppressing it for a hopefully trusted IP or netblock).
    thank you!

  • 119:2

    These are the rule's I have disabled for my network's.

    All the 1:7... are appid rule's and you notice very few of the snort subscriber rule's are disabled simply because I have'nt seen any false positive's from them.

    I think you should review your setting's on your printer to see if you can't use HTTP(s) instead of HTTP.

  • When you have some time, take a tour through this old discussion thread:

    It provides the views and logic from some experienced IDS admins around which rules can be safely suppressed or disabled.

    Many of the rules are actually designed to be more "informational" and not to necessarily indicate nefarious behavior. In fact, the majority of the HTTP_INSPECT preprocessor rules are just for information and do not always indicate malicous behavior.

  • @bmeeks Thank you Bill!

    I've re-read that, this time comprehensively, along with a complete read of "Taming the Beasts", truly a beast of a thread! While a lot of the material appears to be out-of-date, I definitely absorbed a lot from them and gained even more appreciation for the efforts from folks like you. I'm still a bit stunned by the sign off by @jflsakfja

    Among the things I have learned, if I have these correct:

    1. It is great to know about using a config file for disabling rules!
      Notes on my TODO list:
    • SID Management, "Enable Automatic SID State Management"
    • Add disableSid.conf
    • Reference disableSid.conf under Disable SID File.
    • State order should be "Disable, Enable"
    1. event_filter seems like it could be a good step before going full-draconian disable on a rule.
      TODO: find out if these can go into a config file too.

    2. The use of comments in disable lists is very helpful.

    3. I may want to add some "golden rules" to ID and put a quick end to port scanners, but don't think these will be helpful until I am setting up an installation where I need to open ports and am ready to go full-monty and start blocking. Something like this I think:
      drop tcp $EXTERNAL_NET any -> any !$MY_OPEN_PORTS (msg:"Golden Rule TCP"; classtype:network-scan; sid:9900001; rev:1;)
      drop udp $EXTERNAL_NET any -> any !$MY_OPEN_PORTS (msg:"Golden Rule UDP"; classtype:network-scan; sid:9900002; rev:1;)

    However, I am starting to wonder whether I can possibly have the time required to keep snort properly configured, as I don't support networks for a living, I develop software. I anticipate that many will say "maybe not, but then you won't have the time to deal with intrusion/malware either", and I would have to agree with that.

    I have two use cases to consider:

    1. Home/office network (protection from internal actors)
      Pretty happy with all of the protection afforded by pfSense, VLAN-capable switches/APs, and pfBlockerNG-devel, but I recognize the limitations, especially with family laptops spending time connected to other networks. I love the idea of using Snort to identify and stop acquired malware.

    2. Cloud-based web servers (protection from external actors)
      Simply keeping the bad guys out and combatting DoS, I guess that's it?
      (in addition of course, to keeping all software up-to-date, best practices, and all)

    Certainly, I can cobble together a greatest hits collection of rules to disable, but that seems like such a leap of faith to me. Is that my best course of action? For both use cases?