[Snort-devel] Snort full log files need heirarchy
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 126.96.36.199 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
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
More information about the Snort-devel