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
