[Snort-devel] Snort full log files need heirarchy

Bit Stream bitstream01 at ...445...
Sat Mar 23 08:57:01 EST 2002

>From: James Hoagland <hoagland at ...60...>
>>I'd propose that for the next version of snort, that you create a
>>directory heirarchy.  Where IP becomes $LOGDIR/1/2/3/4/ when
>>snort is running in full log mode.  This would solve a lot of
>>problems by limiting the total number of directories in any
>>directory to 255.  Perhaps it is problematic performance wise, but
>>real performance oriented people shouldn't be running in full log
>>mode in real-time anyway.
>This might be a good idea.  It is not a particularly good idea to let
>the attacker control your performance.  Especially if they can push
>it over a file system limit.  (Although, of course, they can control
>how many alerts you get.)  I would suggest this as an option though,
>to preserve backwards compatibility.

Let me reinforce a point that I thought I made.  I'm talking about doing 
this expansion out of band (relative to the snort collection).  That is, I 
am planning to run the collector then postprocess the log file to a more 
useful form for analysis.  In this sense, yes, allowing an attacker to 
control performance is a bad thing, on the other hand, it's out of band, so 
it's not necessarily critical.  As for time spent by the collector recording 
all the data, there is a performance implication there, but I suspect we 
could spend many days and beers arguing about the value of different rules.  
This is why most IDS vendors are trying to find ways to make the number of 
rules v. packet processing time a low-order equation.

>SnortSnarf used to place all its files in one directory too.  But
>now, it stores it in heirarchical directories for reasons like you
>describe.  The pages corresponding to IP files are in nested
>directories named after the first 3 bytes of the IP address.  I could
>see why you might use 4 bytes here though.

I actually contemplated 2 bytes and decided that was too little and never 
contemplated stopping at 3.  Brian wrote to me separately and discusssed 
inode depletion, which could be an issue, but at least inodes are a function 
of mkfs and disk size, where as files-per-dir is static per OS.

I could code this in myself, and am willing to do the development work and 
submit it if people other than me think it's a good idea (and there isn't a 
consensus that it's a bad idea). Since I haven't tracked snort development 
for all that long, I also wanted to make sure it wasn't being done by 
someone already.


Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

More information about the Snort-devel mailing list