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

[adam_peterson () splwg com]

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@sfsnort:/etc/snort
echo.
echo New Jersey
pscp -l root -pw %1 rules.new\* root@njsnort:/etc/snort
echo.
echo Tel Aviv
pscp -l root -pw %1 rules.new\* root@tavsnort:/etc/snort
echo.
echo Manila
pscp -l root -pw %1 rules.new\* root@mlasnort:/etc/snort
echo.
echo Melbourne
pscp -l root -pw %1 rules.new\* root@melsnort:/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 () mrsquirrel com>
> To: <snort-users () 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 () splwg com | +1.415.357.4787


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
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