doc/userguide/make-sense-alerts.rst

   1 Making sense out of Alerts
   2 ==========================
   3
   4 When an alert happens it's important to figure out what it means. Is it
   5 serious? Relevant? A false positive?
   6
   7 To find out more about the rule that fired, it's always a good idea to
   8 look at the actual rule.
   9
  10 The first thing to look at in a rule is the description that follows
  11 the ``msg`` keyword. Let's consider an example: ::
  12
  13   msg:"ET SCAN sipscan probe";
  14
  15 The "ET" indicates the rule came from the Emerging Threats (Proofpoint)
  16 project. "SCAN" indicates the purpose of the rule is to match on some
  17 form of scanning. Following that, a more or less detailed description
  18 is given.
  19
  20 Most rules contain some pointers to more information in the form of
  21 the "reference" keyword.
  22
  23 Consider the following example rule: ::
  24
  25   alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS \
  26     (msg:"ET CURRENT_EVENTS Adobe 0day Shovelware"; \
  27     flow:established,to_server; content:"GET "; nocase; depth:4; \
  28     content:!"|0d 0a|Referer\:"; nocase; \
  29     uricontent:"/ppp/listdir.php?dir="; \
  30     pcre:"/\/[a-z]{2}\/[a-z]{4}01\/ppp\/listdir\.php\?dir=/U"; \
  31     classtype:trojan-activity; \
  32     reference:url,isc.sans.org/diary.html?storyid=7747; \
  33     reference:url,doc.emergingthreats.net/2010496; \
  34     reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Adobe; \
  35     sid:2010496; rev:2;)
  36
  37 In this rule, the reference keyword indicates 3 urls to visit for more
  38 information: ::
  39
  40   isc.sans.org/diary.html?storyid=7747
  41   doc.emergingthreats.net/2010496
  42   www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Adobe
  43
  44 Some rules contain a reference like: ``"reference:cve,2009-3958;"`` should
  45 allow you to find info about the specific CVE using your favorite
  46 search engine.
  47
  48 It's not always straight forward and sometimes not all of that
  49 information is available publicly. Usually asking about it on the
  50 signature support channel can be helpful.
  51
  52 In :doc:`../rule-management/suricata-update` more information on the rule
  53 sources and their documentation and support methods can be found.
  54
  55 In many cases, looking at just the alert and the packet that triggered
  56 it won't be enough to be conclusive. When using the default Eve settings
  57 a lot of metadata will be added to the alert.
  58
  59 For example, if a rule fired that indicates your web application is
  60 attacked, looking at the metadata might reveal that the web
  61 application replied with ``404 not found``. This will usually mean the
  62 attack failed but not always.
  63
  64 Not every protocol leads to metadata generation, so when running an
  65 IDS engine like Suricata, it's often recommended to combine it with
  66 full packet capture. Using tools like Evebox, Sguil or Snorby, the
  67 full TCP session or UDP flow can be inspected.
  68
  69 Obviously there is a lot more to Incidence Response, but this should
  70 get you started.