Snort mailing list archives
Re: rules downloads and scalability
From: Paul Schmehl <pauls () utdallas edu>
Date: Mon, 18 Sep 2006 12:52:33 -0500
--On Monday, September 18, 2006 11:06:09 -0500 Eric Hines <eric.hines () appliedwatch com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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 () utdallas edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Attachment:
_bin
Description:
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ 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
Current thread:
- rules downloads and scalability Jason Haar (Sep 17)
- Re: rules downloads and scalability Eric Hines (Sep 17)
- Re: rules downloads and scalability Eric Hines (Sep 18)
- Re: rules downloads and scalability Martin Roesch (Sep 18)
- Re: rules downloads and scalability Paul Schmehl (Sep 18)
- Re: rules downloads and scalability Eric Hines (Sep 18)
- Re: rules downloads and scalability Paul Schmehl (Sep 18)
- Re: rules downloads and scalability Bristol, Gary L. (Sep 18)
- Re: rules downloads and scalability Eric Hines (Sep 18)
- Re: rules downloads and scalability Eric Hines (Sep 17)
- <Possible follow-ups>
- Rules Downloads and Scalability Mike Guiterman (Sep 18)