Snort

Alan,

First off, let me make sure I'm correctly understanding your goal. Are you
trying to set an option while defining a rule, which will then get passed to
your output plugin when that rule alerts?

The following inline comments are based on that assumption. Please correct
me if I'm wrong.

On Wed, May 27, 2009 at 10:45 PM, Alan M. Carroll <
amc@...> wrote:

> I am working on an output plugin for Snort 2.8.4 and it would be handy to
> have access to metadata. However, looking at the code it appears that rule
> metadata that is not used by Snort is discarded and not available.


The "metadata" keyword is good for setting options in an OptTreeNode. The
metadata string gets discarded at this point because it has already been
parsed, and the values in otn->sigInfo have been filled out.

>
> One approach would be to use some other parser logic to read the rule file,
> extract the metadata, and then use signature identifiers to match up but
> that seems a bit redundant, especially for something that is compiled in to
> Snort, whose parser already fully parses the metadata.


That's definitely redundant.

>
> My current plan is to augment ParseMetadata to have a list of name/function
> pairs. After checking the known metadata keys, if unmatched it would
> traverse the list comparing the key to the strings. Upon a match, the
> corresponding function would be called and passed the OptTreeNode, the key,
> and the value (all of which are in local variables by this point). Then I
> would add a "RegisterMetadataHandler" function to allow plugins to populate
> the list.


If you want to add more metadata key/value types, take a look at the
#defines in the top of parser.c. You'll see a bunch named
"METADATA_KEY__FOO" or "METADATA_VALUE__FOO". Then, in the function
ParseOtnMetadata, add more cases to the if/else block and call whatever
function you want. I don't think it's necessary to keep a separate list of
key/value pairs, nor is it necessary to provide a "RegisterMetadataHandler".

>
> I am left with three questions:
>
> 1) Is this a reasonable approach?


That's hard for me to determine without knowing what your ultimate goal is
here. I would venture that whatever you're trying to do, there's probably a
cleaner way than repurposing the pre-existing "metadata" field. If you're
going to modify Snort, you might as well go whole hog and add your own
option type.

>
> 2) Would anyone else be interested in it, i.e. should I plan on making it
> robust enough for others to use?


> 3) How should my plugin interact safely with the ds_list member of
> OptTreeNode? Presumably it needs to get a globally unique index, but how is
> that done?


There's an enumerated type in plugin_enum.h.  Add your index in there,
before PLUGIN_MAX.

>
>
> Thanks!


No problem! I'm really happy to get email from people that have obviously
done their homework.

-Ryan

At 11:02 AM 5/28/2009, Ryan Jordan wrote:
>Alan,
>
>First off, let me make sure I'm correctly understanding your goal. Are you trying to set an option while defining a rule, which will then get passed to your output plugin when that rule alerts?

Yes.  The output plugin is part of another system which needs to take action when a rule triggers, but that action depends on the specific rule that triggered. Basically I want to attach a metadata key/value that specifies the action of the system. E.g., in the rule I would add "metadata:my_action 12" to perform action 12 when the rule triggers. The amount of action data is small (two u_int32_t values) and having it with the rule in the Snort configuration file rather than somewhere else makes maintenance so much easier.

>The "metadata" keyword is good for setting options in an OptTreeNode. The metadata string gets discarded at this point because it has already been parsed, and the values in otn->sigInfo have been filled out.

Yes, but anything that doesn't have a field already defined in SigInfo is completely discarded as far as I can tell.

I realize that my approach is significantly more general than absolutely required. However, one of my project goals is to minimize the amount of code changes in Snort both at the start and during maintenance. As much as possible I want my code to be in my plugin. The primary advantage of the approach I have selected is that it is a rather small, one time change to the Snort code base. Future changes the format, content, and number of metadata key/values would require no further changes to Snort itself, only to the plugin. It would also mean that other plugins could use the same system without code changes to Snort, or their implementors having to understand Snort internal details quite so intimately. This also makes ongoing maintenance of the changes for future Snort releases is minimized because the changes are minimized. Further a general mechanism has some chance of adoption in to the Snort codebase, whereas code specific to my project does not.

For these reasons I strongly prefer a solution that provides a general hook in to metadata parsing, rather than direct changes to support my project.

>That's hard for me to determine without knowing what your ultimate goal is here. I would venture that whatever you're trying to do, there's probably a cleaner way than repurposing the pre-existing "metadata" field. 

I don't this as repurposing. It seems natural to me that if rules have metadata, then it's the place to put rule specific data. In fact, when I first read the Snort manual and saw that, I assumed this machinery was already in place and the Snort specific keys just the equivalent of reserved words. I was surprised to find that non-recognized metadata was discarded and not at a minimum stored in key/value pairs in the rule node.

After all, if one wants rule specific data, then one must either put it in the Snort configuration file with the rule, or maintain a mapping based on signature identifiers between rules and rule related data. Clearly, the more complex the related data, the relatively less the overhead of maintaining the mapping. But in our case the amount of data is tiny and synchronization is a large overhead. I think this tweak will, in the long run, prove to be less of a maintenance headache. It is definitely a judgement call, but that's why I get the big bucks.

Thanks for the feedback.

I have my output plugin working now along with the rule metadata hook.  If you've ever wanted to be able to do output overrides on specific rules, it works very nicely for that purpose.

I have just a couple of questions left.

1) What is the difference between Restart and CleanExit? I can't find any documentation that elucidates the distinction and a sampling of existing output plugins yields the uniform result that both of these are implemented with identical code. Is this just an artifact from earlier versions of Snort?

2) How or should memory allocated and placed in OpTreeNode.ds_list be cleaned up? Currently when the plugin sees its metadata, it allocates a struct and stuffs it in the ds_list. But that memory is never released. Is that a problem?

Thanks!

Hi all!
ok, now i have 2 segfaults. One happens when i have shellcode.rules 
included in conf, and bt:
#0  0x00007f57c2ceffe5 in strcasecmp () from /lib/libc.so.6
#1  0x0000000000430f31 in ClassTypeLookupByType (type=0x1c2e070 
"shellcode-detect") at signature.c:561
#2  0x0000000000430e35 in ParseClassType (classtype=0x1c2e070 
"shellcode-detect", otn=0x1c2d5e0) at signature.c:521
#3  0x0000000000418295 in ParseRuleOptions (
    rule=0x1c2ceb0 "drop tcp $EXTERNAL_NET any -> $HOME_NET 22 
