WEB SECURITY ADVISOR
Protecting Web sites by guarding the exits
Avi Rubin
08.28.2001
Rating: -4.60- (out of 5)
Protecting Web sites by guarding the exits
By Avi Rubin
There is a new theory in Web site security called exit control. Avi Rubin discusses this new procedure in this tip from InformIT.
Do you have a Web security tip of your own? Why not send it in? We'll post it on our Web site and enter you in our tips contest for a prize.
When you think of protecting a Web site, you might typically consider protecting the Web server machine, using intrusion-detection techniques and utilizing firewalls and other access-control mechanisms. While all of these protections are important, no Web server is unbreakable.
By nature, Web servers are large, complex beasts. They run CGI scripts that often lead to compromise, and often there are many user accounts in which users can post their own content, including scripts. The best way to protect a Web server from compromise is to hire a top-notch administrator who watches the server closely. The administrator should keep a close eye on access patterns and monitor the logs carefully. Of course, when all is said and done, if hackers want to get in, they will. It's just a matter of how quickly you notice it. In addition, attacks may come from insiders with legitimate access to the Web servers.
Watching the exits
One of the common activities of attackers when they break into a Web server is to hijack its content, so that visitors to the Web site see something different when they come. So, here's an idea: Give up on the Web server machine itself, and watch the content after it leaves the server to make sure that it's approved. This idea, credited to Gilian Technologies, is called exit control.
Here's how it works: An administrator decides what is and isn't appropriate to publish on the Web server. The content then goes through an approval phase, in which cryptographic fingerprints of approved content are generated. The fingerprints are then securely transferred to a box that sits at the exit point between a Web server and the rest of the world. When content is requested from the Web server, it passes through the box, and its authenticity is verified. Only approved content is allowed through.
A company uses standard security tools to protect the communication between its production environment and the Web server. These include firewalls, access control and intrusion detection. The content is then served from the Web server as usual. When a user accesses the server over the Internet, the requests and replies travel through the exit-control box in a transparent manner. There, the content is checked for integrity against the cryptographic fingerprints provided by the administrator at the time that something is published.
The beauty of this idea is that it no longer matters that the Web server is broken into. Sure, a denial of service can result, but users visiting http://my.organization.com/ will either see content approved by my.organization, or nothing. Even if an attacker breaks into the Web server, he or she can't change the content. This strategy is very powerful.
Tripwires, screening and signing
There are other architectures for exit control, as well. Tripwire security checks files before the Web server sends them to clients, to make sure that they haven't been modified. This architecture is less robust to server compromise, as a break-in to the Web server could also defeat the exit control. Trusted Computer Solutions also offers an exit-control product for screening and signing content as it moves from high-security domains to low-security domains.
Securing the exit-control box
The astute reader will note that the separate box architecture for exit control presents a problem for secure transactions that use SSL to protect the content. Since everything is encrypted, there's no way for the exit-control box to check the fingerprint of content as it travels through. There are two solutions to this problem:
* Share the SSL state between the server and the exit-control box, so that the content can be decrypted with the session key. This has several practical limitations, and is likely to adversely affect performance.
* Terminate SSL in the exit-control box itself. This means that the box will need to run additional code, and it will have to contain the secret key of the server. While this isn't ideal, it's consistent with the idea of separating the security aspects of the system from the functionality. If the SSL is terminated in the exit-control box, the secret key is not needed on the Web server, so when (not if!) the server is broken into, the secret key will not be compromised.
Is this just trading off security of the Web server for security of the exit-control box? That's an interesting question. In security, we view complexity as the enemy. The more complex something is, the harder it is to secure it. The nice thing about the exit-control strategy is that, while the Web server is bulky, runs CGI scripts and often has user logins, the box watching the exit can be kept simple, run a hardened OS, be monitored closely and thus be protected more easily. In fact, in its product, Gilian took an additional step of not making the box addressable, so it doesn't even have an IP address.
To read more of this article, specifically about extra security features of the exit-control scheme, click over to InformIT. Registration is required, but it's free.
What did you think of this tip? Send us an e-mail and let us know.
|
|
Rate this Tip
|
To rate tips, you must be a member of SearchSecurity.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
