[Snort-users] rules downloads and scalability

Paul Schmehl pauls at ...6838...
Mon Sep 18 13:52:33 EDT 2006

--On Monday, September 18, 2006 11:06:09 -0500 Eric Hines 
<eric.hines at ...8860...> wrote:

> Hash: SHA1
> I suppose Sourcefire's thinking is, which I think makes sense, say you
> download new rules at 9am and a new worm or pretty nasty exploit
> surfaces at noon. Then, new Snort signatures are released at 3:00pm. If
> it were limited to once a day, you wouldn't be able to grab those rules
> until 12:01am the next day :/
> But then again, you wouldn't be able to get them that quickly unless you
> were a VRT paid subscriber.. so that doesn't make sense.. :/ hmm..  I
> can't answer that one..


> Ok, here's another idea :) You have several Snort management solutions,
> each with its own method of managing Snort rules (we've got several
> customers like this) where you use your oink code to download rules for
> Snort management solution A and then you need to do the same for Snort
> management solution B. You can't download rules for B until the next
> day, so B will always be 1 day behind.

Here's a thought.  How about managing your own stuff instead of expecting 
the vendor to do it for you?

Write a script that checks for new rules and downloads them if it finds 
them.  Make sure the site is only accessible inside your own network.  (No 
sense in violating the rules and losing your rights to downloading the 
rules.)  Cron it for once a day, every six hours, whatever floats your 
boat.  Then point *all* your oinkmaster installs to the *local* site where 
the downloaded rules exist.  Or use one oinkmaster install to download the 
file and then point all the other oinkmaster installs to *that* file.  Then 
cron it as you like.

Problem solved.

> That about does it for me :) I suppose the answer to your question is,
> why not? Why tie people's hands more than you actually need to.. if
> every 15 minutes addresses the issue for Sourcefire, why do it longer
> like 24 hours?

I guess my answer would be why let the vendor manage your installation for 
you as opposed to actively taking care of your own stuff in a way that 
works best for *you*?

Paul Schmehl (pauls at ...6838...)
Adjunct Information Security Officer
The University of Texas at Dallas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 4085 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20060918/60836f4d/attachment.bin>

More information about the Snort-users mailing list