(msg:\"EXPLOIT ssh CRC32 overflow /bin/sh\"; flow:to_server,established; 
content:\"/bin/sh\"; metadata:policy balanced-ips drop, policy 
security-ips drop; refere"..., rule_type=14, protocol=6) at parser.c:3752
#4  0x0000000000415e6f in ParseRule (rule_file=0x1c21300,
    prule=0x1dc6230 "drop tcp $EXTERNAL_NET any -> $HOME_NET 22 
(msg:\"EXPLOIT ssh CRC32 overflow /bin/sh\"; flow:to_server,established; 
content:\"/bin/sh\"; metadata:policy balanced-ips drop, policy 
security-ips drop; refere"..., inclevel=1, parse_rule_lines=1) at 
parser.c:2298
#5  0x0000000000413a8a in ParseRulesFile (file=0x1c94ae0 
"/etc/snort/rules/exploit.rules", inclevel=1, parse_rule_lines=1) at 
parser.c:769
#6  0x00000000004151f0 in ParseRule (rule_file=0x1c20f70, 
prule=0x1c24ea0 "include $RULE_PATH/exploit.rules", inclevel=0, 
parse_rule_lines=1)
    at parser.c:1831
#7  0x0000000000413a59 in ParseRulesFile (file=0x1bffb40 
"/etc/snort/snort.conf", inclevel=0, parse_rule_lines=1) at parser.c:767
#8  0x0000000000422d28 in SnortMain (argc=10, argv=0x7fffcc112358) at 
snort.c:953
#9  0x00000000004224aa in main (argc=10, argv=0x7fffcc112358) at snort.c:409
Other fault is when i have commented out shellcode.rule in snort.conf:
#0  0x00007f589f2f81ab in ?? () from /lib/libc.so.6
#1  0x00007f589f2faade in ?? () from /lib/libc.so.6
#2  0x00007f589f2fc26f in calloc () from /lib/libc.so.6
#3  0x000000000042c4e4 in SnortAlloc (size=65535) at util.c:2377
#4  0x00000000004130e8 in ParseRulesFile (file=0x1b23b40 
"/etc/snort/snort.conf", inclevel=0, parse_rule_lines=1) at parser.c:433
#5  0x0000000000422d28 in SnortMain (argc=10, argv=0x7fffa8724968) at 
snort.c:953
#6  0x00000000004224aa in main (argc=10, argv=0x7fffa8724968) at snort.c:409
Also i've attached bt full output for both cases.
Yes, it's correct about inline patch. This is my configure options from 
gentoo portage:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu 
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
--localstatedir=/var/lib --libdir=/usr/lib64 --without-oracle 
--with-postgresql --without-mysql --without-odbc --disable-ipfw 
--disable-profile --disable-ppm-test --enable-debug 
--disable-memory-cleanup --disable-decoder-preprocessor-rules 
--enable-targetbased --disable-timestats --disable-ppm 
--disable-perfprofiling --enable-linux-smp-stats 
--disable-inline-init-failopen --disable-aruba --disable-gre 
--disable-mpls --disable-static --enable-shared --enable-react 
--disable-flexresp2 --enable-dynamicplugin --enable-pthread 
--with-libipq-includes=/usr/include/libipq --enable-inline 
--disable-prelude --disable-ipv6
I disable some flags like --enable-flexresp2 and --enable-gre, but 
nothing happens with segfaults.
Rules i get with oinkmaster from official site - 
http://www.snort.org/pub-bin/oinkmaster.cgi/<code>/snortrules-snapshot-CURRENT.tar.gz.
I'm ready to provide any info you needed! And sorry, english is my 
foreign language.

-------------------------------------
Dmitriy Loktev
Gigzbyte Security Group

Hi all!
ok, now i have 2 segfaults. One happens when i have shellcode.rules
included in conf, and bt:
#0  0x00007f57c2ceffe5 in strcasecmp () from /lib/libc.so.6
#1  0x0000000000430f31 in ClassTypeLookupByType (type=0x1c2e070
"shellcode-detect") at signature.c:561
#2  0x0000000000430e35 in ParseClassType (classtype=0x1c2e070
"shellcode-detect", otn=0x1c2d5e0) at signature.c:521
#3  0x0000000000418295 in ParseRuleOptions (
    rule=0x1c2ceb0 "drop tcp $EXTERNAL_NET any -> $HOME_NET 22
(msg:\"EXPLOIT ssh CRC32 overflow /bin/sh\"; flow:to_server,established;
content:\"/bin/sh\"; metadata:policy balanced-ips drop, policy
security-ips drop; refere"..., rule_type=14, protocol=6) at parser.c:3752
#4  0x0000000000415e6f in ParseRule (rule_file=0x1c21300,
    prule=0x1dc6230 "drop tcp $EXTERNAL_NET any -> $HOME_NET 22
(msg:\"EXPLOIT ssh CRC32 overflow /bin/sh\"; flow:to_server,established;
content:\"/bin/sh\"; metadata:policy balanced-ips drop, policy
security-ips drop; refere"..., inclevel=1, parse_rule_lines=1) at
parser.c:2298
#5  0x0000000000413a8a in ParseRulesFile (file=0x1c94ae0
"/etc/snort/rules/exploit.rules", inclevel=1, parse_rule_lines=1) at
parser.c:769
#6  0x00000000004151f0 in ParseRule (rule_file=0x1c20f70,
prule=0x1c24ea0 "include $RULE_PATH/exploit.rules", inclevel=0,
parse_rule_lines=1)
    at parser.c:1831
