[Snort-users] Re: Snort-users digest, Vol 1 #3857 - 5 msgs

adam_peterson at ...10608... adam_peterson at ...10608...
Tue Dec 30 13:28:05 EST 2003


I've been through exactly what you're going through with both Windows and 
UNIX based sensors and concluded the following:

To update rules on remote sensors, I use Oinkmaster on the master console 
to download the updates.  I then scp those updates to the remote sensors 
using a script (batch file).  That accomplishes what Activeworx attempts 
to do in a GUI and, in my opinion, fails to do in reality by not updating 
the snort.conf file (excluded by default in oinkmaster.conf.  That 
addresses the sensor_name and home_net problems which I also had.  I run 
this batch file every 12 hours:

@echo off
perl oinkmaster\oinkmaster.pl -o c:\ids\rules.new -C 
c:\ids\oinkmaster.conf -b c:\ids\rules.old >> c:\ids\update.log
fromdos rules.new\*

So oinkmaster downloads rule updates to c:\ids\rules.new.  Fromdos just 
converts the text from dos format to UNIX since I do this on a Windows 
machine but my sensors are Solaris.  I then use pscp (from PuTTy) in a 
seperate batch file to update the remote sensors.  You could of course 
just use scp from a UNIX box instead.

@echo off
if exist plink.exe goto 1
echo.
echo plink.exe must be in the current directory!
goto end
:1
if not "%1"=="" goto ok
echo.
echo You must specify a password!
echo.
echo Syntax: tocopy [password]
goto end
:ok
fromdos rules.new\*
echo.
echo San Francisco
pscp -l root -pw %1 rules.new\* root at ...10856...:/etc/snort
echo.
echo New Jersey
pscp -l root -pw %1 rules.new\* root at ...10857...:/etc/snort
echo.
echo Tel Aviv
pscp -l root -pw %1 rules.new\* root at ...10858...:/etc/snort
echo.
echo Manila
pscp -l root -pw %1 rules.new\* root at ...10859...:/etc/snort
echo.
echo Melbourne
pscp -l root -pw %1 rules.new\* root at ...10860...:/etc/snort
:end

As for commenting out the entire rules file (i.e. snmp.rules), I'm sure 
there's a better way to do it than what I do which is what you're trying 
to avoid.  I simply ssh to each sensor and comment it out.  My solution to 
this becoming a management nightmare was to solidify exactly what rules 
files I would be including prior to deployment.  I know that sounds overly 
simple but the truth is that my 9 global sites have enough in common 
traffic-wise to allow me to standardize which rules files are included. 
Hopefully you'll have the same luck.  You still have complete control of 
the individual rules being enabled/disabled using oinkmaster's 
"disablesid" in oinkmaster.conf.

As long as you're dealing with the same/similar hardware you can just copy 
the snort binary and be done with it.  It's 1 file and that's it which is 
wonderful because it means you can compile on 1 machine and just scp the 
new version to your remotes.

Hope that helps.  It's taken me a loooooooooong time to get to the point 
I'm at now where everything works reliably.  I spent too much time with 
GUI's trying to accomplish the same thing I can do with a batch file.

>From: "robert schwartz" <robert at ...5775...>
>To: <snort-users at lists.sourceforge.net>
>Date: Tue, 30 Dec 2003 09:36:01 -0800
>Subject: [Snort-users] Managing many sensors
>
>I have a lot of sensors I'm deploying (5 at this time with many more
>being rolled out after the pilot) and we're starting to design the rules
>management system / update system.  I'm looking at a few tools including
>Activeworx or rsync to do "top down" rule and binary management instead
>of having the management done on all the remote headless sensors. 
>
>With rule updates (including tuning the rulesets sitewide) I can get a
>good update scheme using rsync, but the snort.conf file will lose the
>"$HOME_NET" variable and the "sensor_id" variable in the output plugin.
>If I update all the rules except snort.conf, I lose the ability to
>disable snmp rules on a sitewide basis (for example) by commenting out
>that snmp-rules section of the snort.conf and having that change blasted
>out to the sensors.  With Activeworx it appears that I need a unique
>snort rules configuration for each sensor, and that might be too much
>admin overhead.
>
>What is the best way to proceed assuming standard UN*X style tools like
>SSH, OpenSSL, Rsync, etc?  Currently I have certificate auth working
>from a "master" sensor to the "slave" sensors for SSH and Rsync over
>ssh, but the "perfect" way to update rules from master to clients eludes
>me.  Any help?
>
>Related issue:  I want to upgrade to 2.1, but I don't want to update all
>the remote sensors by hand.  Is the snort binary the only file I have to
>push out?  Is there a packing list somewhere in a Makefile or something,
>or a way to install all the snort binary's into an alternate directory
>structure so I can move those binaries to the remote machines?
>
>I apologize in advance for the redundant nature of these questions, but
>although these issues are often discussed, I haven't found a solution
>that resonates as "the right one" yet.

Adam Peterson | Senior WAN Engineer | SPL WorldGroup | 
adam_peterson at ...10608... | +1.415.357.4787




More information about the Snort-users mailing list