[Snort-users] Snort and ipchains

Bob McDowell bmcdowell at ...7861...
Wed Jan 8 09:15:06 EST 2003

Good point.  I should have mentioned that up front:  I have (will have) 5
firewalls.  One border, one for each type of different service we will host,
and an ISA box that defines the DMZ.  Each firewall is configured to 'fail
closed'.  They are also the 'invisible bridging' variety, so they'll be hard
to directly assault.

As an aside, I do not trust snort to modify my firewall rules.  I don't
really advocate automatically putting things on your block lists.  The
computer isn't really educated well enough to make that kind of a decision.
I also wouldn't trust the computer to explain it's decision to my boss...

I do, however, advocate layering snort behind static firewall rules to
examine/audit the traffic that does get through.

So, even though I'm not expressing myself correctly, I think we agree...

-----Original Message-----
From: snort-users-admin at lists.sourceforge.net
[mailto:snort-users-admin at lists.sourceforge.net]On Behalf Of Matt
Sent: Wednesday, January 08, 2003 10:38 AM
To: snort-users at lists.sourceforge.net
Subject: RE: [Snort-users] Snort and ipchains

At 03:17 PM 1/7/2003 -0600, you wrote:

>I, for one, am on the 'every little bit helps' list.  Any device may
>fail/be exploited/be misconfigured.  Its all about layers.  If I'm going
>to have snort alert, why not have it interfere also?  Obviously I plan on
>thinking worst case and configure all devices accordingly (so they might
>last ten seconds if there were no firewall at all), but for the price why
>not try and leverage snort also?

Actually, your reasoning is exactly why I oppose letting snort modify the
firewall... "any device may fail/be exploited/be misconfigured" includes my
snort box. I favor isolating the failure of the two systems (the snort box
and the firewall box) so that a failure or exploit of one does not imply
failure of both. auto-configuring a firewall from a snort box means that
should the snort box be exploited, it's game-over for your firewall, since
the snort box has the power to reconfigure the firewall and the attacker
can now just re-do it as a "wide-open".

It's all about layers... isolated layers that fail independently and not in
giant cascades, but that's really a matter of different security

There's also an argument that "if you know about an attack and can detect
it, you should already be immune" but I tend not to favor that argument
against auto-firewall-snort setups. Let's face it, most attackers tend to
use a variety of attacks and may start off with some common old attacks
before trying fancy stuff. Blocking them off as soon as they try anything
is worthwhile in protecting you against the "fancy stuff".

I guess the "best" case is to have a fixed-config firewall out front, with
an inline-snort box behind it doing dynamic blocking on a second firewall.
This way the firewall on the snort box is only an "extra" layer that is not
a single-point-of-failure for your networks firewall. I can definitely see
the "every bit helps" argument if you have the resources to set up a
dual-firewall environment.

I'd certainly make sure there's some very careful consideration of what
happens to your network if the snort box is hacked, and make sure it
remains secure even if that box is exploited. I prefer to be able to prove
that hacking it is impossible or worthless (ie: if the snort box cannot
send data to any network because it's only connected by a one-way-tap,
exploiting it is most likely impossible, the best you could likely do is a
DoS of some form that only affects the snort box.)

This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
Snort-users mailing list
Snort-users at lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
Snort-users list archive:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20030108/2416728e/attachment.html>

More information about the Snort-users mailing list