[Snort-users] Alerting unified or (fast) ASCII?
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
write 2 bytes out of the packet
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
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.
More information about the Snort-users