#7  0x0000000000413a59 in ParseRulesFile (file=0x1bffb40
"/etc/snort/snort.conf", inclevel=0, parse_rule_lines=1) at parser.c:767
#8  0x0000000000422d28 in SnortMain (argc=10, argv=0x7fffcc112358) at
snort.c:953
#9  0x00000000004224aa in main (argc=10, argv=0x7fffcc112358) at snort.c:409
Other fault is when i have commented out shellcode.rule in snort.conf:
#0  0x00007f589f2f81ab in ?? () from /lib/libc.so.6
#1  0x00007f589f2faade in ?? () from /lib/libc.so.6
#2  0x00007f589f2fc26f in calloc () from /lib/libc.so.6
#3  0x000000000042c4e4 in SnortAlloc (size=65535) at util.c:2377
#4  0x00000000004130e8 in ParseRulesFile (file=0x1b23b40
"/etc/snort/snort.conf", inclevel=0, parse_rule_lines=1) at parser.c:433
#5  0x0000000000422d28 in SnortMain (argc=10, argv=0x7fffa8724968) at
snort.c:953
#6  0x00000000004224aa in main (argc=10, argv=0x7fffa8724968) at snort.c:409
Also i've attached bt full output for both cases.
Yes, it's correct about inline patch. This is my configure options from
gentoo portage:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib64 --without-oracle
--with-postgresql --without-mysql --without-odbc --disable-ipfw
--disable-profile --disable-ppm-test --enable-debug
--disable-memory-cleanup --disable-decoder-preprocessor-rules
--enable-targetbased --disable-timestats --disable-ppm
--disable-perfprofiling --enable-linux-smp-stats
--disable-inline-init-failopen --disable-aruba --disable-gre
--disable-mpls --disable-static --enable-shared --enable-react
--disable-flexresp2 --enable-dynamicplugin --enable-pthread
--with-libipq-includes=/usr/include/libipq --enable-inline
--disable-prelude --disable-ipv6
I disable some flags like --enable-flexresp2 and --enable-gre, but
nothing happens with segfaults.
Rules i get with oinkmaster from official site -
http://www.snort.org/pub-bin/oinkmaster.cgi/<code>/snortrules-snapshot-CURRENT.tar.gz.
I'm ready to provide any info you needed! And sorry, english is my
foreign language.

-------------------------------------
Dmitriy Loktev
Gigzbyte Security Group

Hi,
First, Congratulations SF team for this new version!
Im found a segfault with this new version with this rule:
  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault"; content:"test"; within:; nocase; sid:987654321; rev:1;)
Yes, within keyword don't have value! and snort crash with nocasei keyword...
look my very simple snort.conf:
  dynamicpreprocessor directory dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
and sid 987654321 of course!

Please add my pseudo to Credits file and my company: Crusoe Researches.
Happy Detect (snort,bro,azwalaro)
Regards
Rmkml
Crusoe-Researches.com


On Thu, 14 May 2009, Snort Releases wrote:

> A beta version of Snort 2.8.5 is now available on snort.org, at
> http://www.snort.org/dl/
>
> Snort 2.8.5 introduces:
>
> - Ability to specify multiple configurations (snort.conf and everything
>  it includes), bound either by Vlan ID or IP Address.  This allows you
>  to run one instance of Snort with multiple snort.conf, rather than
>  having separate processes.
>
> - Continued inspection of traffic while reloading a configuration.
>  Add --enable-reload option to your configure script prior to building.
>
> - Rate Based Attack prevention for Connection Attempts, Concurrent
>  Connections, and improved rule/event filtering.  See README.filters
>  for details.
>
> - SSH preprocessor (no longer experimental)
>
> - Performance improvements in various places
>
> Please see the Release Notes and ChangeLog for more details.
>
> Please submit bugs, questions, and feedback to snort-beta@....
>
> Happy Snorting!
> The Snort Release Team

Thanks for the report rmkml.  Snort is crashing because the function
that parses the within keyword is not checking for NULL arguments and
then dereferencing a NULL pointer.  As long as you supply a value to the
within keyword this shouldn't happen.  We'll open a bug for this since
Snort shouldn't segfault but fail gracefully.  The reason 2.8.4 doesn't
segfault is because and empty string was being passed in instead of NULL
and the code wasn't checking the argument for no value and the within
was being set to 0 via a strtol call which we probably should have been
checking start_ptr == end_ptr and fail since no digits were actually
converted.


rmkml wrote:
> Hi,
> First, Congratulations SF team for this new version!
> Im found a segfault with this new version with this rule:
>  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault";
> content:"test"; within:; nocase; sid:987654321; rev:1;)
> Yes, within keyword don't have value! and snort crash with nocasei
> keyword...
> look my very simple snort.conf:
>  dynamicpreprocessor directory
> dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
>  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
>  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
> and sid 987654321 of course!
>
> Please add my pseudo to Credits file and my company: Crusoe Researches.
> Happy Detect (snort,bro,azwalaro)
> Regards
> Rmkml
> Crusoe-Researches.com
>
>
> On Thu, 14 May 2009, Snort Releases wrote:
>
>> A beta version of Snort 2.8.5 is now available on snort.org, at
>> http://www.snort.org/dl/
>>
>> Snort 2.8.5 introduces:
>>
>> - Ability to specify multiple configurations (snort.conf and everything
>>  it includes), bound either by Vlan ID or IP Address.  This allows you
>>  to run one instance of Snort with multiple snort.conf, rather than
>>  having separate processes.
>>
>> - Continued inspection of traffic while reloading a configuration.
>>  Add --enable-reload option to your configure script prior to building.
>>
>> - Rate Based Attack prevention for Connection Attempts, Concurrent
>>  Connections, and improved rule/event filtering.  See README.filters
>>  for details.
>>
>> - SSH preprocessor (no longer experimental)
>>
>> - Performance improvements in various places
>>
>> Please see the Release Notes and ChangeLog for more details.
>>
>> Please submit bugs, questions, and feedback to
>> snort-beta@....
>>
>> Happy Snorting!
>> The Snort Release Team

Thanks... we'll look into it.

-s

