• Edge traffic manager sends the response back to the client via the original SSL session.
Managing client sessions at the edge makes it easier to secure your infrastructure: You are dealing with a known set of devices allowed to connect to your servers and other back-end devices.
Let's take a minute to discuss key storage. Never store your server's private keys on disk on the same server that uses those keys to encrypt your data. Instead, use smartcards or an HSM (hardware security module) for key storage and management. To steal the keys, these solutions require physical access to the card reader. They provide better security because access to the keys is managed via the smartcards. Rainbow Technologies, nCipher Corp. and Ingrian sell products for securely managing your keys. Don't simply use a removable storage device for these purposes because most operating systems view these devices as mounted file systems or drives, so they are remotely accessible.
Load-Balancers and Connection Control
Just as you must ensure that your firewall is configured correctly and lets only traffic on specific ports pass into your infrastructure, it's equally important to configure back-end devices, where possible, to accept connections only from specified clients.
Controlling who and what can connect to your servers provides for tighter access control and, thus, better security. If you have a load-balancer that can change the source IP address (one that can fully terminate TCP/SSL), your back-end Web servers sitting behind that load-balancer should not accept Web requests from a device other than the load-balancer. In other words, use the TCP-based access control available or create a "firewall sandwich" that allows connections only from specified, trusted sources. Again, start with a deny-all policy and open the machine only as far as necessary to let it perform its tasks.
This is particularly important for your databases because that's where you keep the crown jewels. If you aren't encrypting the data (and you should be), you need to take particular care that access is allowed only from those systems that need it.
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.
You can create your own minimalist APS by using a content switch and letting only specific requests flow through to your servers. By mapping out the entry points into your applications, you can deny requests that do not match those entry points. Because form input is concatenated onto the URL when you use the get method, using the post method for submission of forms will make this process easier.
Let's assume you have a simple application with three customer-facing pages: login.php, enterorder.php and showorder.php. If you use the post method to submit data, you can specify these three pages in your content switch and allow only requests with these three specific URLs to your back-end servers. The reason you don't want to use get is because the rule set grows increasingly complex with a highly variable URL, such as is used in an e-commerce site. While the content switch can certainly determine the entry points when using the get method, the post method is more secure and simpler because the entire form--including the session ID--is transmitted in the payload rather than the header. Yes, if you have a large number of pages you could end up with a huge rule set, but consider how much work would be involved if an attacker wiped out your data or compromised your server. The potential losses in time, reputation, fines and possibly lawsuits if sensitive customer information is released should justify the cost.
You may also consider using an application proxy firewall. Instead of connecting directly to a service, the connection is made to the proxy, which then connects to the desired service and returns the data to the client. This method can stop network attacks and a large percentage of application attacks, such as buffer overflows and protocol violations, because it controls the connection. Such an implementation can also provide audit logs and authentication, offering more control over access to your environment (for an example of a Web application firewall and information on how these products can protect you, see "AppShield Inspects and Protects Your Web Apps From HTTP to Z").
Technology editor Lori MacVittie has been a software developer and a network administrator. Most recently, she was a member of the technical architecture team for a global transportation and logistics organization. Send your comments on this article to her at lmacvittie@nwc.com.
RSS
