Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Snort-users] preprocessors

3 views
Skip to first unread message

Jonas Pfoh

unread,
Dec 16, 2009, 7:56:06 AM12/16/09
to
Hi,

I have a two questions to using preprocessors.

1. Do I understand correctly that preprocessors such as frag3 do some
preprocessing (in the case of frag3, assemble packets), then send them
along to the detection engine to be analyzed? Clearly it makes sense
that they do as they are called "preprocessors", but it brings me to my
next question...

2. Preprocessors like sfPortscan, seem to do less preprocessing and more
alerting...shouldn't this be the job of the detection engine? Is it
done in a preprocessor, because state is needed? When an alert is
triggered by the preprocessor, is/are the packet(s) still sent to the
detection engine?

Thanks for you help.

-Jonas

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Snort-users mailing list
Snort...@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

Todd Wease

unread,
Dec 17, 2009, 8:58:53 AM12/17/09
to
> 1) The preprocessors work in the order you have them in the config
> file. So first the frag3 engine cleans up layer 2 fragmentation. Then
> the stream engine handles the reassembly of IP segmentation. Then (for
> example) the http_inspect engine applies some intelligence to the data
> and sorts it into buffers that we can specifically look at in the
> detection engine. This way we can write rules that are faster and more
> accurate.

Preprocessors have a priority associated with them and will be run in
order of their priority. If the priority is the same, then the ordering
in which they are in snort.conf matters. The priorities are labelled as
such from highest priority to lowest:

#define PRIORITY_FIRST 0x0
#define PRIORITY_NETWORK 0x10
#define PRIORITY_TRANSPORT 0x100
#define PRIORITY_TUNNEL 0x105
#define PRIORITY_SCANNER 0x110
#define PRIORITY_APPLICATION 0x200
#define PRIORITY_LAST 0xffff


Also note that dynamic preprocessors are configured after non-dynamic
preprocessors, so for the same priority group, they will always be
evaluated after non-dynamic preprocessors.


The current priorities for the preprocessors are:

PRIORITY_NETWORK
----------------
frag3
arpspoof


PRIORITY_TRANSPORT
------------------
stream5


PRIORITY_TUNNEL
---------------
ssl


PRIORITY_SCANNER
----------------
sfportscan
perfmonitor


PRIORITY_APPLICATION
--------------------
httpinspect
rpc_decode

(dynamic preprocessors)
ssh
ftptelnet
dns
smtp
dcerpc2


PRIORITY_LAST
-------------
bo


Also, don't let the configuration output confuse you as to when the
preprocessor is actually run. They are configured, then inserted into a
list based on priority. The only time the configuration order matters
is if they are the same priority.

Richard Bejtlich

unread,
Dec 17, 2009, 7:27:09 PM12/17/09
to
On Thu, Dec 17, 2009 at 9:27 AM, Matt Olney <mol...@sourcefire.com> wrote:
> The Todd speaks!
> Thanks, I learned something (and need to update some slides).

This was quite possibly the most informative snort-users thread of
2009. Thanks everyone.

Richard

0 new messages