[Snort-users] Alerting unified or (fast) ASCII?

Matt Kettler mkettler at ...4108...
Wed Oct 20 10:36:38 EDT 2004


At 12:11 PM 10/20/2004, Edin Dizdarevic wrote:
>Allright, I assumed that isn't really that much work to do.
>Obviously the effort is far not negliable. :(

Let's look at a standard 16bit integer: 0x7fff

Binary mode:
         write 2 bytes out of the packet

Ascii mode:

         Allocate a buffer to hold the string (fast if stack allocated)

         Convert 2byte binary number to ascii-encoded decimal string 
"32767". This is generally done in a loop or using recursion with a series 
of modulo operations and subtractions. In this case 4 16-bit modulo's, 4 
16-bit subtractions, 5 8-bit additions (or bitwise OR operations) of 0x30, 
and 5 byte assignments. If you're slick you can reduce the 5 8 bit 
additions to 2 bitwise OR's (1 32bit wide 0x30303030, 1 8bit wide 0x30).

         write five bytes.

         Free the buffer (fast if stack allocated).

ASCII conversion isn't exactly the fastest operation in the world. In this 
case it's much nicer to defer it to a less time-critical point.

Of course, the whole BY part could be implemented as some kind of "Second 
thread" inside snort and get the same benefit, but that's overly 
complicated. It's simpler and cleaner in this case to just have two apps.

>Yes, but it consumes system ressources, memory and cpu cycles.
>Especially if more than one alert has been triggered by will try to
>process the previous entry during the same time another alert may occur.
>I'm not that good in programming but by's file access should be
>non-blocking otherwise it may hinder Snort. I suppose that is anyway the
>case.

Yes BY can read the file without blocking snort.. much the same way tail -f 
doesn't hinder syslog from writing to a logfile.

It's the classic 'One writer, One or more readers' type of file access. 
Very common.






More information about the Snort-users mailing list