rmkml wrote:
> Hi,
> First, Congratulations SF team for this new version!
> Im found a segfault with this new version with this rule:
>  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault";
> content:"test"; within:; nocase; sid:987654321; rev:1;)
> Yes, within keyword don't have value! and snort crash with nocasei
> keyword...
> look my very simple snort.conf:
>  dynamicpreprocessor directory
> dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
>  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
>  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
> and sid 987654321 of course!
> 
> Please add my pseudo to Credits file and my company: Crusoe Researches.
> Happy Detect (snort,bro,azwalaro)
> Regards
> Rmkml
> Crusoe-Researches.com
> 
> 
> On Thu, 14 May 2009, Snort Releases wrote:
> 
>> A beta version of Snort 2.8.5 is now available on snort.org, at
>> http://www.snort.org/dl/
>>
>> Snort 2.8.5 introduces:
>>
>> - Ability to specify multiple configurations (snort.conf and everything
>>  it includes), bound either by Vlan ID or IP Address.  This allows you
>>  to run one instance of Snort with multiple snort.conf, rather than
>>  having separate processes.
>>
>> - Continued inspection of traffic while reloading a configuration.
>>  Add --enable-reload option to your configure script prior to building.
>>
>> - Rate Based Attack prevention for Connection Attempts, Concurrent
>>  Connections, and improved rule/event filtering.  See README.filters
>>  for details.
>>
>> - SSH preprocessor (no longer experimental)
>>
>> - Performance improvements in various places
>>
>> Please see the Release Notes and ChangeLog for more details.
>>
>> Please submit bugs, questions, and feedback to snort-beta@....
>>
>> Happy Snorting!
>> The Snort Release Team
>

Thanks for reporting this issue.  We've already opened a bug on this and are
working on a fix.

Russ

On Thu, May 14, 2009 at 9:39 AM, rmkml <rmkml@...> wrote:

> Hi,
> First, Congratulations SF team for this new version!
> Im found a segfault with this new version with this rule:
>  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault";
> content:"test"; within:; nocase; sid:987654321; rev:1;)
> Yes, within keyword don't have value! and snort crash with nocasei
> keyword...
> look my very simple snort.conf:
>  dynamicpreprocessor directory
> dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
>  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
>  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
> and sid 987654321 of course!
>
> Please add my pseudo to Credits file and my company: Crusoe Researches.
> Happy Detect (snort,bro,azwalaro)
> Regards
> Rmkml
> Crusoe-Researches.com
>
>
>
> On Thu, 14 May 2009, Snort Releases wrote:
>
>  A beta version of Snort 2.8.5 is now available on snort.org, at
>> http://www.snort.org/dl/
>>
>> Snort 2.8.5 introduces:
>>
>> - Ability to specify multiple configurations (snort.conf and everything
>>  it includes), bound either by Vlan ID or IP Address.  This allows you
>>  to run one instance of Snort with multiple snort.conf, rather than
>>  having separate processes.
>>
>> - Continued inspection of traffic while reloading a configuration.
>>  Add --enable-reload option to your configure script prior to building.
>>
>> - Rate Based Attack prevention for Connection Attempts, Concurrent
>>  Connections, and improved rule/event filtering.  See README.filters
>>  for details.
>>
>> - SSH preprocessor (no longer experimental)
>>
>> - Performance improvements in various places
>>
>> Please see the Release Notes and ChangeLog for more details.
>>
>> Please submit bugs, questions, and feedback to snort-beta@....
>>
>> Happy Snorting!
>> The Snort Release Team
>>
>

I notice the --enable-memory-cleanup ./configure option is missing.
Has this been removed?

Wally

On Thu, May 14, 2009 at 11:14 AM, Russ Combs <rcombs@...> wrote:
> Thanks for reporting this issue.  We've already opened a bug on this and are
> working on a fix.
>
> Russ
>
> On Thu, May 14, 2009 at 9:39 AM, rmkml <rmkml@...> wrote:
>>
>> Hi,
>> First, Congratulations SF team for this new version!
>> Im found a segfault with this new version with this rule:
>>  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault";
>> content:"test"; within:; nocase; sid:987654321; rev:1;)
>> Yes, within keyword don't have value! and snort crash with nocasei
>> keyword...
>> look my very simple snort.conf:
>>  dynamicpreprocessor directory
>> dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
>>  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
>>  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
>> and sid 987654321 of course!
>>
>> Please add my pseudo to Credits file and my company: Crusoe Researches.
>> Happy Detect (snort,bro,azwalaro)
>> Regards
>> Rmkml
>> Crusoe-Researches.com
>>
>>
>> On Thu, 14 May 2009, Snort Releases wrote:
>>
>>> A beta version of Snort 2.8.5 is now available on snort.org, at
>>> http://www.snort.org/dl/
>>>
>>> Snort 2.8.5 introduces:
>>>
>>> - Ability to specify multiple configurations (snort.conf and everything
>>>  it includes), bound either by Vlan ID or IP Address.  This allows you
>>>  to run one instance of Snort with multiple snort.conf, rather than
>>>  having separate processes.
>>>
>>> - Continued inspection of traffic while reloading a configuration.
>>>  Add --enable-reload option to your configure script prior to building.
>>>
>>> - Rate Based Attack prevention for Connection Attempts, Concurrent
>>>  Connections, and improved rule/event filtering.  See README.filters
>>>  for details.
>>>
>>> - SSH preprocessor (no longer experimental)
>>>
>>> - Performance improvements in various places
>>>
>>> Please see the Release Notes and ChangeLog for more details.
>>>
>>> Please submit bugs, questions, and feedback to snort-beta@....
>>>
>>> Happy Snorting!
>>> The Snort Release Team
>
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Snort-devel mailing list
> Snort-devel@...
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
>

Hi Wally,

Yes, the option has been removed.  Snort will cleanup memory regardless
now at exit.

Todd


