Date: Sat, 7 Apr 2001 14:53:11 -0700 From: "John Howie" <JHowie@msn.com> To: "Jacques A. Vidrine" <n@nectar.com>, "Crist Clark" <crist.clark@globalstar.com> Cc: <lee@kechara.net>, <freebsd-security@FreeBSD.ORG> Subject: Re: Theory Question Message-ID: <058701c0bfad$265e8530$0101a8c0@development.local> 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
I didn't see anyone state the obvious: have a separate monitoring network that is not attached to your production (i.e. behind the interior DMZ firewall) network. If the IDS box is compromised then it could be used to launch attacks against other connected networks. By having it on a separate monitoring network you prevent this scenario. In practice a machine with no IP address that just receives packets is not likely to be vulnerable. Crist's scenario is not a probable one (as he, himself, acknowledges). However, you might find yourself in a situation where a DoS is created against the IDS itself which means that it won't recognise the activity it was deployed to catch. john... ----- Original Message ----- From: "Jacques A. Vidrine" <n@nectar.com> To: "Crist Clark" <crist.clark@globalstar.com> Cc: <lee@kechara.net>; <freebsd-security@FreeBSD.ORG> Sent: Saturday, April 07, 2001 2:25 PM Subject: Re: Theory Question > 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. > > Of course, the problem is then how do you get useful information out of > your IDS? > > Cheers, > -- > Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message 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?058701c0bfad$265e8530$0101a8c0>