["Joe Patterson" <jpatterson@xxxxxxxxxxxxxxx>]

> > The second, which I'm wondering if it's usefull at all, is a parser for
> > snort's unified output file format.  this format is *almost* identical
> > to
> > libpcap, but has extra data added to each frame (stuff like which
> > snort rule
> > caused this particular packet to get tagged).  Now, it's probably
> > fairly
> > trivial to write something to read in these files and display the
> > standard
> > information.
>
> Assuming they didn't do somethng stooopid such as using a standard
> libpcap magic number, or not having any magic number at all, it should
> be fairly easy to add to the existing wiretap/libpcap.c the ability to
> read those files.

It has its own magic number, I believe (unless #define UNIFIED_MAGIC
0x2dac5ceb looks familiar to anyone...)

The log file starts with a header similar to a pcap header (but I believe
somewhat different).  It starts with a struct *quite* similar to:

------------------------------------------------------------
typedef struct _UnifiedLogFileHeader
{
    u_int32_t magic;
    u_int16_t version_major;
    u_int16_t version_minor;
    u_int32_t timezone;
    u_int32_t sigfigs;
    u_int32_t snaplen;
    u_int32_t linktype;
} UnifiedLogFileHeader;
------------------------------------------------------------

Which is in turn followed by a bunch of UnifiedLog structs quite like:

------------------------------------------------------------
typedef struct _UnifiedLog
{
    Event event;
    u_int32_t flags;       /* bitmap for interesting flags */
    SnortPktHeader pkth;   /* SnortPktHeader schtuff */
} UnifiedLog;


typedef struct _Event
{
    u_int32_t sig_generator;   /* which part of snort generated the alert?
*/
    u_int32_t sig_id;          /* sig id for this generator */
    u_int32_t sig_rev;         /* sig revision for this id */
    u_int32_t classification;  /* event classification */
    u_int32_t priority;        /* event priority */
    u_int32_t event_id;        /* event ID */
    u_int32_t event_reference; /* reference to other events that have gone
off,
                                * such as in the case of tagged packets...
                                */
    struct timeval ref_time;   /* reference time for the event reference */
} Event;

typedef struct _SnortPktHeader
{
    struct timeval ts;     /* packet timestamp */
    u_int32_t caplen;      /* packet capture length */
    u_int32_t pktlen;      /* packet "real" length */
} SnortPktHeader;
------------------------------------------------------------

Now, this looks to me like it should be *reasonably* easy to unravel (i.e.,
I've done it with a hex dump of a unified file, and all the fields lined up
like I expected), but then again, I suck at coding, so that's why I'm asking
folks here what they think.

>
> >   It's also fairly unecessary, as there are tools to "extract" a
> > libpcap-formatted file from a snort unified output file.  However, if
> > there
> > were a way to get ethereal to actually do something usefull with the
> > extra
> > data (i.e., parse it out and show it in the protocol tree with the
> > other
> > frame meta-information such as time, time_delta, time_relative, number,
> > pkt_len and cap_len),
>
> That could probably be done without too much pain, although, without a
> description of the file format, I don't know what I'd recommend as the
> way to do it.

Most of the stuff in the code snippets above seems fairly well commented,
the only thing that might be a bit over-the-top would be to have a reference
to external files which contained mappings from sig_generator/sig_id/sig_rev
to something more human-readable.  But for me, the ability to open up a
unified file un-mangled directly in ethereal would be incredibly nice, and
the ability to write a filter like "frame.snort_sig_generator != 1" would be
absolutely heavenly.

-Joe