Jason Wallace wrote:
> I notice the --enable-memory-cleanup ./configure option is missing.
> Has this been removed?
>
> Wally
>
> On Thu, May 14, 2009 at 11:14 AM, Russ Combs <rcombs@...> wrote:
>   
>> Thanks for reporting this issue.  We've already opened a bug on this and are
>> working on a fix.
>>
>> Russ
>>
>> On Thu, May 14, 2009 at 9:39 AM, rmkml <rmkml@...> wrote:
>>     
>>> Hi,
>>> First, Congratulations SF team for this new version!
>>> Im found a segfault with this new version with this rule:
>>>  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault";
>>> content:"test"; within:; nocase; sid:987654321; rev:1;)
>>> Yes, within keyword don't have value! and snort crash with nocasei
>>> keyword...
>>> look my very simple snort.conf:
>>>  dynamicpreprocessor directory
>>> dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
>>>  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
>>>  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
>>> and sid 987654321 of course!
>>>
>>> Please add my pseudo to Credits file and my company: Crusoe Researches.
>>> Happy Detect (snort,bro,azwalaro)
>>> Regards
>>> Rmkml
>>> Crusoe-Researches.com
>>>
>>>
>>> On Thu, 14 May 2009, Snort Releases wrote:
>>>
>>>       
>>>> A beta version of Snort 2.8.5 is now available on snort.org, at
>>>> http://www.snort.org/dl/
>>>>
>>>> Snort 2.8.5 introduces:
>>>>
>>>> - Ability to specify multiple configurations (snort.conf and everything
>>>>  it includes), bound either by Vlan ID or IP Address.  This allows you
>>>>  to run one instance of Snort with multiple snort.conf, rather than
>>>>  having separate processes.
>>>>
>>>> - Continued inspection of traffic while reloading a configuration.
>>>>  Add --enable-reload option to your configure script prior to building.
>>>>
>>>> - Rate Based Attack prevention for Connection Attempts, Concurrent
>>>>  Connections, and improved rule/event filtering.  See README.filters
>>>>  for details.
>>>>
>>>> - SSH preprocessor (no longer experimental)
>>>>
>>>> - Performance improvements in various places
>>>>
>>>> Please see the Release Notes and ChangeLog for more details.
>>>>
>>>> Please submit bugs, questions, and feedback to snort-beta@....
>>>>
>>>> Happy Snorting!
>>>> The Snort Release Team
>>>>         
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Snort-devel mailing list
>> Snort-devel@...
>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>>
>>
>>     
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Snort-devel mailing list
> Snort-devel@...
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>

Hi,

I have one question and a possible bug to report.

Question:
Is the following a valid configure option?

./configure --enable-flexresp2 --enable-react


Bug:

./configure --enable-dynamicplugin --enable-flexresp2

Fails to build...

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../src -I../src/sfutil
-I/usr/include/pcap -I../src/output-plugins -I../src/detection-plugins
-I../src/dynamic-plugins -I../src/preprocessors
-I../src/preprocessors/portscan
-I../src/preprocessors/HttpInspect/include
-I../src/preprocessors/Stream5 -I../src/target-based  -DDYNAMIC_PLUGIN
-DENABLE_RESPONSE2 -I/usr/include  -g -O2 -fvisibility=hidden -Wall -c
parser.c
parser.c:642: error: syntax error before ';' token
parser.c:643: warning: missing braces around initializer
parser.c:643: warning: (near initialization for `config_opts[42]')
parser.c:643: warning: initialization makes pointer from integer without a cast
parser.c:643: warning: initialization makes integer from pointer without a cast
parser.c:644: error: syntax error before '{' token
make[3]: *** [parser.o] Error 1
make[3]: Leaving directory
`/var/tmp/portage/net-analyzer/snort-2.8.5_beta/work/snort-2.8.5.beta/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/net-analyzer/snort-2.8.5_beta/work/snort-2.8.5.beta/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/net-analyzer/snort-2.8.5_beta/work/snort-2.8.5.beta'
make: *** [all] Error 2

Wally


On Fri, May 15, 2009 at 11:36 AM, Todd Wease <twease@...> wrote:
> Hi Wally,
>
> Yes, the option has been removed.  Snort will cleanup memory regardless
> now at exit.
>
> Todd
>
>
> Jason Wallace wrote:
>> I notice the --enable-memory-cleanup ./configure option is missing.
>> Has this been removed?
>>
>> Wally
>>
>> On Thu, May 14, 2009 at 11:14 AM, Russ Combs <rcombs@...> wrote:
>>
>>> Thanks for reporting this issue.  We've already opened a bug on this and are
>>> working on a fix.
>>>
>>> Russ
>>>
>>> On Thu, May 14, 2009 at 9:39 AM, rmkml <rmkml@...> wrote:
>>>
>>>> Hi,
>>>> First, Congratulations SF team for this new version!
>>>> Im found a segfault with this new version with this rule:
>>>>  alert tcp any any -> any any (msg:"snort v2.8.5 beta SegFault";
>>>> content:"test"; within:; nocase; sid:987654321; rev:1;)
>>>> Yes, within keyword don't have value! and snort crash with nocasei
>>>> keyword...
>>>> look my very simple snort.conf:
>>>>  dynamicpreprocessor directory
>>>> dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
>>>>  dynamicengine dynamic-plugins/sf_engine/.libs/libsf_engine.so
>>>>  preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
>>>> and sid 987654321 of course!
>>>>
>>>> Please add my pseudo to Credits file and my company: Crusoe Researches.
>>>> Happy Detect (snort,bro,azwalaro)
>>>> Regards
>>>> Rmkml
>>>> Crusoe-Researches.com
>>>>
>>>>
>>>> On Thu, 14 May 2009, Snort Releases wrote:
>>>>
>>>>
>>>>> A beta version of Snort 2.8.5 is now available on snort.org, at
>>>>> http://www.snort.org/dl/
>>>>>
>>>>> Snort 2.8.5 introduces:
>>>>>
>>>>> - Ability to specify multiple configurations (snort.conf and everything
>>>>>  it includes), bound either by Vlan ID or IP Address.  This allows you
>>>>>  to run one instance of Snort with multiple snort.conf, rather than
>>>>>  having separate processes.
>>>>>
>>>>> - Continued inspection of traffic while reloading a configuration.
>>>>>  Add --enable-reload option to your configure script prior to building.
>>>>>
>>>>> - Rate Based Attack prevention for Connection Attempts, Concurrent
>>>>>  Connections, and improved rule/event filtering.  See README.filters
>>>>>  for details.
>>>>>
>>>>> - SSH preprocessor (no longer experimental)
>>>>>
>>>>> - Performance improvements in various places
>>>>>
>>>>> Please see the Release Notes and ChangeLog for more details.
>>>>>
>>>>> Please submit bugs, questions, and feedback to snort-beta@....
>>>>>
>>>>> Happy Snorting!
>>>>> The Snort Release Team
>>>>>
>>> ------------------------------------------------------------------------------
>>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>>> production scanning environment may not be a perfect world - but thanks to
>>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>>> i700
>>> Series Scanner you'll get full speed at 300 dpi even with all image
>>> processing features enabled. http://p.sf.net/sfu/kodak-com
>>> _______________________________________________
>>> Snort-devel mailing list
>>> Snort-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables
>> unlimited royalty-free distribution of the report engine
>> for externally facing server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Snort-devel mailing list
>> Snort-devel@...
>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>>
>
>

README.filters was accidentally missing from the packages.
It is attached for your reference when testing out the beta.

Snort Releases wrote:
> A beta version of Snort 2.8.5 is now available on snort.org, at
> http://www.snort.org/dl/
> 
> Snort 2.8.5 introduces:
> 
> - Ability to specify multiple configurations (snort.conf and everything
>   it includes), bound either by Vlan ID or IP Address.  This allows you
>   to run one instance of Snort with multiple snort.conf, rather than
>   having separate processes.
> 
> - Continued inspection of traffic while reloading a configuration.
>   Add --enable-reload option to your configure script prior to building.
> 
> - Rate Based Attack prevention for Connection Attempts, Concurrent
>   Connections, and improved rule/event filtering.  See README.filters
>   for details.
> 
> - SSH preprocessor (no longer experimental)
> 
> - Performance improvements in various places
> 
> Please see the Release Notes and ChangeLog for more details. 
> 
> Please submit bugs, questions, and feedback to snort-beta@....
> 
> Happy Snorting!
> The Snort Release Team
>

You can achieve the same thing via just putting the iplist
preprocessor instantiation in a separate file (blacklist.conf?) and
then including the file from Snort.conf.  I didn't want to spend a lot
of time writing more file opening/reading/parsing logic and loops to
get this out more quickly so I stuck with the built-in parser.  I
setup the runtime config of the system so that you could make multiple
calls to load the whitelist/blacklist if it gets bigger than Snort can
load in its standard parse buffer.

In that name field are you trying to denote the source of the
blacklist?  Tracking that stuff within the data structure would either
require additional memory and complexity to produce the name or
multiple instantiations of the data structure and associated overhead.
 I'd figure performance would be more important than the name but
that's just me talking.  I could certainly add all this stuff but I
think basic and fast might be the better way to go from where I sit.

Thoughts?

Marty

On Wed, May 13, 2009 at 3:31 PM, Seth Art <sethsec@...> wrote:
> Pretty cool!
>
> Suggestion: Rather than enter the IP addresses into snort.conf, it
> might be easier to manage something like this if we reference files
> that include the IP lists using a predefined syntax.  That way you can
> download community based lists daily without ever having to update
> snort.conf each time.
>
> Something like this:
>
> preprocessor iplist: < noalerts > < nodrops > <directory>
>                    whitelist name <filename>
>                    blacklist name <filename>
>                    blacklist name <filename>
>
> Ex:
>
> preprocessor iplist:
>                    whitelist trusted /etc/snort/lists/trusted.list
>                    blacklist ET-dshield /etc/snort/lists/dshield.list
>                    blacklist ET-CC /etc/snort/lists/cc.list
>
>  Thoughts?
>
>
> On Wed, May 13, 2009 at 2:50 PM, Martin Roesch <roesch@...> wrote:
>> Hi everyone,
>>
>> I wrote a patch for Snort 2.8.4.1 that implements IP blacklisting as a
>> preprocessor in Snort over this past weekend.  We talked about this
>> last week on the mailing list in regards to trying to implement
>> blacklisting using regular Snort rules and how well that doesn't work.
>> :)
>>
>> This code has been tested against Snort 2.8.4.1 only.  I've tested
>> builds on OS X, Ubuntu and Fedora so far.  It requires libdnet (or
>> dumbnet-dev for those of you on Debian-based distros) to build
>> properly.  Check the README file that comes with it for instructions
>> on patching it into your codebase.  It supports inline blocking and
>> alerting but not Flexresp-style TCP reset session shootdowns.
>>
>> Have a look and let me know what features you'd like or bugs you find.
>>
>> This code is purely EXPERIMENTAL, this is just me spending some of my
>> spare time doing a fun coding project so if your machine sprouts legs
>> and refuses to work until it receives part of the TARP bailout it's
>> not my fault.
>>
>> Here's the link:
>>
>> http://www.snort.org/users/roesch/code/iplist.patch.tgz
>>
>> Marty
>>
>> --
>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>> Snort: Open Source IDP - http://www.snort.org
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Snort-users mailing list
>> Snort-users@...
>> 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
>>
>



