|
Well this may not be exactly what you were expecting but we figured it might be nice to know a little bit about the unified file formats whilst this program continues to evolve and documentation to running it actually gets written.
Unified Format
The original unified file format actually came in two flavours, there was the Log unified format and the Alert unified format. The general overview of the file format can be seen in figure 1.
Figure 1 - Unified file format overview.
|
The file header structure contained a 32 bit integer, referred to as the "magic" number that defined what the unified log file contained. The number "0xdead1080" indicated that the file contained log data blocks whilst the number "0xdead4137" indicated alert data blocks.
After the file header comes an arbitrary number of data blocks, fixed in length, one after the other. This particular structure does have one benefit in that it's very easy to fast forward through a file to the n'th record. Knowing the length of the header and the size of each record allows one to fast forward to the n'th record simply with header_length + n * record_length. Noting that n = 0 is of course the first record.
It should be apparent that because the file format only supports one form of data block that programs parsing this information (eg. barnyard) require separate decoding plug-ins to distinguish the two.
Unified2 Format
As of Snort 2.8 we started to see the introduction of a new unified file format, unified2, the evolution of the original unified format. Actually the original unified format was also undergoing some minor changes but more on this shortly.
The new unified2 format was moving away from its single fixed sized record methodology and moving to an extensible frame based structure. The record data would be independent of the type. That is each record is preceded by a record header which essentially defines the type of record to follow and its length. This in turns provides ability to store other record types such as IPv6 alerts, performance stats and even extended portscan information into the same output file. This structure does make it a little trickier to fast forward through, in that each record header has to be read in turn to find to work out the length of the following record.
This structure style can also be seen in the ID3v2 tag format. Let's take a closer look at the structure of the unified2 file format.
Figure 2 - Unified2 file format overview.
|
Figure 2 illustrates how the data frames are structured within the file. Each data block is preceded by a data header which holds two pieces of information; the type of data block to follow, and the length of it. The types of data blocks currently available in the Snort 2.8 series are ALERT, EVENT and EVENT_IPV6. We are now seeing support for IPv6 logging. Even better still future enhancements include logging of portscan information and other extended information.
|
