Snort mailing list archives
Re: Snort multiple sensor configuration
From: "Stephen Reese" <rsreese () gmail com>
Date: Thu, 9 Oct 2008 13:23:17 -0400
I am of the opinion that dropping *any* packets is bad.
Good call, those couple of missed NOP's could be the evil bastards trying to attack :-).
You have three connections, one before the firewall, one after, and one inside the network. I agree with Jack -- nix the connection outside the firewall. It's a waste.
I see the point here and I'm probably missing something but what if we wanted to know where an attack was coming from or if one of our machines were attacking another network and I needed to know what network so I could disclose to them what was happening? We are performing NAT aka PAT on the internet connection.
The one connection after, I'd keep your variables as you have them, HOME_NET configured, and EXTERNAL_NET as !$HOME_NET.
Keep them as I have them and remove the external class A WAN ip?
Then, on the inside connection, i'd have your HOME_NET configured as your internal network (treating your firewall/dmz/router as external), and your EXTERNAL_NET configured as "any".
This part is a little confusing to me but let me explain this part of the network a bit better. 172.31.1.0 is the main network (sensor) <router> 172.31.2-5.0 are the remote network connect via T1 which *shouldn't* be carrying internet traffic, just access to various internal network services from the main network to the branch visa-verse. Your saying that defining HOME for this sensor as all of our internal networks will cover the bases or should I just have the only HOME network as 172.31.1.0 and EXTERNAL as any.
That way you will see traffic going out of your network, coming into your network; as well as traffic coming into your network from your perimeter (in case one of those gets compromised), then you will also see traffic going from your internal hosts, to your other internal hosts (in case a virus starts spreading or similar).
I know everything network is unique and it takes quite a bit of tuning to get this right. I just want to be able to say hey look that host is being attacked but something from the outside, where is it coming from or going to or that host 172.31.1.X is being attacked by a branch network host 172.31.3.19. Thanks again for the help everyone.
On Thu, Oct 9, 2008 at 11:15 AM, Stephen Reese <rsreese () gmail com> wrote:in a multi-nic deployment dropped packets are the biggest concern. Watch the dropped packet counts closely. more than 5% means you're wasting your time.I don't think I'm doing do bad in regards to the packet loss, the links to the internet and branch networks are not very fast the the machine is decent, 3.2 intel with 4 gigs of ram on a 64 debian OS. Oct 9 06:55:05 atlas snort[5260]: Packet Wire Totals: Oct 9 06:55:05 atlas snort[5260]: Received: 5100680 Oct 9 06:55:05 atlas snort[5260]: Analyzed: 5099871 (99.984%) Oct 9 06:55:05 atlas snort[5260]: Dropped: 808 (0.016%) Oct 9 06:55:05 atlas snort[5260]: Outstanding: 1 (0.000%) Oct 9 06:56:31 atlas snort[5257]: Packet Wire Totals: Oct 9 06:56:31 atlas snort[5257]: Received: 1855372 Oct 9 06:56:31 atlas snort[5257]: Analyzed: 1855129 (99.987%) Oct 9 06:56:31 atlas snort[5257]: Dropped: 242 (0.013%) Oct 9 06:56:31 atlas snort[5257]: Outstanding: 1 (0.000%) Oct 9 06:57:08 atlas snort[5254]: Packet Wire Totals: Oct 9 06:57:08 atlas snort[5254]: Received: 1989644 Oct 9 06:57:08 atlas snort[5254]: Analyzed: 1989643 (100.000%) Oct 9 06:57:08 atlas snort[5254]: Dropped: 0 (0.000%) Oct 9 06:57:08 atlas snort[5254]: Outstanding: 1 (0.000%)Sniffing outside of a properly configured firewall is wasteful. Do you really need an IDS to tell you that the firewall is blocking lots of bad traffic? It's a firewall! That's what it does! Make sure it's configured correctly, make sure it's a quality firewall, then let it do it's job. If you don't trust your firewall, solve that before deploying an IDS. Crappy firewalls are a curse because once it's installed you're usually stuck with it. Most IT organizations cannot politically repace a "working" firewall with a "good quality" firewall. It's usually not about money, it's usually about brand loyalty, training curves, fancy reporting tools, and religion.I understand this, I'm probably just reading in to some of the examples I've seen floating around. The firewall is a new Cisco ASA model which is nice but only so nice as it's configuration, hmm, now that I think about it maybe it has a method to monitor traffic on it's interfaces.Once you trust the firewall, you can stop trying to process packets that are never going to reach your network anyway. You can't defend a network that does not have rock-solid firewall protection. Don't load up "all the rules". If you load up too many rules, you will be dropping packets. If you can keep the dropped packet counts down (<5%), your IDS will function very nicely. When the IDS is new, you need to find out what's "normal" for your network and tune the sensor to understand "normal". Start by unloading application exploit rules and loading up "equipment misconfiguration" rules. Load up rules that indicate heretofore unknown problem areas, like clear text passwords and devices sending out TFTP broadcast requests. Misconfigured devices, leaking firewalls. Solve all those problems first. You can't defend a jacked-up network. Once all those rules go quiet, load up the malware and spyware rules. Fix those problems. At this point you will observe that you need a black-hole DNS server. Once all *those* rules go quiet, you can really run a tight defense against the remaining problems as they come up. Or you can just make pretty charts all day and possibly get a pay raise and a promotion. ;)mmm, charts, base :-) anyhow thank you for your insight, I'll keep hammering away and see if I can get some useful information out of this. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ 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-- Joel Esler Cell: 706-231-1451 AIM: eslerjoel [m]
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ 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:
- Snort multiple sensor configuration Stephen Reese (Oct 08)
- Re: Snort multiple sensor configuration Jack Pepper (Oct 09)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Message not available
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Message not available
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Re: Snort multiple sensor configuration Joel Esler (Oct 10)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 10)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Re: Snort multiple sensor configuration Jack Pepper (Oct 09)
- Re: Snort multiple sensor configuration Matt Olney (Oct 09)
- Re: Snort multiple sensor configuration Jack Pepper (Oct 09)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Re: Snort multiple sensor configuration Matt Olney (Oct 09)