-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org

Hi Seth,

The alerts look exactly like standard preprocessor alerts, I'm using
GID 135 for the plugin and it only generates one message.  I could get
fancier with some of it but noting the origin of a blacklisted IP
would be a bit of a pain.  The ptrie structure does support attaching
data to the address entries but where there are collisions the logic
will get more complex and it makes the parsing more complex too.  If
we can live with it this way that makes life easiest for me but if
someone makes a good use case for it I'll implement it.

Marty

On Wed, May 13, 2009 at 4:02 PM, Seth Art <sethsec@...> wrote:
> I am pretty sure a blacklist.conf, called in snort.conf would do the trick.
>
> With the name thing, I think it would be informative to record why
> each IP was blocked or alerted on.
>
> The high speed functionality is great, don't get me wrong.  Obviously
> we cant have all the info we get from a sig, AND have a high speed
> preproc, however I assume the alerts will look like any other preproc
> alert, right?  If I could pick one piece of information to have in
> addition to the IP, it would be a classification (command and control,
> malware, spam servers, rbn, etc).  I think this would help with
> response.
>
> If the additional memory/complexity would defeat the purpose of having
> the high speed preproc in the first place, then I agree that it might
> not make sense.
>
> Either way, I am looking forward to testing it out.   Thanks.
>
> -Seth
>
>
> On Wed, May 13, 2009 at 3:37 PM, Martin Roesch <roesch@...> wrote:
>> You can achieve the same thing via just putting the iplist
>> preprocessor instantiation in a separate file (blacklist.conf?) and
>> then including the file from Snort.conf.  I didn't want to spend a lot
>> of time writing more file opening/reading/parsing logic and loops to
>> get this out more quickly so I stuck with the built-in parser.  I
>> setup the runtime config of the system so that you could make multiple
>> calls to load the whitelist/blacklist if it gets bigger than Snort can
>> load in its standard parse buffer.
>>
>> In that name field are you trying to denote the source of the
>> blacklist?  Tracking that stuff within the data structure would either
>> require additional memory and complexity to produce the name or
>> multiple instantiations of the data structure and associated overhead.
>>  I'd figure performance would be more important than the name but
>> that's just me talking.  I could certainly add all this stuff but I
>> think basic and fast might be the better way to go from where I sit.
>>
>> Thoughts?
>>
>> Marty
>>
>> On Wed, May 13, 2009 at 3:31 PM, Seth Art <sethsec@...> wrote:
>>> Pretty cool!
>>>
>>> Suggestion: Rather than enter the IP addresses into snort.conf, it
>>> might be easier to manage something like this if we reference files
>>> that include the IP lists using a predefined syntax.  That way you can
>>> download community based lists daily without ever having to update
>>> snort.conf each time.
>>>
>>> Something like this:
>>>
>>> preprocessor iplist: < noalerts > < nodrops > <directory>
>>>                    whitelist name <filename>
>>>                    blacklist name <filename>
>>>                    blacklist name <filename>
>>>
>>> Ex:
>>>
>>> preprocessor iplist:
>>>                    whitelist trusted /etc/snort/lists/trusted.list
>>>                    blacklist ET-dshield /etc/snort/lists/dshield.list
>>>                    blacklist ET-CC /etc/snort/lists/cc.list
>>>
>>>  Thoughts?
>>>
>>>
>>> On Wed, May 13, 2009 at 2:50 PM, Martin Roesch <roesch@...> wrote:
>>>> Hi everyone,
>>>>
>>>> I wrote a patch for Snort 2.8.4.1 that implements IP blacklisting as a
>>>> preprocessor in Snort over this past weekend.  We talked about this
>>>> last week on the mailing list in regards to trying to implement
>>>> blacklisting using regular Snort rules and how well that doesn't work.
>>>> :)
>>>>
>>>> This code has been tested against Snort 2.8.4.1 only.  I've tested
>>>> builds on OS X, Ubuntu and Fedora so far.  It requires libdnet (or
>>>> dumbnet-dev for those of you on Debian-based distros) to build
>>>> properly.  Check the README file that comes with it for instructions
>>>> on patching it into your codebase.  It supports inline blocking and
>>>> alerting but not Flexresp-style TCP reset session shootdowns.
>>>>
>>>> Have a look and let me know what features you'd like or bugs you find.
>>>>
>>>> This code is purely EXPERIMENTAL, this is just me spending some of my
>>>> spare time doing a fun coding project so if your machine sprouts legs
>>>> and refuses to work until it receives part of the TARP bailout it's
>>>> not my fault.
>>>>
>>>> Here's the link:
>>>>
>>>> http://www.snort.org/users/roesch/code/iplist.patch.tgz
>>>>
>>>> Marty
>>>>
>>>> --
>>>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>>>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>>>> Snort: Open Source IDP - http://www.snort.org
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>>>> production scanning environment may not be a perfect world - but thanks to
>>>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>>>> Series Scanner you'll get full speed at 300 dpi even with all image
>>>> processing features enabled. http://p.sf.net/sfu/kodak-com
>>>> _______________________________________________
>>>> Snort-users mailing list
>>>> Snort-users@...
>>>> 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
>>>>
>>>
>>
>>
>>
>> --
>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>> Snort: Open Source IDP - http://www.snort.org
>>
>



