Next: The ident Analyzer Up: Analyzers and Events Previous: The ftp Analyzer Contents Index
Subsections

- `http` variables
- `http` event handlers

#
The `http` Analyzer

The `http` analyzer processes traffic associated with the Hyper Text Transfer Protocol (HTTP) [RFC1945,RFC2616], the main protocol used by the Web. Bro instantiates an `http` analyzer for any connection with service port `80/tcp`, providing you have loaded the `http` analyzer, or defined a handler for `http_request`. It also instantiates an analyzer for service ports `8080/tcp` and `8000/tcp`, as these are often also used for Web servers.

The analyzer uses a capture filter of ```tcp dst port 80 or tcp dst port 8080 or tcp dst port 8000`'' (§ ). Note: This filter excludes traffic sent by an HTTP server (that would be matched by `tcp src port 80`, etc.), because Deficiency: Bro doesn't yet have an analyzer for HTTP replies. It generates summaries of HTTP sessions (connections between the same client and server) and looks for access to sensitive URIs (effectively, URLs).

##
`http` variables

  [``sensitive_URIs : pattern``] Any HTTP method (e.g., `GET`, `HEAD`, `POST`) specifying a URI that matches this pattern is flagged as sensitive.

  Default: URIs with `/etc/passwd` or `/etc/shadow` embedded in them, or `/cfdocs/expeval` (used in some Cold Fusion exploits). Note: This latter generates some false hits; it's mainly included just to convey the notion of looking for direct attacks rather than attacks used to exploit sensitive files like the first ones.

  Deficiency: It would be very handy to have variables providing hooks for more context when considering whether a particular access is sensitive, such as whether the request was inbound or outbound.

  [``sensitive_post_URIs : pattern``] Any `POST` method specifying a URI that matches this pattern is flagged as sensitive.

  Default: URIs with `wwwroot` embedded in them.

Figure 7.8: Example of HTTP log file entries for a single HTTP session.

In addition, `http_log` holds the name of the HTTP log file to which Bro writes HTTP session summaries. It defaults to `open_log_file("http")`.

Figure 7.17.1 shows an example of what entries in this file look like. Here we see a transcript of the 1596th HTTP session seen since Bro started running. The first line gives its start time and the participating hosts. The next five lines all correspond to `GET` methods retrieving different items from the Web server. Deficiency: Bro can't log whether the retrievals succeeded or failed because it doesn't yet have an HTTP reply analyzer.

The corresponding lines in the `red` file look like:

        972482762.872695 481.551 http 441 5040 131.243.2.12 200.241.229.80
            S3 X %10596
        972482764.686470 18.7611 http 596 7712 131.243.2.12 200.241.229.80
            S3 X %10596
        972482764.685047 ? http 603 2959 131.243.2.12 200.241.229.80
            S1 X %10596

That there are three rather than five reflects (i) that the client used persistent HTTP, and so didn't need one connection per item, but also (ii) the client used three parallel connections (the maximum the standard allows is only two) to fetch the items more quickly. As with FTP sessions, the `%10596` `addl` annotation lets you correlate the `red` entries with the `http` log entries.

Note: All three of the connections wound up in unusual states. The first two are in state `S3`, which, as indicated by Table 7.3.6 means that the responder (in this case, the Web server) attempted to close the connection, but their was no reply from the originator. The last is in state `S1`, indicating that neither side attempted to close the connection (which is why no duration is listed for the connection).

##
`http` event handlers

The standard HTTP script defines one event handler:

  [``http_request (c: connection, request: string, URI: string)``] Invoked whenever the client side of the given connection generates an HTTP request. `request` gives the HTTP method and `URI` the associated resource. The analyzer matches the URI against the ones defined as sensitive, as given above.

Deficiency: As mentioned above, the event engine does not currently generate an `http_reply` event. This is for two reasons: first, the HTTP request stream is much lower volume than the HTTP reply stream, and I was interested in the degree to which Bro could get away without analyzing the higher volume stream. (Of course, this argument is shallow, since one could control whether or not Bro should analyze HTTP replies by deciding whether or not to define an `http_reply` handler.) Second, matching HTTP replies in their full generality involves a lot of work, because the HTTP standard allows replies to be delimited in a number of ways. That said, most of the work for implementing `http_reply` is already done in the event engine, but it is missing testing and debugging.

Next: The ident Analyzer Up: Analyzers and Events Previous: The ftp Analyzer Contents Index