[Snort-devel] snort_inline-1.9.1-2 release
pieter at ...1883...
Mon Mar 31 02:04:21 EST 2003
Sterling work on Snort_inline. Just a few questions if I may:
1. Are there any plans to support Snort 2.x and if so, when will that
2. Whenever I activate Snort_inling in bridging mode, then portscans
slow down to a trickle. Can you think of a reason for this other than
latency in the kernel vs. user space copying of packets?
3. Will the portscan preprocessor be integrated into snort_inline?( I
guess that is a bit of an oxymoron because you can only identify a
portscan by the number of packets that you have already let through in a
Lastly, I am interested in understanding the snort_inline code a bit
better. Is there any information or advice as to how I can do that?
Thanks in advanced.
On Sun, 2003-03-30 at 19:29, Rob McMillen wrote:
> The Honeynet Project has updated snort_inline to include preprocessor support.
> Any preprocessor that normalizes data can be used with snort_inline 1.9.1-2.
> The Honeynet Project is also currently porting pre-processors that actively
> alert (or drop) attacks. The snort_inline.conf file has been updated with these
> new capabilities. You can find src code, binaries, and updated configuration
> files at
> Why couldn't we use plugins before? To answer this question, we need to give a
> basic description of snort_inline.
> Basically, the kernel makes a copy of the packet and gives it to snort_inline.
> snort_inline then takes this copy of the packet; adds a pcap header, and sends
> it through the snort process. At the end of the process, snort_inline checks
> the packet routing decision: drop, sdrop, reject or accept (default if drop,
> sdrop, or reject are not set). When the packet is marked for drop, sdrop, or
> reject, snort_inline tells the kernel to drop the packet and disregard the copy
> of the packet it sent us earlier. When the packet is not marked for drop,
> sdrop, or reject, snort_inline tells (this is what was fixed) the kernel to
> accept the packet and use the copy of the packet we are not providing instead of
> the copy the kernel kept. The intent of this action was to allow the use of the
> "replace" keyword that lets users change the packet payload. For example,
> I can use the "content" keyword to find cmd.exe and use the "replace" keyword to
> change it to xxx.exe. This would render attacks using an exploit that used
> cmd.exe useless.
> Now, snort_inline tells the kernel to accept the packet and use the copy the
> kernel kept unless the payload was modified by the use of the replace keyword.
> Why is this important? This is important for two reasons:
> 1. It increases snort_inline throughput because we are no longer
> copying a packet from kernel space to user space; making a routing decision; and
> copying a packet from user space to kernel space. We are only doing this when
> it is absolutely necessary.
> 2. It allows the use of plugins that "normalize" (modify) the payload
> so the detection engine can better identify attacks in packets sent by "evil"
> people trying to hide by using things such as unicode to hide their intent.
> The way these plugins work in Snort-1.9.1 is that they modify the packet payload
> ("normalize") so that the rule base has a better shot at identifying an attack.
> Things such as unicode attacks are decoded by the http_decode preprocessor
> plugin before the packet is sent to the detection engine. This increases the
> chance of identifying the attack.
> Feel free to drop me a line if you have any problems/questions.
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
pieter at ...1883...
Tel: 01344 390530
DDI: 01344 390630/390631
Fax number: 01344 390700
Mobile: 0776 665 6924
TERMS AND CONDITIONS
(i)The information contained in this email and attachments is only
intended for the addressed recipient(s) and may not be distributed or
viewed by any other party without the explicit consent of the sender. If
you have received this message by accident, please contact Pieter
Claassen (pieter at ...1883...) and destroy any electronic or physical
copies of the information contained in it, immediately.
(ii)This email is not certified to be virus free and OpenAuth accepts no
liability for losses arising from you receiving this email.
(iii)Any digital signatures (if present) used to authenticate this
email, only serves to allow you to verify the originating email address
of the sender and should not be relied upon to prove identity or base
financial transactions on, unless the Certificate Practice Statement
that the signature references, explicitly states differently.
(iv)This email may be subjected to further terms and conditions as
published on the company website at http://www.openauth.co.uk. If you
need to rely on the information contained in this email in any way, then
you should read those terms and conditions to understand how much you
can trust the information in this email.
(v)OpenAuth retains the copyright on any relevant material that is
included in this email.
More information about the Snort-devel