Re: A few snort3 observations

["Michael Altizer \(mialtize\) via Snort-devel" <snort-devel () lists snort org>]

As an abstraction layer, LibDAQ has two sides: application and modules.  The LibDAQ library (application API) is used 
by Snort to load and interact with DAQ modules, which implement platform-specific functionality that meets the required 
semantics of the module API.  The --daq-dir argument tells Snort where to load dynamic DAQ modules from.  What you told 
Snort at compile time was where the LibDAQ headers and libraries are so that it can build against those to access the 
application API.

If you are using pkg-config to find LibDAQ (highly recommended rather than explicit switches - for your case, you'd do 
something like exporting PKG_CONFIG_PATH=/opt/snort3/libdaq/lib/pkgconfig while configuring), it will also attempt to 
determine information about static DAQ modules and build them into the Snort binary.  This is the default behavior, you 
can disable bundling static DAQ modules with ENABLE_STATIC_DAQ=False via CMake (or --disable-static-daq with 
configure_cmake.sh).  Point being, if you set up your build environment to allow it and the DAQ module you want to use 
is available as a static module in the LibDAQ distribution (say, pcap or nfq), then you do not need to specify 
--daq-dir unless you want to override the built-in modules.

On the snort2lua front, my response from my other email more or less stands regarding both appreciating feedback and 
the priority of improving its functionality at this point in time.  I'm not sure if we'll tackle the nested variable 
situation in the near future.  The generated Snort 3 conf that you sent actually looks pretty reasonable given what I 
can see of your Snort 3 config (which is missing a lot of files that would have been necessary to get a complete 
picture).  Most of the "bloat" comes from snort2lua's boilerplate informative text, combining the other config files 
into the single config (which is the default behavior), and trying to be very helpful about telling you when options 
have been changed or removed.

As for the dofile() usage instead of include(), it's because it's creating an absolute path using the SNORT_LUA_PATH 
environment variable, so it doesn't want the path-tracking semantics of include() to kick in.

On 11/13/20 12:11 PM, James Lay via Snort-devel wrote:
So....my compile line includes:

--with-daq-includes=/opt/snort3/libdaq/include --with-daq-libraries=/opt/snort3/libdaq/lib

So why does snort not know where daq is without the --daq-dir command line option at runtime? I told snort where it was 
when I compiled it above. Can we not simply tell snort "hey...use the compile time options as the default when run"? To 
be fair, this is not just a snort thing...I do see this behavior elsewhere.

Next up....snort2lua. I'll include the before and after as an attachment so as not to make this email unreadable. After 
snort2lua, my tight, simple, 171 line config is now 1206 lines. Seriously...it's ghastly.

Per the snort3 docs (which, funnily enough you can't direct bookmark because the links expire) states: "For best 
results, use include in place of dofile. This function is provided to follow Snort’s include logic." So why does 
snort2lua start off my config with:

dir = os.getenv('SNORT_LUA_PATH')

if ( not dir ) then
    dir = '.'
end

dofile(dir .. '/snort_defaults.lua')
?

Second, snort2lua will fail (did for me at least) if you have a "double" variable declaration:

var CONF_PATH /opt/snort/etc
var RULE_PATH $CONF_PATH/rules

snort2lua will simple say the 2nd line file as shown above wasn't found and my rules weren't processed (hard setting 
this worked though).

Lastly, why did snort2lua split out the alt_max_command_line_len in smtp? Why did snort2lua import my threshold.conf 
and put it right into my snort3.conf? Why do I have a snort.rules.lua and a snort.rules.rules, both of which kinda look 
like rules files? And if I'm using the snort3.conf that comes in the tarball/git repo as a guide, the snort.rules.lua 
doesn't show up ( I do see the snort3-community.rules as an example though, so that's a plus ).

My hope that snort2lua would take a finely tuned snort2.conf and convert it to a finely tuned snort3.conf with some 
minor tweaks to be done is long gone. At this point in time my plan is just to throw out the snort2lua generated 
snort3.conf and just start from scratch. I appreciate the new functions and granularity (and look forward to diving 
into them)...but devs...PLEASE PLEASE PLEASE give people a snort2lua config output that at least looks somewhat similar 
to the original snort2.conf. Otherwise....I suspect folks are just going to look at the output....have eyeballs that 
look like they've just dropped 5 hits of acid, and just delete it and start the laborious task of having to relearn the 
snort config syntax in tandem with converting what they have with their current configs.

Thank you.

James



_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org<mailto:Snort-devel () lists snort org>
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!


_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!