Next: , Previous: General Process Steps, Up: Analysis of Incidents and Alarms



5.3 Understand What Triggered the Alarm(s)

To understand what triggered the alarm, compare the signature or rule code with payload. The network traffic that matches the signature, rule, or policy is known as the payload. The payload that triggers the alarm is usually included in the Bro's incident report. Often it is obvious that the payload is not malicious.

Example: The signature may trigger on the word shadow, notifying that someone may be attempting to download the shadow password file. However, the payload may reveal that the actual download is something like theshadow.jpg, which is obliviously innocuous.
The two kinds of alarms, converted signatures and embedded rules trigger alarms differently, so they must be treated separately. The following sections describe how to investigate the signature or rule code and payload of each.

5.3.1 Converted Snort Signatures

These signatures are recognizable by the inclusion of a bro number and the identification SensitiveSignature. A signature code and payload block should be present in the incident report. To understand what triggered the alarm, compare the payload to the signature code and find the defined signature within the payload. Since some payload lines can get extremely long, the payload lines in the report and notice and alarm logs has been truncated to 250 characters. Sometimes the actual trigger payload is beyond the 250 character cut off. In this case, the protocol sessions log file must be examined. See Examine HTTP FTP or SMTP Sessions.

5.3.2 Embedded Bro Rule

For alarms triggered by an embedded Bro rule the signature code block will not appear, and in many cases, neither will the payload. There is currently no direct way to find the specific Bro rule that triggered the alarm other than to search the Bro policy files. Following is a process for conducting that search. The example of the HTTP_SensitiveURL is used. In actual practice, this rule appears quite often in the reports.

Read about the specific analyzer: In the Bro Technical Reference Manual there are sections for each type of analyzer. In the case of our example the HTTP analyzer is the obvious choice. In the section on the HTTP analyzer, it is noted that the variables sensitive_URIs and sensitive_post_URIs are responsible for flagging sensitive URIs.
Find the policy file that defines these variables: Using egrep to search for sensitive_URIs and/or sensitive_post_URIs yields the following:
          > egrep "sensitive_URIs | sensitive_post_URIs" http*
          http-request.bro:   const sensitive_URIs =
          http-request.bro:  # URIs that match sensitive_URIs but can be generated by worms
          http-request.bro:   const skip_remote_sensitive_URIs = /\/cgi-bin\/(phf|php\.cgi|test-cgi)/ &redef;
          http-request.bro:   const sensitive_post_URIs = /wwwroot|WWWROOT/ &redef;
          http-request.bro:   if ( (sensitive_URIs in URI && URI != worm_URIs) ||
          http-request.bro:   (method == "POST" && sensitive_post_URIs in URI) )
          http-request.bro:   skip_remote_sensitive_URIs in URI )
     

Clearly http-request.bro is the file of interest. If, in the case of other types of analyzers, more than one file appears, look for the place where the const statement is used to declare the variable(s).

Look into the policy file: Search in the section of Bro policy code that describes the rule(s) for the specific notification. In the file http-request.bro, is found:
     
     export{
        const sensitive_URIs =
           /etc.*\/.*(passwd|shadow|netconfig)/
           | /IFS[ \t]*=/
           | /nph-test-cgi\?/
           | /(%0a|\.\.)\/(bin|etc|usr|tmp)/
           | /\/Admin_files\/order\.log/
           | /\/carbo\.dll/
           | /\/cgi-bin\/(phf|php\.cgi|test-cgi)/
           | /\/cgi-dos\/args\.bat/
           | /\/cgi-win\/uploader\.exe/
           | /\/search97\.vts/
           | /tk\.tgz/
           | /ownz/        # somewhat prone to false positives
          &redef;
     
          # URIs that match sensitive_URIs but can be generated by worms,
          # and hence should not be flagged (because they're so common).
          const worm_URIs =
               /.*\/c\+dir/
               | /.*cool.dll.*/
               | /.*Admin.dll.*Admin.dll.*/
          &redef;
     }
     
     redef capture_filters +=  {
             ["http-request"] = "tcp dst port 80 or tcp dst port 8080
                                 or tcp dst port 8000"
     };
     
     # URIs that should not be considered sensitive if accessed remotely,
     # i.e. by a local client.
     const skip_remote_sensitive_URIs = /\/cgi-bin\/(phf|php\.cgi|test-cgi)/
      &redef;
     
     const sensitive_post_URIs = /wwwroot|WWWROOT/ &redef;
Unfortunately, there isn't any way of knowing exactly which one of these rules triggered the HTTP_SensitiveURL alarm. As will be seen in the next section, the triggering payload must be compared against this entire section.