Re: A complication with an unconventional use of Snort

[Leon Ward <leon.ward () sourcefire com>]

Hi

Have you thought about using Snort's unified output and then  
processing it with barnyard at a later date?

-Leon

On 19 Sep 2006, at 16:49, bahdko () erols com 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  
> memory.
>
> 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.
>
>
> Thanks,
>
> --Laura
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users



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 () sourcefire com

www.sourcefire.com
www.snort.org



-------------------------------------------------------------------------
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 cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users