Re: DB Rules

["Jason Robertson" <jason () ifuture com>]

actually you wouldn't have to worry so much about -HUPing the database, if 
it's running a sql database, or the likes just insert the data directly into the 
database, when you are ready you rehup everything, it would then open a 
connection to the database do select * from rules, and then close the 
database.  As for others, that's what clustered databases, can be used for.

It's the methodolgy I am using for my pam module actually for postgresql, 
which is a multiple database engine design, so I have a backup which both 
db's update each other, though I am planning to add a front end to that as 
well.. to provide a caching option, to store a number of transactions.. Though 
I wish the db servers had an option to cache in a connection, especially 
inserts, which can be where the biggest delays can occur.

But the biggest benefit, is that you can simplify, and reduce the number of 
areas to maintain, it is the reason for my sql pam and nss modules I have 
been working on and going nuts on it.. I am thinking of a different system, I 
would love to use kerberos, but after looking at it.. I don't have a need for that 
level of system, and then again using DES, there is now programs that can 
crack DES in real time, so since it's pretty much internal anyways, I am 
working on a networked auth system.. for that purpose.. 

jason


On 17 Aug 2001, at 17:18, Erek Adams wrote:

Date sent:              Fri, 17 Aug 2001 17:18:04 -0700 (PDT)
From:                   Erek Adams <erek () theadamsfamily net>
To:                     Charles Henrich <henrich () sigbus com>
Copies to:              <snort-users () lists sourceforge net>
Subject:                Re: [Snort-users] DB Rules

> On Fri, 17 Aug 2001, Charles Henrich wrote:
>
> > It would be really cool if snort could read its rulesets from the database
> > source.  That way remote sensors who are talking directly to the central DB
> > server could get immediate rule updates, and make administration of a snort
> > network much easier.. (IMHO).  Whacha think?
>
> It could work.  But there are a few things about it that I don't like.
>
> 1)  Snort needs to be HUP'ed or restarted to re-load it's rules.  DB can't do
> that, so you'd need to script something. 2)  Ease of editing.  Now we've got one
> more layer between your admin and the rules.  I can't just 'vi fred.rules' and
> comment out what I don't want. 3)  One Basket.  Everything goes into a single
> point of failure. 4)  DB Availability.  What happens when net access to the DB
> goes away? Outage, blip, whatever--There will be times connectivity between them
> will go awry.
>
> Personally, I simply use ssh/scp and a shell script.  It allows me to push new
> rules, .conf files, new versions, etc. to each sensor without resorting to
> logging into them.  Again, this is my opinion only!
>
> This is kinda like the "Tomato or Tamato" debate.  :)  If it works for you, do
> it!  If not, make something that will work for you.
>
> Later!
>
> -----
> Erek Adams
> Nifty-Type-Guy
> TheAdamsFamily.Net



---
Jason Robertson                
Network Analyst            
jason () ifutureinc com    
http://www.astroadvice.com      

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users