Date: Sat, 07 Apr 2001 14:48:13 -0700 From: "Crist Clark" <crist.clark@globalstar.com> To: "Jacques A. Vidrine" <n@nectar.com> Cc: lee@kechara.net, freebsd-security@FreeBSD.ORG Subject: Re: Theory Question Message-ID: <3ACF8B1D.21272C1C@globalstar.com> References: <200104071610.RAA18117@mailgate.kechara.net> <3ACF83FA.55761A7B@globalstar.com> <20010407162552.D87286@hamlet.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jacques A. Vidrine" wrote:
>
> On Sat, Apr 07, 2001 at 02:17:46PM -0700, Crist Clark wrote:
> > A possible scenario: Your IDS is listening to the unprotected link to
> > the Internet and chugging away, crunching the data passing by looking
> > for attack signatures. Hiding somewhere in the bowels of this large
> > and complex IDS program[0] is a buffer overflow vulnerability. EvulHax0r
> > sends a crafted series of packets past the box which trip the buffer
> > overflow and execute arbitrary code of his choosing on the box. Game
> > over. His code could attach an IP stack to the external interface
> > (just run ifconfig), it could open a tunnel through the backside of
> > the IDS and back out of the front[1] of your network, or if EvulHax0r
> > is really 33l33t, he could set up a covert channel on the external
> > interface that does not use the kernel stack.
>
> This is why you physically cut the TX wires to the network. That buffer
> overflow can still be successful, and the machine can still be
> comprimised, but it cannot be used to make further attacks. The types
> of comprimises are also limited, since the attacker must work blindly.
As I pointed out, it may be possible to use the machine for further
attacks even with physically disabling transmission on the external
interface. One could conceive of quite a number of ways to establish
a tunnel from the internal interface of the IDS, through the firewall,
and back out onto the Internet.
> Of course, the problem is then how do you get useful information out of
> your IDS?
Were you indicating to disable transmission on the internal interface?
Then why hook it up to the internal network at all? That defeats the
purpose of the original poster's design.
Going back to the original problem, IMHO, if you want to have data
connectivity with the IDS, a fairly secure way to go is to have one
or more serial connections to the IDS from the inside.
} {
Internet }----+---[Firewall]----{ Protected network
} | { |
[IDS]..................[IDS Mngmnt]
(serial line(s))
For example, you could have one console connection and one data connection
passing the logging info. The possibility of an attacker gaining further
access into your network if the IDS is comprimised is small (but as always,
non-zero), and you have all of the access you need to the system. The one
caveat being the data rate limitation on a serial line. (And serial lines
are even worse when it comes to TEMPEST, but not too many people need
concern themselves with that.)
--
Crist J. Clark Network Security Engineer
crist.clark@globalstar.com Globalstar, L.P.
(408) 933-4387 FAX: (408) 933-4926
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact postmaster@globalstar.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ACF8B1D.21272C1C>