First, a promiscuous NIC connected outside the firewall presents 'only' the
risk associated with having no TCP stack bound to an existing (but not
broadcasting) MAC address. Connecting it to inside the firewall via a second
NIC does not necessarily bypass or short-circuit the firewall. The interface
outside is still vulnerable to weapons of mass destruction for the collision
domain segment, and there are some creative attack paths conceivable, but I
have not yet heard of anyone implementing anything (anyone else?) yet.

Second, there is trade-off with read-only connections for an IDS capable of
reacting with RSTs and the like - RSTs will not work through a read-only
connection. You can end up with a watchdog capable of barking, but not
biting...
I have seen each method be appropriate to differing situations - what have
you seen?
dcdave
----- Original Message -----
From: "Chris Keladis" <Chris.Keladiscmc.cwo.net.au>
To: "Crist Clark" <crist.clarkglobalstar.com>
Cc: "Ingersoll Jared" <JIngersollcswv.com>; <FOCUS-IDSsecurityfocus.com>
Sent: Friday, June 08, 2001 5:59 PM
Subject: Re: Retreiving information from IDS..

> Crist Clark wrote:
>
> > I sometimes wonder how often the dual-NIC approach is more of a
liability
> > than advantage. I suspect people may frequently be doing things like
> > short circuiting a firewall with such a device. You need to balance
> > your NIDS software requirements, the costs of adding the second NIC (the
> > cost of the NIC are insignificant, but the costs or other problems for
> > wiring the second network connection may not), and the security risks
> > of the configurations (again, two NICs is not automatically more secure
> > than one). As always, real-world security is about reducing risk, but
> > balancing it against the cost.
>
> After some research and many peoples helpfull suggestions, i'm going to
look
> into the Shomiti 100BT ("Century") Ethernet taps.
>
> We need HA, and the Shomiti taps claim to pass traffic even if the units
lose
> power which is a big plus to us.
>
> I also would prefer to avoid putting hubs in production segments degrading
their
> performance (or port-mirroring etc..)
>
> (This was just for the "dirty"-side IDSs btw)
>
> Anyway, the taps are read-only (or so i understand), which imposes a
hardware
> restriction, reducing the risk of compromising the IDS itself.
>
> It's not fail-safe (espescially if one has physical access), and i agree,
the
> risk needs
> to be weighed up, but at least this helps reduce the risk, as IDS does add
> security-value
> to complement a Firewall.
>
>
>
> Regards,
>
> Chris.
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]