('binary' encoding is not supported, stored as-is) 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.
This archive was generated by hypermail 2b30 : Fri Mar 22 2002 - 09:01:09 PST