[Snort-users] A complication with an unconventional use of Snort
leon.ward at ...1935...
Tue Sep 19 12:06:33 EDT 2006
Have you thought about using Snort's unified output and then
processing it with barnyard at a later date?
On 19 Sep 2006, at 16:49, bahdko at ...71... wrote:
> I have snort sensors deployed in an uncommon scenario, and I'm
> having a complication I'm hoping someone could give me input on.
> The first part of the process does not experience problems.
> The data from the LAN is first gathered by a snort process that is
> run that just creates a binary file. The snort program that does
> this is started like so:
> /usr/local/bin/snort -l /var/log/snort -bD -i eth1
> This process results in a binary log file named something similar
> to snort.log.1126876613.
> Then, when the Snort program has been restarted and the binary log
> file is closed, the second part of the process is as follows.
> I use another instance of Snort to read this binary log file and re-
> log it into a fully-expanded ASCII format. An example command I use
> to do this is as follows:
> /usr/local/bin/snort -dvCeq -K ascii -r /var/log/snort/snort.log.
> 1126876613 net 192.168.10.0/24 -D -l /var/log/asciilogs/
> The result of this operation is that there are directories within /
> var/log/asciilogs that contain all of the packet information, in
> ASCII, from the binary file.
> My problem is this:
> During this second instance of Snort, Snort appears to take the
> entire binary log file, no matter how big it is, and steadily read
> the whole thing into memory as it processes it. I can watch in
> "top" as the memory and swap available on the machine are steadily
> sucked away until the amount of memory displacing the binary file
> size are represented, and then the process ends and frees up the
> Does Snort really have to do it this way and take all of that
> memory? I know that Snort is processing this file sequentially,
> more or less packet-by-packet, it would seem that it shouldn't be
> necessary to hold the entire file in memory the whole time.
> I periodically have some binary log files that exceed the swap
> +memory of my sensor, and I can't process those because of the way
> Snort is doing this.
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
Leon Ward CISSP, SFCE
Security Engineer UK
Sourcefire (The originators of Snort)
400 Thames Valley Park Drive,
Thames Valley Park
Reading, RG6 1PT, United Kingdom
Tel: +44 (0) 1189 653 555
Mob: +44 (0) 7818 067 304
Fax: +44 (0) 1189 653 554
leon.ward at ...1935...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users