Snort mailing list archives
Re: *very* many snort installations..
From: "Shane Smith" <shane () crownbank com>
Date: Wed, 26 Nov 2003 10:16:50 -0500
In most successful IDS setups, there is already a snort box behind your firewall, configured on the switch to be a "mirror port" for all traffic. Simply putting Snort boxes in front of your firewall's isn't enough, as you won't know exactly what gets through. A setup with both and inside and outside sensor, will show you both attempted intrusions and actual intrusions respectively. Also, an internal sensor can be used for policy management and compliance, such as making sure no p2p traffic is flowing inside your network. As far as installing Snort on *every* workstation, that seems very redundant. You should only need one sensor on any physical segment, since all the workstations would be watching the same traffic. This could cause several hundred alerts to be triggered, even for just one bogus packet. For management, I've had success with oinkmaster (http://oinkmaster.sourceforge.net/) auto-updating the rule sets. While I haven't run into problems yet, I loath the day a bad rule sneaks it's way into an update, and snort doesn't start back up. I use BigBrother (http://bb4.com) to watch all my sensors, and make sure the snort service is running. In the scenario you describe, it would almost be worthwhile to have a separate BB4 installation just to monitor all your Snort sensors. You can also use BB4 to watch a logstream, or in my case a MySQL db with all your alerts. External alerts (attempted intrusions) don't raise any alarms until traffic becomes excessive, but any alert on an internal sensor (potentially an intrusion) causes the bells and whistles to go off. The thing to remember with Oinkmaster is that once implemented, you do most of your ruleset configuration there, instead of in snort, otherwise changes you make will be overwritten during any update. If you script this, you can do like I do, and have the script retrieve an updated ruleset config file prior to any update from a central location. Doing this, will cause all your sensors to have the same, current rules, and you only need modify one file. The previous ruleset used is stored "just in case" I need to rollback. On a large deployment, needing to role back could be a real pain, and you don't want to be left snortless until you do. I suggest additional scripting, and possibly having your oinkmaster script check your central repository for updates frequently. Then if you need to role back, if you scripted and configured everything correctly, you could simply change your central ruleset again, and wait for that update to propagate, and snort to start back up. So yes, you can *fake* central management of Snort via scripting on your sensors, and watch them all via BigBrother. It may be a pita to get there, but you'll be very happy when you do. That's my story.... -Shane ----- Original Message ----- From: "Mokum" <snort () meij net> To: <snort-users () lists sourceforge net> Sent: Wednesday, November 26, 2003 8:45 AM Subject: [Snort-users] *very* many snort installations.. Greetings, I was requested to look into the possibility to install snort as a service on 'all' [XP only] workstations [*way* over 10.000] of a very large, very global organization. The goal is to have a better insight in the 'known bad' data flows though out the network. Of course, the main parts of the network are already IDS'ed so the workstation installation would be a sort of extended sensorium to make sure we see things behind the routers, switches, nat'ing devices & firewalls that normally go undetected untill things go really really wrong. The well known pitfalls of rollouts like these that I am aware of are: - the managebility: - collection of events - the number of the events - the QA - snort.exe - stability of the service - resources needed - quality of the rules implemented Not my problem is: - the installation & distribution of the service, this is done for about 1000 other applications too. - the updating of the rules [is part of the distribution] My question is if anybody on the list has expirience [good or bad] with a concept like this? Any pointers? Cheers, mokum ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! 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 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! 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
Current thread:
- *very* many snort installations.. Mokum (Nov 26)
- Re: *very* many snort installations.. Shane Smith (Nov 26)
- RE: *very* many snort installations.. Michael Steele (Nov 26)
- RE: *very* many snort installations.. Jason Haar (Nov 26)
- <Possible follow-ups>
- RE: *very* many snort installations.. hugh_fraser (Nov 28)
- Re: *very* many snort installations.. Adriel T. Desautels (Dec 02)