For several significant reasons, web-based information systems present unique challenges from a security standpoint.
First, web-based systems often force organizations to violate some of the most basic tenets of information security. For example, many e-Business applications require that unknown and, therefore, untrusted users be allowed to interact with critical information systems on internal networks. Anonymous prospects must be able to browse catalogs, check inventory and prices, and even fill "shopping carts." From a technical perspective, not only must firewall ports be opened to allow such communications, but web servers performing real-life business functions must process application-level requests emanating from unidentified sources. If not properly implemented, remote access web-based systems such as SSL VPNs designed for mobile employees to access key systems and file repositories while out of the office require communication channels to be created from the Internet to sensitive systems and data such as e-mail and corporate directories again often forcing organizations to violate sound security policies.
Additionally, web-based systems are accessible from public Internet kiosks, shared or borrowed computers, and other machines over which no organizational control exists generating a whole slew of previously unconsidered problems related to access from "insecure" locations. Temporary files, user credentials, and other sensitive data is often left on machines after users complete their activities. Through the exploitation of various weaknesses, hackers can sometimes even reinstate user sessions that is reestablish sessions of legitimate users who previously used the same computer and wreak tremendous havoc by accessing, modifying, or creating data on behalf of that user (e.g., sending an e-mail on behalf of the legitimate user).
Finally, common security technologies including firewalls, intrusion detection systems (IDSs), and even standard reverse-proxies are often ineffective in protecting web-application infrastructure. Attacks exploiting application-level vulnerabilities such as buffer overflows can traverse proxies, SSL-encrypted communications easily bypass IDSs, and open ports seriously compromise the effectiveness of firewalls. Worse yet, reverse proxies may introduce new weakness in the stability and security of the architecture. Reverse proxies are, themselves, often subject to compromise by hackers, since they are typically implemented using web-server software with some added code to handle the proxying capabilities. A hacker can easily transform a hacked reverse proxy into an effective host to use in staging attacks against internal systems.
The security risks described above are serious and real. To combat these threats, and to address the shortcomings of the individual staples of classic IT security infrastructure (as described above), organizations have designed various complicated, proprietary architectures utilizing multiple security technologies, often implemented in part on actual application servers. As a result, many face serious issues of integration, complexity, and scalability. Upgrades of one component of the security architecture may cause another component (or even the main web application) to cease functioning. For enterprises with large numbers of web servers, implementing and managing security systems on each individual machine has proven impractical.
In addition, many of the complicated solutions developed for securing web systems do not fully address the security concerns of web access especially those emanating from the issue of access from insecure locations. Often the security remains inadequate; sometimes it is also implemented at a cost to the application's business functionality or in some other manner that seriously hinders user experience and productivity.
Air Gap Based Filtering Proxies were created specifically to address the aforementioned security issues, and to enable secure deployment of web-based systems. By offering both inbound filtering to ensure that no attacks reach sensitive systems and outbound filtering to ensure that no sensitive data remains on insecure machines, and by doing this on a secure Air Gap platform, these systems offer a viable, simple, scalable solution to the problem of securing web applications.
A detailed description of the architecture of Air Gap based filtering proxies and how they successfully address the aforementioned issues follows.
The underlying concept in Air Gap design is that sensitive systems must never be connected to the Internet (or any other insecure network) and that any requests made from the Internet to internal servers must be subjected to thorough inspection before being relayed to destination machines. Air Gap works much like a drop box requests from the Internet are dropped into a bucket where after the bucket is physically isolated from the Internet internal servers can retrieve the requests, check their appropriateness, and process accordingly.
Air Gap architecture consists of three components (often implemented within one box as seen in Figure 5.5):
This machine serves as the "face" of the Air Gap proxy the address to which users wishing access to web-based applications go. Its IP address and DNS name are published to the world, and users interact with it as if it were an actual web server. In actuality, all that this machine does is receive encrypted user requests, strip off any networking information, and load the encrypted application-level information from the original network packets onto an Air Gap switch. By removing destination IP information, Air Gap technology eliminates a hacker's ability to address systems not intended to be externally addressable. The external server is typically networked to an organization's DMZ. It is important to understand that despite any hardening performed on the external server, the Air Gap model assumes that this machine may not be secure so no configuration information or the like is stored on it.
An Air Gap switch is some form of solid-state device (not a computer or any other programmable device) consisting of a memory bank and a high-speed switch that can be connected to only one server at a time. After the external server loads the application-level information onto this hardware device, the analog switch disconnects from the external server, switches sides, and connects to the internal server.
This server is connected to the internal LAN (or some more internal DMZ than the External Server). It pulls the application-level information from the Air Gap switch, decrypts any data that is encrypted with SSL, and performs security checks on all requests. When user requests are deemed to have passed the necessary security tests, the internal server determines to which destination server the request must be sent, builds a TCP/IP communication channel to that server, and relays the request across the internal network.
Responses work in a similar fashion, with the internal server translating and encrypting traffic from the various application servers prior to transmission across the Air Gap switch.
All of the security functions of the Air Gap architecture are carried out on the internal server. This includes:
Air Gap enables organizations to establish a single location for handling SSL, which is clearly ideal. If each individual web server would handle SSL, not only could application performance suffer, but security concerns could arise. SSL encrypted requests are not readable by IDSs, and any attacks sent in encrypted form could reach their intended targets unobstructed. Additionally, from a business perspective, centralizing SSL processing allows for optimization both in terms of number of SSL certificates needed (one for the proxy rather than one for each server), as well as in terms of accelerators (if acceleration is needed only one accelerator can be installed at the proxy rather than one on each server). By performing SSL management at the proxy we eliminate this problem. Also note that the Air Gap architecture allows the SSL certificates (and decryption private keys) to be stored on the internal server where it physically cannot be reached by hackers on the Internet. The risk of a hacker stealing the certificate and associated key and setting up a rogue web site that impersonates the organization, are dramatically reduced when using the Air Gap solution. Also, the Air Gap system can utilize various techniques to check that the SSL packets are properly crafted, have not been tampered with, etc.
For those sections of a web site where authentication is necessary, authentication including two-factor-based strong authentication should be carried out at the network perimeter, not on the actual application server. Systems that require authentication should not be accessed by unknown users even to receive a login page. By offloading the authentication to the perimeter, Air Gap solutions both improve security (by ensuring that unknown users cannot attempt to attack the system by responding to login requests with buffer overflow attempts and the like), as well as performance (by ensuring that the server need not dedicate resources to receiving, processing, and rejecting random "junk" requests generated by worms such as Code Red, Nimda, etc.).
All inbound requests should be inspected to ensure that only legitimate application requests and not attempts to attack internal servers pass. Filtering should always be done using positive logic (i.e., maintaining a rule base of acceptable request and rejecting all others), as negative logic (i.e., maintaining a list of exploits that should be rejected) will not protect an organization from as-of-yet undiscovered vulnerabilities. Web requests consist of URLs, parameters, and methods and an Air Gap based proxy should include a filtering engine that can inspect all requests based on values and combinations of these items.
The Internal server also must manage all issues related to outbound data modification and manipulation that is, to ensure that outbound data is handled in such a fashion that both meets the needs of remote users, as well as ensures that no security issues arise because a user is accessing the system from an Internet kiosk or other "unsafe" machine. Among the tasks it performs in this regard are:
Instruct the browser not to cache any data and to expire any data that must be cached.
Replace any uses of vulnerable HTTP Basic Authentication with safe authentication
Overlay stronger forms of authentication (such as SecurID) when appropriate
Ensure that any user logouts actually terminate sessions on the proxy and the back office in such a fashion that they cannot be reestablished
Ensure that no user credentials are ever cached on the browser machine
Ensure that all temporary files (generated, for example, by opening an e-mail attachment) are erased when the user logs out
Implement timeouts to ensure that if a user neglects to log out, his session will be terminated but, do so in a fashion that does not time out legitimate users who are typing long e-mails or performing other activity that the server cannot detect.
Implement periodic reauthentication schemes so that the damage is contained in situations in which a user walks away from an Internet kiosk without logging out of the web application and another user walks up to it shortly thereafter (before a timeout occurs).
The Air Gap solution offers numerous security benefits:
First of all, Air Gap maintains a constant disconnection between the External and Internal servers and the External and Internal networks. This allows organizations to adhere to policies forbidding exposure to the Internet, a sensible rule that reverse-proxy solutions force organizations to violate. It also keeps the security engine of the Appliance safe from tampering. Even in the worst-case scenario, if a hacker were to gain administrator-level control of the external server, all he could do is load bad data onto the Air Gap Switch which would be rejected by the authentication, application filtering, and SSL inspection engines on the internal server.
Also, unlike standard reverse proxies, Air Gap based proxies do not allow external users to access any machines that have access to the internal network. A typical proxy which is a computer with multiple network interface cards each attached to a different network suffers from an innate problem that untrusted users are able to communicate with a machine that can communicate to internal networks. If a hacker, for example, attacks the proxy via the NIC facing the Internet, he can then use the proxy as a staging ground for attacks to the internal network through another network-interface card. Air Gap technology ensures that any machines that can be reached by untrusted users do not have access to the internal network, and that the staged-attack technique described above is rendered powerless.
When using an Air Gap solution, the only holes necessary to keep open in corporate firewalls in front of the Air Gap based proxy are the ports used for web access normally TCP/80 & 443 while all others can be shut off. Unlike the case with other solutions, however, no ports need to be open between the proxy and the back office (from the DMZ to the internal network). This minimizes network exposure, and provides a single point of management for security personnel. Of course, this also allows organizations to adhere to sensible corporate security policies prohibiting the opening of firewall ports from the untrusted world into the internal network.
As discussed earlier, TCP connections are terminated on the external server side (i.e., on the DMZ-side) of the Air Gap architecture. The proxy plucks the application-level payload out of network packets it receives and loads only this data onto the Air Gap switch. No network protocols or packets are transmitted. New TCP packets are generated by the Appliance server on the internal LAN after the rigorous security checks described throughout this document are performed.
Unlike standard reverse proxies that rely on the stability and security of operating systems and which can be compromised through the exploitation of o/s vulnerabilities, Air Gap switches are implemented with firmware they run no software, no operating system, and are completely stateless. In short, there is nothing to compromise. Without an operating system running, there is no operating system to attack and there is no chance of exploiting an operating-system vulnerability to compromise the proxy or break through to the internal network.
Eliminates plain-text sensitive information in insecure locations Enterprise security policies normally mandate that no sensitive information be maintained in DMZs; reverse-proxy architectures almost universally force organizations to violate such regulations; SSL certificates and decryption keys, authentication information, and security configuration and enforcement mechanisms are maintained in the insecure DMZ or made accessible to the DMZ via the opening of (even more) firewall ports.
Air Gap architecture allows all sensitive data to be stored on the internal network no SSL certificates, decryption keys, etc. are stored in the DMZ. Additionally, SSL decryption occurs on the internal LAN not on the DMZ. Without Air Gap technology, decryption normally takes place on the DMZ and important information is transmitted in plain-text to the back office over the insecure DMZ network wire.
Because all requests are inspected, buffer overflows and other attempts to exploit system vulnerabilities do not reach internal systems. Organizations are protected against not only vulnerabilities known at the time the Air Gap system is deployed, but against problems that are discovered in the future for which no patch or other remedy exists. In fact, deploying a filtering proxy can reduce the urgency to patch web and application servers because in most cases even without patching the systems are secure because of the filter protecting it. It is important to realize that the lack of robust filtering is one of the more serious vulnerabilities in most reverse-proxy architectures as if a user sends an application-level attack to an unprotected proxy, one of two things is likely to happen. The attack may successfully compromise the proxy in which case the hacker would gain access to a machine that can reach servers on the internal network. Alternatively, the attack may have no adverse effect on the proxy, but the proxy may relay the attack to servers on the internal network and inadvertently compromise them on behalf of the hacker. In such a fashion, hackers and other mischievous folks can achieve successful security breaches against internal systems protected by reverse proxies.
Quite significantly, the solution described earlier includes functionality to eliminate the threat of access from insecure locations developing into a problem of unauthorized access. Even the greatest security system is worthless if it has "back doors" that allow unauthorized users to "spoof themselves" as legitimate users.
Reprinted with permission from Whale Communications (Author: Joseph Steinberg).