-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org

It sounds like a good case for post processing markup. SnortUnified.pm
has hooks to make this easy. "Handlers" should do well as none of the
other output code needs modification, it will do it in the background
before presenting the complete event.

Basically create and register a handler for all GID 135 events to
lookup the IP address in metadata and place it into the message.

On Wed, May 13, 2009 at 9:13 PM, Martin Roesch <roesch@...> wrote:
> Hi Seth,
>
> The alerts look exactly like standard preprocessor alerts, I'm using
> GID 135 for the plugin and it only generates one message.  I could get
> fancier with some of it but noting the origin of a blacklisted IP
> would be a bit of a pain.  The ptrie structure does support attaching
> data to the address entries but where there are collisions the logic
> will get more complex and it makes the parsing more complex too.  If
> we can live with it this way that makes life easiest for me but if
> someone makes a good use case for it I'll implement it.
>
> Marty
>
> On Wed, May 13, 2009 at 4:02 PM, Seth Art <sethsec@...> wrote:
>> I am pretty sure a blacklist.conf, called in snort.conf would do the trick.
>>
>> With the name thing, I think it would be informative to record why
>> each IP was blocked or alerted on.
>>
>> The high speed functionality is great, don't get me wrong.  Obviously
>> we cant have all the info we get from a sig, AND have a high speed
>> preproc, however I assume the alerts will look like any other preproc
>> alert, right?  If I could pick one piece of information to have in
>> addition to the IP, it would be a classification (command and control,
>> malware, spam servers, rbn, etc).  I think this would help with
>> response.
>>
>> If the additional memory/complexity would defeat the purpose of having
>> the high speed preproc in the first place, then I agree that it might
>> not make sense.
>>
>> Either way, I am looking forward to testing it out.   Thanks.
>>
>> -Seth
>>
>>
>> On Wed, May 13, 2009 at 3:37 PM, Martin Roesch <roesch@...> wrote:
>>> You can achieve the same thing via just putting the iplist
>>> preprocessor instantiation in a separate file (blacklist.conf?) and
>>> then including the file from Snort.conf.  I didn't want to spend a lot
>>> of time writing more file opening/reading/parsing logic and loops to
>>> get this out more quickly so I stuck with the built-in parser.  I
>>> setup the runtime config of the system so that you could make multiple
>>> calls to load the whitelist/blacklist if it gets bigger than Snort can
>>> load in its standard parse buffer.
>>>
>>> In that name field are you trying to denote the source of the
>>> blacklist?  Tracking that stuff within the data structure would either
>>> require additional memory and complexity to produce the name or
>>> multiple instantiations of the data structure and associated overhead.
>>>  I'd figure performance would be more important than the name but
>>> that's just me talking.  I could certainly add all this stuff but I
>>> think basic and fast might be the better way to go from where I sit.
>>>
>>> Thoughts?
>>>
>>> Marty
>>>
>>> On Wed, May 13, 2009 at 3:31 PM, Seth Art <sethsec@...> wrote:
>>>> Pretty cool!
>>>>
>>>> Suggestion: Rather than enter the IP addresses into snort.conf, it
>>>> might be easier to manage something like this if we reference files
>>>> that include the IP lists using a predefined syntax.  That way you can
>>>> download community based lists daily without ever having to update
>>>> snort.conf each time.
>>>>
>>>> Something like this:
>>>>
>>>> preprocessor iplist: < noalerts > < nodrops > <directory>
>>>>                    whitelist name <filename>
>>>>                    blacklist name <filename>
>>>>                    blacklist name <filename>
>>>>
>>>> Ex:
>>>>
>>>> preprocessor iplist:
>>>>                    whitelist trusted /etc/snort/lists/trusted.list
>>>>                    blacklist ET-dshield /etc/snort/lists/dshield.list
>>>>                    blacklist ET-CC /etc/snort/lists/cc.list
>>>>
>>>>  Thoughts?
>>>>
>>>>
>>>> On Wed, May 13, 2009 at 2:50 PM, Martin Roesch <roesch@...> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I wrote a patch for Snort 2.8.4.1 that implements IP blacklisting as a
>>>>> preprocessor in Snort over this past weekend.  We talked about this
>>>>> last week on the mailing list in regards to trying to implement
>>>>> blacklisting using regular Snort rules and how well that doesn't work.
>>>>> :)
>>>>>
>>>>> This code has been tested against Snort 2.8.4.1 only.  I've tested
>>>>> builds on OS X, Ubuntu and Fedora so far.  It requires libdnet (or
>>>>> dumbnet-dev for those of you on Debian-based distros) to build
>>>>> properly.  Check the README file that comes with it for instructions
>>>>> on patching it into your codebase.  It supports inline blocking and
>>>>> alerting but not Flexresp-style TCP reset session shootdowns.
>>>>>
>>>>> Have a look and let me know what features you'd like or bugs you find.
>>>>>
>>>>> This code is purely EXPERIMENTAL, this is just me spending some of my
>>>>> spare time doing a fun coding project so if your machine sprouts legs
>>>>> and refuses to work until it receives part of the TARP bailout it's
>>>>> not my fault.
>>>>>
>>>>> Here's the link:
>>>>>
>>>>> http://www.snort.org/users/roesch/code/iplist.patch.tgz
>>>>>
>>>>> Marty
>>>>>
>>>>> --
>>>>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>>>>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>>>>> Snort: Open Source IDP - http://www.snort.org
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>>>>> production scanning environment may not be a perfect world - but thanks to
>>>>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>>>>> Series Scanner you'll get full speed at 300 dpi even with all image
>>>>> processing features enabled. http://p.sf.net/sfu/kodak-com
>>>>> _______________________________________________
>>>>> Snort-users mailing list
>>>>> Snort-users@...
>>>>> 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
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>>> Snort: Open Source IDP - http://www.snort.org
>>>
>>
>
>
>
> --
> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
> Sourcefire - Security for the Real World - http://www.sourcefire.com
> Snort: Open Source IDP - http://www.snort.org
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Snort-devel mailing list
> Snort-devel@...
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>

