Re: Changes in IDS Companies?

From: Matt Harris (mdh@unix.si.edu)
Date: 10/29/02 

Date: Tue, 29 Oct 2002 09:28:08 -0500
From: Matt Harris <mdh@unix.si.edu>
To: Aaron Turner <aturner@pobox.com>, focus-ids@securityfocus.com

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
 *
 */

Relevant Pages

  • Re: IDS on Switched Networks
    ... connecting a network IDS to it would be fine. ... Higher state of alert you know what attacks you are ... If your firewall has NAT turned on, ...
    (Focus-IDS)
  • Re: Firewall or IDS
    ... You can actually use IPSec on Win2K to do the same thing - plus you can ... PIX firewall will not be ... >> able to defend against application layer attacks like Code Red. ... A network IDS won't be able to defend against Code-Red-like attacks as soon ...
    (Focus-Microsoft)
  • Re: Securing against an internet based intrusion
    ... That is the job of a firewall to prevent a user from the internet from ... fashioned password attacks. ... the administrators password? ...
    (microsoft.public.windowsxp.security_admin)
  • RE: amount of alarms generated by IDS
    ... Obviously to manage, control, and mitigate these types of attacks it is ... "They used to read the 3000ppm water monitor with a magnifying glass." ... amount of alarms generated by IDS ... The comparison is more appropriately made as a firewall with the ability ...
    (Focus-IDS)
  • Re: Theory Question
    ... Your IDS is listening to the unprotected link to ... His code could attach an IP stack to the external interface ... but it cannot be used to make further attacks. ... and back out onto the Internet. ...
    (FreeBSD-Security)