Date: Sat, 7 Apr 2001 22:16:52 -0500 (CDT) From: James Wyatt <jwyatt@rwsystems.net> To: John Howie <JHowie@msn.com> Cc: "Jacques A. Vidrine" <n@nectar.com>, Crist Clark <crist.clark@globalstar.com>, lee@kechara.net, freebsd-security@FreeBSD.ORG Subject: Re: Theory Question Message-ID: <Pine.BSF.4.10.10104072029260.31820-100000@bsdie.rwsystems.net> In-Reply-To: <058701c0bfad$265e8530$0101a8c0@development.local>
next in thread | previous in thread | raw e-mail | index | archive | help
If you have a large network to protect, maintaining a separate monitoring network for out-of-band control (of the main network which is subject to attack) can be pretty costly. I've seen VLANs suggested for large outfits, but that can be attacked at the switch level. You can use voice channels and PPP over serial, but filter the heck out of it and don't set a default route. At some point you will have to network to your IDS box if you want much functionality from it. If you simply have the box set to log out the serial port, it can be easily overrun (DoSed) if you have a good net connection. If you do enough, the easiest attack is to plant a contractor on your staff and have them work from the inside out anyway... - Jy@ On Sat, 7 Apr 2001, John Howie wrote: > 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 > 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?Pine.BSF.4.10.10104072029260.31820-100000>