IDS mailing list archives

Re: Changes in IDS Companies?


From: Aaron Turner <aturner () pobox com>
Date: Mon, 28 Oct 2002 18:07:30 -0800

On Mon, Oct 28, 2002 at 09:23:04AM -0500, Matt Harris wrote:
There's also the option of using a non-inline style IDS, but having it
utilize an in-line device which should, theoretically, already be
present on your network border to handle blocking of traffic (such as
router ACL's, which is what Cisco's IDS does by default, or adding and
managing temporary firewall rules, etc).  This seems to work well, and
since the actual IDS work is done on a different host than the network
traffic passing, the actual performance hit is very limited in that you
won't see more of a hit than you will if you were using ACL's or
firewall rules anyways, which most security-concious folk are.  

A number of problems with this:

1) Futzing with router ACL's or firewall policies via your IDS is not granular.
They don't drop a specific connection (the attack) but rather all traffic on
a given port for a client/server.  This can have very ugly effects for
legit traffic.

2) It's too late.  The attack has already reached the target.  Consider 
something like jill.c which exploits the IIS-ISAPI buffer overflow and 
opens a connection back to the attacker on another port and you'll quickly
understand why this method of "protection" is more hype than reality.

3) Many attacks are internal.  Most firewalls are at the border, hence
there's nothing the firewall can do, unless you (re)deploy more firewalls.

Note that TCP resets that some vendors claim as intrusion protection are
even worse.  Not only is it only effective against TCP, but you've got to
get the reset inside the window.  This sounds simple until you consider
many attacks come from the internal employees on your high-speed LAN.

-- 
Aaron Turner <aturner at pobox.com|synfin.net>    http://synfin.net/aturner
They that can give up essential liberty to obtain a little temporary safety 
deserve neither liberty nor safety. -- Benjamin Franklin

pub 1024D/F86EDAE6  Sig: 3167 CCD6 6081 0FFC B749  9A8F 8707 9817 F86E DAE6
All emails by me are PGP signed; a lack of a signature indicates a forgery.

Attachment: _bin
Description:


Current thread: