Although performance increases can be gained by implementing this type of configuration, the servers are left vulnerable because the Web servers must have a direct route back to the client. That means the client has a fairly direct route to the server, opening it up to possible intrusion unless you implement additional firewall rules and placing a heavier burden on the firewall. Be wary of using OPR (out of path return) or DSR (direct server return) configurations on Web and application servers behind a load-balancer (see "OPR or DSR Configuration"). These configurations use a server load-balancer to make the connection from client to server but let the server send its reply directly back to the client, bypassing the server load balancer.
Application Protection Systems
Closely related to IDSs, APSs (application protection systems) detect and act on abnormal traffic patterns at the application layer (Layer 7). There are two major differences between IDSs and APSs. First, an APS is proactive. When an APS detects an abnormality or a malicious request, it can block the request from reaching your servers. Second, an APS inspects and acts on data streams as opposed to individual packets. An APS examines the payload of a transmission and determines the validity of each request as a whole. An APS should be in front of your Web server or load-balancing solution (see "APS Placement").
These systems, such as those provided by Kavado, Protegrity, Sanctum and Stratum8, work by building a set of policies from observed communication between clients and servers. Any request that deviates from that base set of policies is considered an attack, and the system can act on it according to configurable rules.
These systems can detect a variety of attacks, even before patches for exploits are available. The Nimda and Code Red viruses, which propagated through abnormal requests, could have been prevented by an APS long before the patches were available.