Re: New rules keyword error

["John Creegan" <jcreegan () questarweb com>]

It seems to me that it would not be difficult to create a script into
which one could wrap the rule update process, whether that be oinkmaster
or one of the other scripts I've seen that does the work of
auto-updating.

In that script, one could use an instance of snort, even if there's
only one box doing IDS, to test the new ruleset (pointing to an
alternate ruleset).  Snort puts out plenty to know if it didn't start
because of a malformed rule or if there were daemon errors starting up
or whatever.  If no errors, fold in the new rules and restart the
production snort(s).  If errors, either go into babysitting mode or wait
for another day.

Unless I'm missing something, this seems to me the best of both
worlds.

However, unless I create something like that, I'll never auto-update
(lights out mode) either.  And even if one of the snort mountaineers put
out a realist stating that they'd already done this, I'd still be with
Erek on this one, if for no other reason than I'm from the days when
corruption in file transfer was a little too common, but primarily
because my boss trusted my opinion to go with a freeware product saving
my bucks.  The last thing I wanna do is say, "Yeah, I know... I missed
that attack and this entire group is now sittin' around twiddling their
thumbs.  Yeah, we have to rebuild all these systems now, and yeah,
money's flying out the window and we're missing deadlines.  Sorry about
that.  It's the rule maintainers' fault.  What can I do?"  I wouldn't
expect my boss to trust me or snort much after that.  Going beyond that,
if enough auto-updates fail often enough, might not the non-security
savvy folks (the ones that can't separate out the various functionality
of the product) start saying that the entire snort product is crap? 

Too, and making certain to say that no one has expressed any
unappreciation for the snort rule maintainers, I think that whomever(s)
is/are updating the rulesets is doing it as volunteer work.  If they
screw up from time to time, who am I to complain?  I'd much rather focus
on the many days these nice folks get it right.

Of course, all this is my opinion.  I could be wrong.

> > > "Marc Quibell" <mquibell () fbfs com> 10/22/03 03:54PM >>>



DANG! I thought I WAS getting the stable release! Doh! THanks..

Cheese,

Marc


On Wed, 22 Oct 2003, Marc Quibell wrote:

> Er...What?
>
> Auto-updates are only bad if you screw them up, no?

Ummm...  No.  Auto-updates are bad <period>.

<Gratiuitous Princess Bride Reference>

  "Lemme 'splain."

</Gratiuitous Princess Bride Reference>

In doing auto-updates, you make an assumption.  You assume that the
source
is 100% perfect and pristine.  Now, call me a paranoid person (And
they
are out to get me!), but unless I can "control" the server I update
from...  It's not secure, pristine or perfect.  I don't trust other
people
when it comes to something as mission critical as an IDS.

Consider this:  You have all 100 of your sensors over your enterprise
setup to pull from Snort.org for rule updates.  You update.  There
happens
to be a corrupt file (hey, it happens).  All of your sensors are now
screwed.  Want to explain that to your boss?  "All of our stuff broke
because I trusted someone else."

Scenario 2:  There is a human error on the remote side.  Something is
introduced into the mix that breaks something on your side.  "Well
boss,
it worked fine until they changed it."

Bottom line:  I don't trust what I can't control.  I auto update from
my
own 'update' box--That I manually push rules to.  I don't know about
your
shop, but I can't afford the luxury of trust.

> Now why were they screwed up? Are you saying that the old
nomenclature
> for "CVS Stable" no longer applies to snort 2.0.x?

Nope.  I'm saying you're grabbing the snort-current.tar.gz ruleset. 
Snort
uses a 'normal' development model.  -STABLE is just that 'stable'.
-CURRENT is the "bleeding edge".  Grab the -STABLE ruleset and all
should
be well.  And also remember that the SourceForge CVS servers are about
24-32 hours behind.

> Snort is no good w/o auto-updates..no time to babysit processes.

I can't agree with you on that.  For something as critical as an IDS,
I
_make_ time to babysit if need be.

Cheers!

-----
Erek Adams

   "When things get weird, the weird turn pro."   H.S. Thompson




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win
$100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 
_______________________________________________
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


This message (including any attachments) contains confidential 
information intended for a specific individual and purpose, 
and is protected by law.  If you are not the intended recipient,
you should delete this message and are hereby notified that any 
disclosure,copying, or distribution of this message, or the taking 
of any action based on it, is strictly prohibited.



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
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