What is Mudpit?

Background

The unified plugin allows Snort to write its alerts and logs into continuous binary files spending no time on binary->text conversions usually performed during alert/log generation process.

This feature has a potential to greatly improve Snort's performance/stability, especially if events are collected in a remote relational database.

The Problem

Snort has two separate output streams: alert and log. Alerts contain brief description of what's happened. Logs, on the other hand, provide full information about event, but usually are generated less often than alerts. There is no magic Snort parameter allowing one to get all the required information in one stream. With unified plugin you also get two streams; by ignoring one of them you will lose quality or quantity.

In general, Snort unified plugin can be configured to produce alert and log files simultaneously, but some events would be duplicated in both files having different level of details.

Existing Solutions

There are programs out there that can read and process files written in Snort's unified format. Most notable project with similar goals is Barnyard. To the best of our knowlegdge, none of the existing programs satisfies requirements for single complete source of output information suitable for event monitoring.

MudPit

Mudpit has been written to satisfy people's needs for the intelligent, modular and reliable processor for Snort's unified format.

The following Mudpit features make it exceptionally useful in Snort-based IDS devices hosted on Linux/UNIX:

Ability to process both alert and log files in parallel, choosing one that contains more information on a particular event.
Ability to independently handle outputs of more than one Snort processes on the same computer under separate permission sets.
Stability, including support for automatic recovery from network failures and outages with no information loss (checkpoints).
Modularity and ability to assign more than one output plugin to each spool processor.
A generic locking facility that allows separate spool processors to write to the same back-end database simultaneously.
"Start and forget" reliability.

Details

Mudpit utilizes well-known UNIX parent/child technique to achieve required reliability. Each child process works as a separate Snort spool processor. It reads an alert/log file pair in the specific spool directory and sends an event data to output plugins. Output plugins are implemented as UNIX shared modules and are dynamically loaded by each spool processor at initialization time. Each plugin should export the following set of functions:

int mp_out_init() [mandatory]: Called once during initialization. Configuration string(if any) given to this particular output plugin in the config file is provided as a parameter.
int mp_out_log() and/or int mp_out_alert() [at least one of them should be provided]: These functions are called when a new event becomes available. If both are exported and both alert and log data is available for a particular event, the log function is called.
mp_out_fini() [optional]: Called once during spool processor termination.

See mp_simple_out.c/Makefile for more details on output plugin implementation.

Important Note

In order for Mudpit to work correctly, Snort should have BOTH unified alert and unified log plugins active.

Supported Platforms

Currently, Linux RH7.3 is the only platform we used for testing. There should be no significant problems to compile/run Mudpit in any modern UNIX environment. Real problems await those who will try to port it to MSWin or MAC OSes v.X.

Contributors

Mudpit was originally written by Fidelis Security Systems