This is a discussion on Re: [Snort-users] *very* many snort installations.. within the Snort forums, part of the System Security and Security Related category; In most successful IDS setups, there is already a snort box behind your firewall, configured on the switch to be ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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/...fo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.p...st=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/...fo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.p...st=snort-users |