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'' (§
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.
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 %10596That 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).
The standard HTTP script defines one event handler:
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.