[Snort-users] Snort multiple sensor configuration

Stephen Reese rsreese at ...11827...
Thu Oct 9 13:23:17 EDT 2008


> 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 at ...11827...> 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 at 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]
>


More information about the Snort-users mailing list