Friday, September 16, 2011

Snort 2.9.1 HTTP and SMTP logging features

To provide better context to the alerts generated by Snort, Snort version 2.9.1 introduced some new logging features for HTTP and SMTP which will help the user to better analyze the alerts. This logging of extra data by HTTP Inspect and SMTP preprocessors is similar to the X-Forwarded-For/True-Client-IP logging introduced prior to Snort 2.9.1.

HTTP Logging:
Let's talk about HTTP URI and Hostname logging.

How to enable logging of HTTP URI and Hostname?

To turn on the logging of the HTTP Request URI, the config option to use is "log_uri" and to enable the logging of hostnames, use the config option "log_hostname" as shown in the example below:

The memcap here will determine the maximum amount of memory the HTTP Inspect preprocessor will use for logging the URI and Hostname data. You can refer to the Snort Manual for further details.

When these features are turned on in HTTP Inspect, the HTTP Request URI and HTTP Request hostname headers are extracted and logged to unified2 as an "extra data event" with each alert generated for that particular session. It is recommended to turn on stream5 reassembly with PAF on HTTP ports to ensure correctness and accuracy.

When a HTTP Request URI is greater than 2048 or when a HTTP hostname (specified in the "Host" Request header) is greater than 256, Snort will log the truncated the URI and/or hostname. A preprocessor alert with GID:119 and SID:25 is generated when hostname exceeds 256 bytes.

There is also a preprocessor alert with GID:119 and SID:24 for multiple "Host" headers in one HTTP request.

Please note that the URI and hostname are only logged in Unified2 mode and not logged with -A cmg.

So, how do you read the output?

Unified2 can be read using the Snort tool u2spewfoo. You can find it under the tools/u2spewfoo directory in the Snort tarball.

In the output above, two extra data events are generated for the event with GID:1 and SID: 1. The first extra data event displays the URI and the second displays the hostname associated with that session.

It is important to note that the unique "event id" and "event second" are used to correlate the alerts with their extra data. The "event type" indicates the presence of an "extra data" record and the unique "type" will determine the type of the extra data event logged. Here is a list of extra data types used in Snort.

SMTP Logging:
The SMTP preprocessor, similar to HTTP Inspect preprocessor, can log extra data associated with each alert. The data that SMTP logs are as follows:

1. The email addresses in the MAIL FROM command.
2. The email addresses in the RCPT TO command. When there are multiple RCPT TO headers, the email addresses are concatenated using commas.
3. The filename of the MIME attachment extracted from the "Content-Disposition" header. Multiple filenames are appended with commas.
4. SMTP email headers.

How to enable logging of SMTP "extra data"?

SMTP preprocessor can log the extra data mentioned above using the following config options.

The config options "log_mailfrom", "log_rcptto", "log_filename" and "log_email_hdrs" do not take any arguments. However, email_hdrs_log_depth requires the user to pass a number between 0-20480, which will determine in bytes the amount of email headers logged. The config option "memcap" is used to determine the maximum memory used for logging the above mentioned data.

Again, stream5 reassembly needs to be turned on for SMTP ports for this feature to work correctly. Without stream5 reassembly, the SMTP extra data won't be logged.

How to read the Output?

Like HTTP extra data, SMTP extra data can be read using the u2spewfoo and "event id" and "event second" are used to correlate the alerts with their extra data events.

We will not be updating the spo_database output method to insert this information into the database. As a reminder, this output method will be removed in a future Snort release in 2012. Sourcefire has turned over the maintenance of the "ACID" database schema to the Barnyard2 group, and will also, no longer be maintaing it either.