Re: EXTERNAL_NET: any vs !$HOME_NET

[Jason Brvenik <jasonb () sourcefire com>]

Hari Sekhon wrote:
> Ok, so I should split the intrusion detection into one for external by
> the borders and one or more for internal, but this still leaves me
> with the same problem that I want to detect as many things as possible
> as long as they aren't false alerts, again I would have to have
> EXTERNAL_NET as any and then have a huge amount of normal traffic for
> which I'd have to write pass rules, which is basically where I am
> already at.
>   

Not exactly. I don't know what kind of network or systems you are
dealing with but...

Try looking at HOME_NET and EXTERNAL_NET in this way.

HOME_NET is a list of systems you are interested in protecting.
EXTERNAL_NET is a list of systems you are interested in protecting
HOME_NET from.

For this discussion lets assume that you have a network like this.

DMZ = 10.2.2.0/24
Internal network = 10.1.0.0/16
Live Internet addresses = 72.73.74.0/24 ( NAT into the DMZ )

You might have four sensors that you use to monitor this setup.

On the internal sensor you would have HOME_NET set to 10.1.0.0/16 and
EXTERNAL_NET set to !HOME_NET
You would probably want to disable categories like icmp-info...

On the DMZ sensor you would have HOME_NET set to 10.2.2.0/24 with
EXTERNAL_NET set to !HOME_NET

You would likely want to monitor these two sensors closely. A third
sensor that we will call the "external" sensor would be on your uplink
just behind the firewall.  This sensor is nothing more than a sensor
that would be used to monitor for outbound attacks. Many rules would be
disabled entirely as they don't apply. HOME_NET would be set to
![10.1.0.0/16,10.2.2.0/24] and EXTERNAL_NET would be left as any.

Your fourth sensor would be inside and have a HOME_NET and EXTERNAL_NET
that are exactly the same.

In this way you have extreme flexibility and can monitor sensors
appropriately...


> How many servers do you run snort on, every server, or one or two (in
> which case it's not easy to see traffic to other hosts unless you have
> a switch that can monitor all ports (which I don't - and don't fully
> understand how you could even do this, the combined traffic from all
> ports would be much more than a single port monitoring host could
> handle). I've taken the web address of
>
>   
There are a variety of solutions that can solve this problem. There are
network solutions to mirror/SPAN traffic at varying speeds with
associated costs. Sourcefire has systems capable of monitoring up to 4
gigabits in a single 2U chassis. Bottom line is that it is not
intractable but may be impractical for your situation. More information
would be required to make specific recommendations. We architect
solutions for enterprise scale challenges every day so I'm confident it
can be done.
> I guess I would have to do a large amount of commenting out of rules
> and adding a lot of pass rules for normal network activity (which I
> have already had to do and looks like I will have to do much more of)
>   
It is the routine for monitoring solutions. Look at the threshold
keyword as a more manageable solution. Also look at oinkmaster to assist
in maintaining the rules across updates. Beyond that you probably have
to go commercial.
> It seems that the lesser of two evils for a lot of this stuff is to
> just blind myself to a lot of things and then hope what's left is
> enough.
>   
Pretty much ;)

It always comes down to time, money, and risk. If you skimp then you can
reduce any value but the other two will have to bear the burden.
> -h
>
> On 01/01/07, Jason Brvenik <jasonb () sourcefire com> wrote:
>   
> > Hari Sekhon wrote:
> >     
> > > I've currently got "var EXTERNAL_NET any" in my snort.conf and was
> > > considering making it "var EXTERNAL_NET !$HOME" instead, but looking
> > > at the rules files, it seems that most rules will immediately
> > > disregard any suspicious traffic from your HOME_NET in this case,
> > > which basically blinds you to any internal threats.
> > >       
> > Correct. A proper deployment will have systems monitoring external
> > threats and a different system monitoring internal threats. You could
> > also run multiple instances of Snort on the same machine with different
> > interfaces and configurations. This is a less preferred method but often
> > makes budget happier. You should be aware that bridging an external and
> > internal network with _any_ device regardless of purpose has a certain
> > amount of risk involved.
> >
> >     
> > > I am also running snort on several servers that are not publicly
> > > accessible (ie port forwards) but want to be able to see malicious or
> > > suspicious traffic from all networks.
> > >
> > > The current problem with the EXTERNAL_NET any is that a lot of rules
> > > are throwing up too many false positives and it's very difficult to go
> > > around writing pass rules for every other packet that goes through the
> > > network interface (I exaggerate slightly)
> > >       
> > You are asking too much of one system and configuration. If you needs
> > are more complex and detailed, you should move to a more complex and
> > detailed configuration.
> >
> >     
> > > It's seems a very difficult juggling act to on the one hand stop false
> > > positives and
> > > on the other to not totally negate the worth of the ids by making it too loose.
> > >       
> > It is until you split the functions up into more manageable chunks.
> >
> >     
> > > For example I have stacks of "MS Terminal server request RDP" alerts
> > > coming from machines on my home net. I can see how changing the
> > > EXTERNAL_NET would be a good idea to stop these unless they come from
> > > outside the network, but considering that this also stops most rules
> > > from matching if somebody attacks from a machine within the building
> > > or any remote site connected via vpn (which are included in HOME_NET
> > > and therefore excluded from EXTERNAL_NET)
> > >
> > > Anybody got any advise on this?
> > >       
> > Create external, internal, VPN, and B2B segments and then monitor each
> > appropriately. Each zone has a different threat perspective and should
> > be monitored with different rules and configurations.
> >
> >     
> > > --
> > > Hari Sekhon
> > >
> > > -------------------------------------------------------------------------
> > > 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
> > >
> > >       
>
>
>   


-------------------------------------------------------------------------
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