IDS mailing list archives

Re: Changes in IDS Companies?


From: Matt Harris <mdh () unix si edu>
Date: Tue, 29 Oct 2002 09:28:08 -0500



Aaron Turner wrote:

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.

Generally, this is done on a basis of simply blocking all inbound
traffic from the offender's IP address.  Hence entirely blocking the
effective attack as well as anything else they may try for the next X
number of seconds/minutes/whatever.  


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.

If people are running insecure web servers, then is it really the
network infrastructure's job to protect them?  I'm thinking more along
the lines of protecting against flood attacks, port scans, and the like
- from smurfs to simple icmp floods, etc.  In addition, blocking at the
border router level can be even more useful for this, since it stops it
before it gets to the IDS, Firewall, etc, and hence saves them some
processing time for legitamate traffic.  It's not a perfect solution to
all problems, but IMO the only real solution has to be at every level -
I only go so far with network based security, and rely on host based
security for the rest.  Exploits just shouldn't work against systems,
and if they do because some admin was lazy, then it shouldn't be my
IDS's job to protect their lazy selves.  ;-)
Security is everyone's concern.  If it isn't a particular person's
concern, then they'll be the ones to have to fix or rebuild their
systems.  
But that's a philosophical and business difference for a lot of people. 
I'm in a place where business decisions don't affect things since we're
not running a business.  And as far as philosophy, see above.  


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.

True enough.  Deploying internal firewalls and IDS's is definitly not a
bad thing, if not in fact even a good thing.  Most of the attacks I see
internal are unintentional user-mishaps, I've yet to see any genuine
malicious activity.  But nonetheless, we try to be prepared. 
Statistically here, about 99% of attacks outside of individual subnets
(I have no way of monitoring what may go on within a seperate subnet,
though I think the help desk would be getting calls if something bad
happened that affected users adversely), come from the internet.  So,
that is where the effort here is in fact concentrated.  


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.

And we have a gig backbone.  I've actually tested some TCP reset
configurations, it never once worked for me.  Not a single time, even
when running stuff from my cable modem-connected system at home against
our network here.  


--
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.

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature

-- 
/*
 *
 * Matt Harris - Senior UNIX Systems Engineer
 * Smithsonian Institution, OCIO
 *
 */


Current thread: