- Use the Source, Luke
Home | Register | News | Forums | Guide | MyLinks | Bookmark

Sponsored Links

Latest News
  General News
  Press Releases
  Off Topic

Back to files

mudpit vesion 1.5

Original Author: G Savchuk, Fidelis Security Systems, Inc. <>
Current Maintainer: J Le Plastrier,, Inc. <>

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

See file LICENSE for details.

Mudpit - intelligent spool processor for Snort's 'Unified' files.


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.


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.

Understandably, our intention was to 'reassemble' the complete set of information produced by snort, sequentially and without duplications, at the same time having an ability to discard unnecessary details later in the process, if desired.


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 our requirements for single complete source of output information suitable for event monitoring.


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

The following Mudpit features make it exceptionally useful:

  • 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.


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 output/simple/mp_simple_out.c and Makefile for more details about output plugin implementation.


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


Currently, Linux RH 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<10.


Command line parameters:
-c <config file> Specifies the name of the configuration file.

Default is /etc/ Only absolute filename is accepted here.

-v [-v [-v]]      Increases verbosity level.
-D|--daemon       Daemon mode.
--once            Process each spool once, then exit.
-h/--help         Prints this help message

Configuration file format:

# Global parameters:

global {
# Turn on daemon mode (same as -D )
# mudpit would not become a daemon if verbosity level > 0. # Default - not a daemon.
# Conflicts with: verbose.

# Verbosity level (the same as the appropriate number of "-v" args) # Default: 0
# Conflicts with: daemon
verbose = 4

# The following are text files that contain important # event-related information. All of them come with Snort # distribution; see for details. # If not absolute, filenames are relative to the directory # containing the main configuration file (see -c parameter). # They are all assigned to their respective default values. # Values assigned here are considered global for all spools # but can be overridden on a per spool basis. class_file = "classification.config"
sid_file = ""
gen_file = ""
ref_file = "reference.config"

# Pid file is used in daemon mode only. # Default: "/var/run/"
pid_file = "/var/run/"

# Nice: changes priority for each spool processor. # see man renice(8) for more details.
# The main process is unaffected.
# Default is 0
nice = 5

# run_once: mudpit processes new data,
# then exits without waiting for incoming data. # default: false

# Spool configurarion. One or more spools should be configured. # Spool definition contains the absolute path to a spool directory # (that is, the directory containing Snort's log/alert file pair) # and parameters for the spool processor. spool "/snort/spool" {

# the name of a lock resource for this spool. Spool processor will try # to obtain exclusive lock on this resource each time before it attempts # to send data to output plugins. Alphanumeric symbols and '_' are allowed # in the resource's name.
# Default: none (no locking)
lock = "mysql"

# Spool processor will delete Snort output file each time the newer # file becomes available
# Default: don't delete

# The following are text files that contain important # event-related information. All of them come with Snort # distribution; see for details. # If not absolute, filenames are relative to the directory # containing the main configuration file (see -c parameter) # They are all assigned to their respective default values. # Values assigned here are applied only to this spool and # override any values assigned globally. class_file = "/usr/local/etc/snort/spool1/classification.config" sid_file = "/usr/local/etc/snort/spool1/" gen_file = "/usr/local/etc/snort/spool1/" ref_file = "/usr/local/etc/snort/spool1/reference.config"

# Copy Snort output file to the specified directory when it's processed. # If 'delete_processed' was specified, processed file will be moved from # the spool directory to the arch directory. Absolute path is required. arch_dir= "/snort/arch"

# Set euid/uid and egid/gid of the current spool processor to those of # the given user and his primary group. Works only if Mudpit is started # as a root process.
# Default: euid/uid and egid/gid are not changed. user = "snort"

# Specifies the name of the checkpoint file. # Default: "checkpoint"
checkpoint = "checkpoint"

# The name of the output plugin. At least one plugin must be specified. # The string after comma is a parameter sent to the plugin; its format # depends on a plugin type (mp_out_init entry should understand it). # Default: none.
output = "/snort/",
"server alisa, user snort, database snort, hostname TEST, interface eth1" }

Sponsored Links

Discussion Groups
  Networking / Security

About | FAQ | Privacy | Awards | Contact
Comments to the webmaster are welcome.
Copyright 2006 All rights reserved.