Re: IDS and SSL

[<me () silvexis com>]

In-Reply-To: <001201c1cfc8$08e72760$8c00a8c0@neo>

Hi,

I'm not sure everything stated about IDS for web 
applications and HTTP/S has been entirely correct. 
For this discussion I'll refer to this class of product as 
a web application firewall.

1)      The most effective web application IDS's 
are not IDS's or resemble anything like a traditional 
IDS. They are instead reverse proxies or in effect 
much like proxy firewalls that are designed to only 
handle web traffic. All of them are capable of blocking 
invalid requests not just detection.
2)      SSL processing is moving to the appliance, 
there are several options available now that can 
drastically simplify SSL usage for sites that have 
many web servers. For example, why manage SSL 
certs on 20 web servers when you can do it once at a 
central point, and gain a massive performance boost 
as well?
3)      SSL encryption can not be snooped without 
a man in the middle breaking the transmission. 
4)      Performance wise, most web application 
firewalls can run at wire speed today or be clustered 
together to enable the effective handling of high traffic 
loads.  40,000 new connections per second and multi-
gigabit speeds are possible – if you had a pipe big 
enough to support this in the first place. People used 
to say the exact same things about firewalls, “Single 
point of failure”, “Bottleneck”, etc… all these issues 
were addressed and the same is true for web 
application firewalls.
5)      HIDS or rather HIPS suffers from several 
key limitations that limit it’s usefulness for web 
application protection
a.      HIPS do not analyze the bi-directional 
transmission of web traffic and perform request 
matching to ensure that users are only requesting 
things they were shown. In English: attacks against 
the web application (not the web server) can not be 
detected. (e.g. hidden field manipulation, parameter 
tampering, cookie tampering, etc…)
b.      Because the outgoing traffic is not matched 
with the inbound traffic (e.g a real time security 
policy), a static policy must be built before the 
application goes live to control what will be allowed. In 
addition, attack patterns or signatures will be required 
to detect most attacks, something that will need to be 
updated and as the anti-virus world has proven, even 
with a highly evolved signature distribution network, 
viruses still can spread like wildfire. 
c.      HIPS can add a significant CPU overhead 
to every system they run on.
6)      A proper Web Application Firewall will build 
it’s security policies in real time, keeping the client 
honest in their requests. It’s a very simple concept – 
don’t allow a client to request anything they haven’t 
been given as an option. Are their links on your site to 
the holes used by code red or nimda? No. So why 
were these requests allowed in the first place? Add to 
this strong data validation features to control down to 
the character what you allow in (and how much, don’t 
forget buffer overflow attacks) and you really are 
covering your bases. IDS’s and HIDS don’t even 
come close to this. The web application firewall 
should build it’s policies based on what’s allowed and 
block everything else. This is exactly how a firewall is 
configured today BTW, this concept has been 
pushed up the stack and extended to the web traffic, 
where most of the hacks are happening today. 

Quite frankly I wouldn’t put a web server of any worth 
on the net without knowing what the content of every 
inbound request is and that I have a system in place 
to control and limit those requests. The web server 
can’t do this, the firewall can’t do this, and HIDS can’t 
do this either. Blocking it with a web application 
firewall is the only option that’s available today.  

There are several products out there, just do a google 
search on web application firewall.