[Snort-devel] Snort3 IPS questions, issues, and requests

Russ rucombs at cisco.com
Mon Nov 20 10:24:32 EST 2017

Hey Noah, responses inline.


On 11/19/17 3:36 AM, Noah Dietrich wrote:
> Hello,
> While working with Snort3 (build 240), I have found some issues, and 
> have a few questions and requests. I am happy to submit these through 
> Github if you'd like.
This is fine.  Whatever works for you.
> 1.  What is the difference between *ips.include* and *ips.rules*?  
> From the manual and examples, it looks like ips.include is for legacy 
> rules (although snort3 community rules load fine), while ips.rules is 
> for local rules in the same file.  can you clarify?
ips.include = filename of Snort 3.0 rules you want to load.  Like Snort 
2.X, you can put include statements in that file to include other 
files.  Snort 3.0 will not load Snort 2.X rules (but you can use 
snort2lua to convert them).

ips.rules = string variable containing rules directly in the Lua file.  
This is good for simple rules or test configurations or enabling 
specific builtins like this:

local_rules =
block ( gid:119; sid:16; )
block ( gid:119; sid:32; )

ips = { rules = local_rules }

> 2.  For best practices, are you expecting people to set *$RULE_HOME* 
> in *snort_defaults.lua*, or should this be overwritten in 
> *snort.lua*?  Should this be moved to snort.lua, since the word 
> 'defaults' seems to indicate something the user shouldn't change.
I am not familiar with RULE_HOME, but obviously those files are just 
starting points and should be modified to meet your needs.  That said, 
my suggestion would be to just edit snort.lua and copy/paste/tweak stuff 
from snort_defaults.lua into snort.lua or elsewhere.  That way you can 
more easily absorb any changes to snort_defaults.lua.
> 3.  If $RULE_HOME is set, when referencing rule files, you are now 
> required to have all rules under that folder (with no explicit paths 
> to other locations). This seems like a bug.  It would be nice if 
> relative files would use the $RULES_HOME directory, while full paths 
> to rule files would not use $RULE_HOME.
Are you referring to RULE_PATH?  Regardless, there is no restriction on 
where your rules are located or on including one file from another.  
Snort++ intentionally doesn't start guessing about the location of stuff 
so I wouldn't call that a bug.  Sounds like adding a command line option 
that says look for all rules files starting with a given path will do 
what you want.
> 4.  When using *ips.include* with a file that lists all rule files 
> (example below), the file paths don't seem to be relative to 
> $RULE_HOME, but are relative to the snort.lua file, which seems odd.
By default, everything should be relative to your current working 
directory, which seems normal.  :)  How is this different from #3?
> 5.  It would be nice to be able to specify multiple rule files in your 
> snort.lua, rather than listing them all in ips.include (or whatever). 
> The current method of lincluding a list of rule files in a text file 
> referenced from *ips.include *seems like a kludge and adds an extra 
> layer of work and increases the chance of an issue when configuring 
> your rules. A comma-seperated list of files (relative to $RULE_HOME or 
> full paths) would be helpful.
Would this work for you (assuming the new command line option mentioned 
in #3)?

local_rules =
include one.rules
include two.rules
# ...

ips = { rules = local_rules }
> 6.  Not sure if this is an issue or not, but if you specify the GID 
> keyword in a rule loaded with *ips.include*, snort3 will segfault.
Oops.  Any segfault is an issue but I'm unable to reproduce that. Can 
you isolate it and send the rule?
> Thank you,
> Noah
> Here is how my system is configured for the above questions (relevant 
> sections only):
> *_/etc/snort/snort_defaults.lua:_*
> RULE_PATH = '/etc/snort/rules'
> *_/etc/snort/_**_snort.lua_*
> ips =
> {
>     enable_builtin_rules = true,
>     include = RULE_PATH .. '/ips.include',
> }
> *_/etc/snort/rules/ips.include_*
> include rules/snort3-community.rules
> include rules/local.rules
> ls -l /etc/snort/rules
> -rw-r--r-- 1 root root      64 Nov 19 09:33 ips.include
> -rw-r--r-- 1 root root    1389 Nov 19 09:36 local.rules
> -rw-r--r-- 1 root root  376241 Nov 18 13:42 sid-msg.map
> -rw-r--r-- 1 root root 1504089 Nov 18 13:36  snort3-community.rules
> *_
> _*
> *_noah at snort3:/etc/snort$ /bin/snort -V_*
>    ,,_     -*> Snort++ <*-
>   o"  )~   Version 3.0.0 (Build 240) from 2.9.8-383
>    ''''    By Martin Roesch & The Snort Team
> http://snort.org/contact#team
>            Copyright (C) 2014-2017 Cisco and/or its affiliates. All 
> rights reserved.
>            Copyright (C) 1998-2013 Sourcefire, Inc., et al.
>            Using DAQ version 2.2.2
>            Using LuaJIT version 2.0.4
>            Using OpenSSL 1.0.2g  1 Mar 2016
>            Using libpcap version 1.7.4
>            Using PCRE version 8.38 2015-11-23
>            Using ZLIB version 1.2.8
>            Using FlatBuffers 1.7.0
>            Using Hyperscan version 4.6.0 2017-11-18
>            Using LZMA version 5.1.0alpha
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.snort.org
> https://lists.snort.org/mailman/listinfo/snort-devel
> Please visit http://blog.snort.org for the latest news about Snort!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20171120/d30c8f7f/attachment.html>

More information about the Snort-devel mailing list