[Snort-devel] rfc for snort preprocessors architecture (draft)

Fyodor fygrave at ...1...
Wed Apr 4 07:08:20 EDT 2001

heh, let me try to push the ball on snort preprocessors design. This paper
is a very draft outline of proposed architecture. I am not certain of internal 
implementation yet, so I described only part of suggested API. Anyway any feedback
would be appreciated alot. (the piece also has been comitted into cvs docs module 
as well).


-/cut here/-
Document status:
$Id: draft-snort-preprocessors-01.txt,v 1.1 2001/04/04 10:57:22 fygrave Exp $
$Log: draft-snort-preprocessors-01.txt,v $
Revision 1.1  2001/04/04 10:57:22  fygrave
Snort preprocessors draft.


TITLE: On snort preprocessors
AUTHOR: Fyodor Yarochkin <fygrave at ...1...>
DATE: Tue Mar 27 19:41:31 ICT 2001
STATUS: draft


The purpose of this document is to introduce Snort 2.x preprocessors design.
Presently all preprocessors are being executed on the same 'priority level', with
no way to specify the right ordering of execution except for the preprocessor
rule appearance in the configuration file. Moreover with current architecture
it is not possible to specify preprocessor-matching rules outside of preprocessor
initialisation line (if any). With the suggested preprocessors architecture we
hope to solve this kind of problems.


The new preprocessors design supposes to have all preprocessors being separated
into preprocessors groups which would identify the 'priority level' at which
the preprocessor is supposed to be executed. Following five groups of preprocessors
are suggested:

1. Application (High-level protocol plugins (http/pop3/ftp etc)
2. Session     (underlying level protocol plugins (ssl, ssh, ...))
3. Transport   (tcp/udp protocol plugins)
4. Network     (IP/?? protocol plugins)
5. Datalink    (Ethernet/ARP/?? protocol plugins)

Preprocessor group with the higher number has the higher execution priority. Additionally
Sub-group priority level could be assigned to certain preprocessor to identify the preprocessor
priority within a group. (i.g. http_decode preprocessor might be forced to be executed before
http_session_match f.e.).

2. Preprocessor rules specification.

Following rules specification for preprocessors is suggested (very lousy for the moment, but something
to get started). XML rules model is being used for convinience:

<preprocessor ftp>
<priority=1> <!-- if omitted, assigned automagically>
<ports range="21,8081">

<pprule ftp>
        <login "ftp"> OR <login "anonymous">
    <alert msg="Anonymous login attempt" priority="blah" ...">

<pprule ip>
        <destination $HOME_NET> AND <smallfrags 20>
     <alert msg="Small fragments detected">


rem: module-load related API is omitted. Should probably be the same for all
DL modules.

pphandle_t *RegisterPreproc(char *ppword, int priority, int grouppriority);

Registers preprocessor with keyword 'ppword', priority level 'priority' and priority within
n group: 'grouppriority'. pphandle_t type handler is returned and should be operated later.

Priority could take one of the following values:


GroupPriority could have any number within signed int range assigned.

pphandle_t *RegisterPPInitParam(pphandle_t *handler, char *keyword, int (*parse_func)(char *));

Registers a function 'parse_func' which will be invoked to parse argument of keyword 'keyword'
from preprocessor initialisation block.

pphandle_t *RegisterPPRuleParam(pphandle_t *handler, char *keyword, int (*parse_func)(char *));

Registers a function 'parse_func' which will be invoked to parse argument of keyword 'keyword'
from preprocessor rule block.

pphandle_t *ChangePPriority(int newpriority, int newgrouppriority);

Changes preprocessor priority level.

int UnregPreproc(pphandle_t *handle);

Unregisters Preprocessor (for dynamic preprocessors reconfiguration. All structures related
to preprocessor will/should be deallocated by this moment).

More information about the Snort-devel mailing list