RE: IDS evaluations procedures

["Nathan Davidson" <ndavidso () globix com>]

Good point Mike, you have to take into account the collateral damage caused by enforcing such policies. In most cases 
you can tune a policy to loose the minimum of non-mainstream browsing whilst still tightening security. I tend to leave 
the IPS policy in a non-blocking mode for a few days after implementation to catch the inevitable deviations from 
HTTP1.1 browsing and the like. This burn-in period also allows the IPS to maintain flow data on existing connections 
thus removing the likelihood of incorrectly mitigation established flows.

 

 There are sometimes cases where you just can’t enforce as tight a policy as you would like because of the application 
or client end being poorly implemented. However, if you take the situation of an online retailer, you may wish to 
implement a loose policy for the brochure ware site and a much tighter policy for the eCommerce component. That way 
someone browsing the site on an HTTP1.0 device will be able to at least look up a price and get the sales phone number.

 

With the advent of ever more tightly policed application standards (see IPS,application firewalls, layer 7 proxies, 
etc) I suspect that non-compliant browsers, tools and monitors will soon have to get their act together or be left 
behind. 

 

Nathan 

 

 

-----Original Message----- 
From: Mike Frantzen [mailto:frantzen () nfr com] 
Sent: Mon 18/07/2005 15:29 
To: Nathan Davidson 
Cc: focus-ids () securityfocus com 
Subject: Re: IDS evaluations procedures

 

> An example would be to use an IPS to force all HTTP requests to have the host header www.xyz.com (your sites URL) 
> this will stop a significant proportion of HTTP noise before signature matching.

As IPS developers we have to be very careful with IPS optimizations like
this. They work well in some sites but break horribly in others.

Your example will block most HTTP/1.0 requests that don't require a
Host: header. Many upness checkers won't bother with a well formed HTTP
request so your site will appear down and someone may get paged and get
very cranky figuring out why everything works but the website-is-up
checker. Likewise it will run into a cold-start problem when a
connection is already live and sent the packet containing the Host:
header just before the IPS began monitoring.

.mike
frantzen@(nfr.com | cvs.openbsd.org | w4g.org)
PGP:  CC A4 E2 E8 0C F8 42 F0  BC 26 85 5B 6F 9E ED 28

 

        -----Original Message----- 
        From: Mike Frantzen [mailto:frantzen () nfr com] 
        Sent: Mon 18/07/2005 15:29 
        To: Nathan Davidson 
        Cc: focus-ids () securityfocus com 
        Subject: Re: IDS evaluations procedures
        
        


        > An example would be to use an IPS to force all HTTP requests to have the host header www.xyz.com (your sites 
URL) this will stop a significant proportion of HTTP noise before signature matching.
        
        As IPS developers we have to be very careful with IPS optimizations like
        this. They work well in some sites but break horribly in others.
        
        Your example will block most HTTP/1.0 requests that don't require a
        Host: header. Many upness checkers won't bother with a well formed HTTP
        request so your site will appear down and someone may get paged and get
        very cranky figuring out why everything works but the website-is-up
        checker. Likewise it will run into a cold-start problem when a
        connection is already live and sent the packet containing the Host:
        header just before the IPS began monitoring.
        
        .mike
        frantzen@(nfr.com | cvs.openbsd.org | w4g.org)
        PGP:  CC A4 E2 E8 0C F8 42 F0  BC 26 85 5B 6F 9E ED 28