I'll provide mt .$02 in line

On Fri, May 8, 2009 at 1:09 PM, Soumyadipta Das
<soumyadipta_das@...> wrote:
> Hi Everyone,
>
> Following are two school of thoughts regarding the packet decoding:
>
> 1) The snort decoder engine(decode.c) decodes a packet and puts the
> different layer headers in different structures starting from the data link
> layer until layer 4(OSI-model). Contents of the upper layers are not
> directly segregated in structures and are left for preprocessors and rules
> to take care of. Benefit of this approach is the flexibility while writing
> rules to match for any particular pattern above layer 4. However, on the
> other hand it also opens up the possibility of a mistake in writing a rule.
>

It also does not impose overhead of decoding where it is not needed or
introduce complexity where it is not needed. The rules language is
itself is a a state machine and can track and decode a majority of
protocols. Where rules cannot effectively model to detect attack there
is a clear need to move to preprocessors and further normalization,
you can see evidence of this is the preprocessors already around. Some
say # of protocols supported is a key metric in assessing the
completeness of detection. I would argue that snort supports unlimited
protocols and that having to rely on a developer to add protocol
support is inherently flawed for reasons I will call out for #2

There are definitely some drawbacks in this approach in that you
cannot share a decode across multiple consumers of that information
but the problem set seems to be generally small so I wouldn't consider
it a significant area of concern.

> 2) A lot of commercial IPS/IDS tries to decode different application layer
> protocols. This approach provides more easy accessible granularity while
> writing a rule particularly for given protocol. For instance, a rule for a
> given function on a MSRPC named pipe distinguished by its UUID would be
> easier to write.

I would contend that t provides accessibility at the cost of
granularity and flexibility. You are beholden to the developers
thoroughness and understanding of the protocol and the added
complexity is likely to introduce unnecessary overhead and will
inevitably introduce a vulnerability. Simple and easy only works up to
the bounds of the person that implemented it.

A good example of this is ISS and the protocol decodes they use for
many things, all closed and developed in code. Some number of years
ago the ICQ protocol decoder was found to have an overflow and it
resulted in the most rapidly spread worm in all of history ( Check my
data here, I could be recalling incorrectly ) -
http://secunia.com/advisories/11073/

In the snort world it is just a rule, using a proven code base, not
requiring a recompile or regression, and unlikely to introduce a
vulnerability. The cost is that the rule writer must understand hte
protocol and triggering conditions. The reality is that this is the
case regardless of the implementation used to detect it. If you accept
that in order to detect you must understand then it is not a far reach
to know that armed with a rules language and the knowledge of the
vulnerability you can handle things just as well if not better.

Snort has had issues with in the past in much the same as the above
referenced case. Bottom line, new code = new complexity = potential
new vulnerability. Rules = new detection without new code without
potential for new vulnerability. Both methods still require intimate
knowledge of the tool and vulnerability.

>
> Please share your views on which would be a preferred approach.
>
> Regards,
> Soum
>
> ________________________________
> Now surf faster and smarter ! Check out the new Firefox 3 - Yahoo! Edition *
> Click here!
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Snort-devel mailing list
> Snort-devel@...
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
>