Web Server Security by Rik Farrow and Richard Power Your Web server represents your organization to the Internet. Besides presenting your public net presence, your Web server may dispense information which requires privacy and confidentiality. Some organizations, such as Amazon or Travelocity, use their Web servers for electronic commerce. Web servers have proven to be juicy targets for attackers, too. Attackers broke into the MGM, CIA and Department of Justice Web servers and changed home pages into embarassing parodies of each organization. Animal rights activists broke into the Kriegsman Furs server, and replaced their home page with links to animal rights sites. Obviously, Web servers are not as secure as we would like them to be. In some cases, the insecurity was as simple as an unnoticed but insecure CGI (Common Gateway Interface) script. In other cases, it was the security of the host operating system that was the problem. One method for improving the security of your Web server is to put it behind a firewall. But this may serve to move a security problem inside your internal network--not a good idea. If you keep the Web server outside of your firewall, your internal network is protected, but not the Web server. And the Web server becomes more difficult to administer. The best approach is a compromise solution, with the Web server on its own network, protected from the outside and with limited access to internal servers. Tunneling Through Many people place their Web servers behind their firewall, on an internal network. These people have the greatest ease-of-management over any other placement of the Web server, but at the expense of security. Also, maintaining the Web server in a secure manner actually becomes more difficult. Let's look back in time a few years, and see just what can happen when you put your public Web server on your internal network (see Figure 1). You have configured your firewall so that only traffic destined for the Web server, that is, HTTP and perhaps HTTPS, is permitted through the firewall. As far as an outside attacker goes, probes of the Web server system only reveal the listening port for the Web service, and nothing else. The attacker cannot send UDP packets, TCP packets for other services (SMTP, telnet, FTP, finger, SMB, etc) because all of these services are blocked. What could possibly happen? General Electric found out. On Thanksgiving Day in 1994, an attacker exploited a flaw in GE's Web server, which was on an internal network behind GE's firewall. The attacker sent an HTTP request over the standard TCP connection which triggered a bug in the Web server. After the exploit was completed, the attacker still had a TCP connection to the Web server system, but he or she was now talking to a command interpreter instead of the Web server software. In other words, the one-time standard Web connection now functioned more like a telnet session. The attacker was now able to use the Web server as a base for attacks on other internal GE systems. The attacker had a field day, breaking into many systems, all courtesy of the tunnel made by permitting access to the Web server through the firewall. Perhaps putting your public Web server on an internal network is not such a good idea. The other problem with this approach is that it misleads people into treating the Web server just like any other internal server. The Web server requires special care, as it is directly exposed to external users, even if this exposure is limited to HTTP. Treating the Web server as an involved component of the firewall puts the Web admininstrators in the correct frame of mind. Paranoid and cautious. Exposed The second route taken is to put the Web server outside of the firewall (where the firewall we are talking about is an application gateway or stateful inspection firewall). You still will most likely have a router between the Web server and the Internet, and you can use this router to protect the Web server with packet filters. So the Web server is not totally exposed to attacks. An attacker who breaks into the Web server is still outside your firewall. Hopefully, you have set up your firewall so that the Web server has very limited access to your internal network (see Figure 2). The Web administrators now have a more difficult time administering the Web server, because accessing it is no longer as convenient to access--the firewall gets in the way. And then there is the problem of confidential data on the Web server itself. Before, if your Web server were behind the firewall, you might consider it yet another database server, and load confidential data on it which duly authenticated Web users could view in a controlled fashion. Now you have just moved that Web server, and its private data, outside your internal networks. Is this such a good idea? Certainly not. The point of having a firewall is to create a perimeter around your internal network, providing protection for your critical data. Now some of that critical data is outside, protected only by a router (see the August '97 column for the downsides of using routers for firewalling). If someone breaks into the Web server, you are history. In fact, you could have the same problem with the Web server on the internal network. You don't have to keep critical data on your Web server at all. You can use a layered defense by using CGI scripts or other Web server mechanisms which process requests from external users and pass them to an internal database server. The internal server authenticates the request and provides a limited view of the private data. The Web server acts as a database client, using the remote user's authentication (username and password, for example) to gain access to a portion of the database. The firewall permits the Web server to access just the database server, and no other internal services. If an attacker manages to break into the exposed Web server, the only entry point to the internal network leads to the database server, which has its own access control protecting it. You get a layered defense, with the Web server being the first layer (perhaps behind a packet filter), the firewall the next layer, and the database server the final layer (and the real target in this model). The Middle Road Rather than exposing your Web server, or leaving it to the tender mercies of router configuration for defense, you might chose the middle road. You put the Web server on a screened subnet or DMZ (DeMilitarized Zone), a third network attached to your firewall (Figure 3). The firewall can now defend both your Web server and the internal network against attacks. This is our favorite approach, and the design favored in two recent books on Web security (see sidebar). The firewall only permits HTTP (and perhaps HTTPS) to the Web server from the Internet. The firewall also controls the Web server's access to the internal network, limiting it to severely controlled access to internal database servers as required. Internal users are permitted to access the Web server for testing. This approach looks like the best of both worlds. But there is still a problem. How do your internal users administer the Web server? The Web server, acting as a nice, juicy target, must be securely administered. If you permit your public Web server to be treated like an intranet server, you are asking for trouble. Public Web servers need to be configured as bastion hosts. Bastion hosts have been stripped of all non-essential services and software. Ideally, a bastion host only contains required software and nothing more. It is possible to set up a UNIX system as a bastion host with fewer than 100 files on it, other than the documents and scripts being served. All other software was removed, or better yet, never installed. If you don't strip of unnecessary software, you will at least disable network services other than those required to run the Web server and remotely administer it. Another principle of bastion hosts is to reduce the number of user accounts to a bare minimum. Ideally, there are no user accounts, just the system manager and Web administrators. The fewer users on a system, the less likely that someone will make a mistake and introduce a vulnerability. Or use a weak password. Smoke and Mirrors Of course, you could automate the administration of your public Web server. A truly modern solution: no human intervention required. Impossible? Well, yes and no. The system manager still has an account, and can remotely manage the system. A recommended method for doing this is to use an encrypted link, software such as secure telnet or SSH. The Web administrators work on an internal Web server which contains the data for the public Web server. Changes made to the internal Web server are migrated to the external, public Web server. One way of doing this is to use file sharing software, such as Microsoft's SMB or UNIX NFS. But these file sharing protocols are not secure, and this is _not_ recommended. Instead, you can use mirroring software which updates the public Web server to reflect changes made on the internal server. The mirroring software gets access to the public Web server, and no user accounts or Web administrator accounts are required. Advantages of this approach include having a complete, live backup of the public Web server. Changes to the Web server can be thoroughly tested before being mirrored. The internal Web server can be a less secure system and easily accessible to the Web administrators. Not that you want this system to be too easily accessed. You still want to protect this system from internal attacks. Even if downsizing has diminished in frequency, insiders still have some of the best motives and opportunity for attacks. You might consider using version control software on the Web server data, which allows you to see who has instituted changes, and also permits you to roll back changes. Paranoia Perhaps we sound a bit overly paranoid. But just consider how many Web servers have already been broken into, some with spectacular publicity. Having a publicly accessible Web server is an important part of doing business today. And having a secure, properly maintained Web server is just a part of due diligence--doing business professionally and with integrity. Put you Web server on its own network, a DMZ protected by your firewall, and administer to it carefully. In a future column, we'll talk about CGI scripts. Sidebar: Two books recently came out which talk about Web security. "Web Security Sourcebook", by Aviel Rubin, Dan Geer, and Marcus Ranum, is easy to read and a complete background for using both Web browsers and setting up Web servers (John Wiley and Sons, ISBN 0-471-18148-X, 350 pages). "Web Security and Commerce" by Simson Garfinkle and Gene Spafford provides a somewhat more detailed approach while covering similar topics (O'Reilly and Associates, ISBN 1-56592-269-7, 483 pages). Neither book covers much about using NT servers for your exposed Web server. NT is still a new operating system, one which hackers are eagerly investigating (see http://ntbugtraq.rc.on.ca/ntexploits.htm). For an online reference for Web security, check out Lincoln Stein's excellent Web security pages (http://www.genome.wi.mit.edu/WWW/faqs/ www-security-faq.html).