Re: Barnyard, Mudpit, and the Unified Output Format

["Alex Butcher, ISC/ISYS" <Alex.Butcher () bristol ac uk>]

--On 24 August 2004 08:05 -0400 M Shirk <shirkdog_linux () hotmail com> wrote:

> I really have some questions about the Unified Output Format, and issues
> I have experienced.
>
> Using Barnyard 0.2, and Mudpit 1.3, I have been able to run snort using
> the Unified Output Format (UOF) output plug-in. I have the
> snort.log.192832 and snort.alert.192832 files in /var/log/snort.
>
> Quick digression:
> It takes intuition to install Mudpit, you have to customize the makefiles
> in the output/acid directory to have the correct location of the mysql
> header and library files. You also have to link directly to an object
> file that after you run "make install" will be in the source tree under
> output/acid. I will try to work on a mudpit how-to, and post it to the
> list.

I didn't need to do that here. Your mysql install is probably (partially) 
broken.

> Back to the story:
>
> After messing around, I am able to  input alerts into the MySQL database.
> However, the SIDS are not correct. I checked the mappings and both
> barnyard and mudpit were referencing the /etc/snort/*.map files and the
> classification file in the same directory. I am not sure if this is an
> issue when working with snort22, but only certain alerts would show up
> with the correct sid and name. All I was doing was telneting to port 80
> and doing a GET /../../cat/etc/passwd HTTP/1.1 and I also was nmaping to
> port 80 and 443.

Snort doesn't use the .map files. The .map and .config files should be 
rebuilt from the snort.conf/*.rules whenever those are modified. I've 
attached my mudpit init script and makemap.sh to show how I've done this.

Finally, Mudpit needs to stopped and restarted before Snort is started 
using the modified snort.conf/*.rules, otherwise there will be a mismatch 
between Snort and Mudpit.

Also, if you don't purge your snort database between changes, expect the 
events to get muddled up then also.

> Which brings me to a topic of discussion. Along with the issue above,
> there is no payload, no packet data. Now the reason to be running snort
> in this manner is to help with performance. But I was under the
> impression that snort will dump everything to the log file, including the
> payload in a binary format and then a separate process such as Barnyard
> or Mudpit will decode and input the payload into the MySQL database for
> use with ACID. I was mucking around with the output code for Mudpit and
> did find that there is a function for the data and data_payload. I just
> want to know if this is the true nature of the output plug-in; to allow
> snort to sniff at top speed, or if there is something wrong with my setup.

I emailed the list a while back about how tagging works in conjunction with 
unified logging and spool processors. Andrew Baker (barnyard author) wrote:

======
AJ Butcher, Information Systems and Computing wrote:
> What is the preferred mechanism for logging sessions in this manner?
>
> Do *any* of them even work when using unified or database logging? The
> Snort  2.1.x manual indicates that 'tag' doesn't work with database
> logging, and 'logto' doesn't work in binary mode. It says nothing about
> 'session'.

The unified output plugins definitely support the tag option.  When tagging 
is enabled, all of the tagged packets will be written to the unified log 
file.  Additionally, with recent versions of Snort, if an alert is 
triggered on a reassembled stream, then all of the packets for the stream 
will also be written to the unified log file.  While I cannot speak for 
mudpit, Barnyard will process the tagged packets.  However, how the are 
processed is up to the discretion of each output plug-in.  I do know that 
the ACID database output plugin in Barnyard does not treat tagged packets 
properly.  IIRC, each tagged packet will become a new event entry in the 
database instead of having all the packets associated with a single event. 
This is a limitation of the database design since it significantly predates 
tagged packet support.

-A
======

Mudpit appears to INSERT the tagged packets into the database, but they 
appear as duplicate alerts (which can be a bit confusing as the content 
that triggered the rule will probably only appear in one packet - and 
therefore one alert - from the session).

FLoP extends the schema in order to support full session logging, and 
provides a tool (getpacket) to retrieve the session in pcap format (e.g. 
for Ethereal to load). I haven't used this feature "for real", yet, though.

> Look forward to your comments.
> Shirkdog

HTH,
Alex.
--
Alex Butcher: Security & Integrity, Personal Computer Systems Group
Information Systems and Computing             GPG Key ID: F9B27DC9
GPG Fingerprint: D62A DD83 A0B8 D174 49C4 2849 832D 6C72 F9B2 7DC9

Attachment: makemap.sh
Description:

Attachment: mudpit.init
Description: