Securing Your Web Site

Like most people in the network security field, I am constantly asked by clients, "How do I build a secure Web server?" And with the almost constant stream of successful attacks on Web servers everywhere, it is a reasonable question!

Yet it is impossible to effectively secure a Web server in a vacuum but rather the entire site must be have a secure network architecture. And all security efforts and planning in an organization have to be within a larger context of a security plan. All too often, a site's security policy is whatever was implemented at the firewall — the network administrator decided that outbound Telnet access is ok, for example, so that becomes a de facto policy. But it should be the other way around; the policy should be that it makes business sense to allow Telnet and then to direct the network administrator to allow the access. So while there are some tools that are particularly useful for building secure e-commerce or e-business Web sites, there are some general rules that all sites should follow to secure all of their servers. In essence, these guidelines are to just follow the basics — because the best Web server-specific tool is useless if the basics aren't followed.

MAKING A PLAN

What are the things, then, that need to be considered when creating a security plan and how does your Web server fit into the scheme of your business? There are five questions that should be kept in mind when formulating your Web (and general) security policies:

1. What are you trying to protect? This may sound obvious but answering the question will still clarify the issue. For many companies, the very essence of the business is the intellectual property that is wholly contained on one or two servers. If the Web server is the portal to your back office servers, then you must pay particular attention to securing it; if your Web server merely has static catalog of information, for example, it might be the case that other servers need more of your security time and attention.
   
   
2. From whom are you protecting it? This may also sound obvious but it is an important question to answer when considering the protection you need. If your major concern is pedestrian attackers, you will need different protections than if you fear a well-funded, sophisticated government-sponsored or industrial attack.
   
   
3. What is the likelihood of an attack and what kind of attack is most likely? This question is directly related to the one above. Knowing something about the potential attacker will give some clues as to the probability of an attack and the methods that they might use. Hackers who don't really care about your business in particular might just rattle the doors of your site and then move on if they encounter even simple resistance; a more hostile attack, on the other hand, might be directed at breaking into your servers and tampering with the information.
   
   
4. What are the possible results of an attack or compromise? The obvious answer is that someone will trash your server and your data will be lost. But since you have backups — you do have backups, right? — losing data is almost the least of your worries. Downing your Web server could put a virtual business out of business. Vandalizing your Web server could jeopardize customer confidence in any business. We've already seen at least one case where an attacker stole credit cards from a site's database and then attempted to extort funds from the site to not distribute the card numbers; and when the extortion attempt failed, the attacker indeed publicized the numbers. In some cases, a successful major attack on a company can put the company out of business.
   
   
5. How much protection can you afford? This question is always a major headache for network managers and CIOs. After determining what's at risk and gaining a real measure of the exposures and vulnerabilities, you can then take a stab at determining what kind of financial resources you should direct at the problem. It is next to impossible to calculate ROI on security because you can't always measure what you saved from the attack that didn't happen.

The following formula is useful in helping gauge a site's ever-changing security risk:

R = A · T · V

A represents the asset value of the material you have placed on your Web server; as the Web server provides more information and additional access to corporate information, A probably rises. T is the threat likelihood, which is always changing; when you fire an employee, write an article about security (!), or do anything that calls attention to yourself, your visibility goes up for a while and so does the potential threat. Finally, V is the vulnerability. This is the area you can really work on; the only way to minimize your risk is to reduce your vulnerability with security tools, policies, user education, and vigilance. Although risk (R) is a unitless number, this formula can still have a great value. Try applying the formula at some point in time and just choose some metrics for A, T, and V; the resulting R forms a baseline for you. Apply the formula again some months later or in anticipation of an upcoming major network project, and in almost all cases you will find that the resultant R has increased, thus demonstrating a trend to which you should pay attention. Don't let unitless fool you. Cliff Stoll's classic The Cuckoo's Egg was about how a 75¢ billing discrepancy led to him tracking down a group of hackers in Germany attacking U.S. government and military sites.

FIGURE 1. Securing a Web site requires a secure network topology. To that end, attention must be paid to all areas of the network starting at the router connecting the site to the Internet.

As Figure 1 shows, a secure Web architecture comes from addressing the security of all elements within your network topology. There will always be a weak point and attackers will try to find and focus on that spot. But before talking about any of those specific items, let me put in a plug for good physical site security. All of the computer and network security in the world is useless if your site is wide open to someone walking in and leaving with a server. If you are paranoid enough to believe that attackers might target your business, do not ignore the very real threat of physical theft; it is far easier to kick in a plywood door than to kick in a good firewall.

ROUTER

The router is the first point of presence your network has to the Internet. It should also implement the first set of defenses, using the packet filtering and/or other access control capabilities that are available on most routers today. Access control lists at the router should, at the very least, block undesired protocol traffic (such as ping, traceroute, and IP source routing) and direct all incoming protocol traffic (e.g., HTTP and e-mail protocols) to appropriate servers. The router can also be used to block incoming traffic with obviously bogus addresses; any incoming IP packet that contains your network's address in the Source Address field is clearly employing address spoofing. Request for Comments (RFC) 1918 describes private IP addresses, or IP network addresses that can be used freely by any site for internal addressing and are not supposed to be routed over the Internet. Any incoming packet that advertises an RFC 1918 private address in its Source Address field is also bogus. Many routers can employ added intelligence and actually recognize and repel certain attacks (mostly denial-of-service attacks).

Another feature that should be considered at the router is Network Address Translation (NAT), described in RFC 1631. NAT was introduced to deal with IP address exhaustion. In most cases today, sites attaching to the Internet are assigned an IP address block that is smaller than the number of hosts on their LAN, although every LAN host does need to have its own IP address. With NAT, when a host on the LAN accesses the Internet, the host's private IP address is translated to a global address from the public IP pool assigned to the site. In this way, several thousand hosts using private addresses can share just a few public IP addresses. NAT also has a security component; the global addresses cannot be used by an attacker to learn the private addresses used within the network. With NAT, then, only the public servers are visible to the public Internet.

Historically, packet filters and firewalls have been built to protect a site from an inbound attack from the Internet. But these defenses should also be built to protect outbound attacks from being launched from this site, as well. Attacks have to come from someplace and if more ISPs and end user sites protected the outside world rather than just protecting from the outside world, we'd all be better off.

I cannot overemphasize this last point. The Internet has been described as "anarchy, only not that well organized." As long as everyone spends resources to only protect themselves, we will all continue to be on our own and we'll all be victimized in one way or another. For almost no extra effort, we can also protect each other.

DEMILITARIZED ZONE

A demilitarized zone (DMZ) topology separates the "trusted" internal network systems and servers from the "untrusted" servers accessible to the general public. A DMZ is sometimes built as shown in Figure 1 which is a simple, inexpensive way to isolate public servers from private servers. Figure 2 shows an alternative configuration. In this scenario, the router has two LAN ports, one connected to an unprotected ("dirty") DMZ and the other connected to a firewall. The dirty DMZ contains servers that have relatively static information that require minimal protection; these so-called "sacrificial servers" could certainly include a public Web server.

FIGURE 2. Another DMZ model, employing an outside, unprotected ("dirty") DMZ for servers with static information and minimal protections. An inside, protected ("clean") DMZ is used for those servers that require additional protections; these are the servers that might communicate with the private servers on the internal network.

The firewall also has three network interfaces, one each to the external network (back to the Internet router), protected ("clean") DMZ, and internal network. The clean DMZ contains public servers that we need to protect because, for example, they have access to internal network resources; this would be a good place to put extranet servers. Strict controls can be placed on what traffic is allowed to pass between the Internet, dirty and clean DMZs, and the internal network. Although your network will still work without employing a DMZ, this type of topology is a good idea because it provides a way to logically segment and protect your network resources, in particularly the public Internet, private intranet, and semi-private extranet Web servers.

FIREWALLS

The firewall is the primary system that protects internal, trusted, private network systems from the outside, less-trusted world. The firewall can supplement the access controls implemented in the router and usually has an easier, more intuitive user interface than a router.

The most common type of firewall applies basic packet filtering and access control but with more intelligence than the typical router. A top-notch firewall can detect a large variety of inbound attacks and block them, and will also look at incoming and outgoing packets in the context of protocol packet exchange ("stateful inspection").

Firewalls can be acquired as software packages running over Windows NT/2000, Unix, or other operating systems or as a stand-alone hardware appliance, and there are pros and cons to each. The appliance is a single-purpose device optimized for a single task and uses a specialized operating system; some users, however, object to the fact that it is usually impossible to access the underlying operating system and really learn about it. Software firewalls, on the other hand, run on widely available general-purpose operating systems but the underlying software platform then becomes a potential vulnerability. Overall, firewall capabilities, features such as ease of use and manageability, and cost are probably more important that whether the solution is hardware or software but if everything else was equal, I'd probably go with the appliance because of its suitability to task.

Another form of firewall are proxy servers that hide inside systems from the outside world. When a user on the internal network attempts to connect to a server on the Internet, the proxy actually gets in the middle and sets up the connection on behalf of the user. The proxy, then, is the only system publicly advertised. They also cache Web pages which can reduce network traffic. Proxy servers should be used in conjunction with some form of packet filtering or else clients and attackers alike might be able to go around the server. Proxies generally protect internal client systems and intranet hosts rather than public servers on the dirty DMZ.

Several other tools related to firewalls are important for protecting your site. Intrusion detection systems (IDS), in particular, monitor all packet traffic and can detect many attacks in real-time. IDS are stateful devices that compare the incoming and outgoing traffic pattern with known attacks in its attack signature database. By examining the header and some content of every packet, and the patterns in which the packets appear, they can detect denial of service (DoS) attacks, episodes of port scanning, TCP session hijacking, small packet attacks, Internet Explorer attacks, and more. DoS, and the more recent flavor of Distributed DoS, attacks are particularly insidious because software tools with which to launch these attacks are widely available on the Internet. The security administrator can define what actions the IDS should take when certain noteworthy events occur, ranging from logging an alarm or sending an e-mail notification to calling a pager or shutting off a network connection. IDS are becoming an essential part of a secure Web site's protection; while a firewall and IDS alone cannot thwart the launch of a DoS attack, they can minimize the negative effects.

Another important related tool is log analysis software that will help you interpret the information contained in the logs maintained by the router, firewall, Web server, etc. As an aside, be sure that logging is turned on. Windows NT, for example, comes with a reasonably powerful logging capability that is off by default. In addition, some services, such as Microsoft's Internet Information Service (IIS), use their own log files separate from the operating system's. The good news about logs is that they contain all of the information that you might need to understand your network; the bad news is that there's so much information that it is almost impossible to see trends that might help you better manage your network and/or avoid a problem. Log analysis software is designed to display information in tables and graphs that humans find much easier to deal with than row upon row of numbers.

PROTECTING THE SERVERS

All servers — Web, e-mail, database, domain name system (DNS) — are software that run on some underlying operating system (OS). But the most prevalent server OSs on the Internet — Windows NT and various flavors of Unix — are not inherently secure. It is imperative that network administrators continually monitor the Web sites of their OS vendor to ensure that they have the latest software patches and service packs for all relevant daemons and services.

But doing this manually is not always sufficient nor possible. Vulnerability scanners are software that will do at least part of this task for the network administrator, most focusing on Unix and/or Windows NT. This software will poke and probe the installation of an OS on a particular server and produce a report about the security vulnerabilities that it finds. Based upon the software's OS vulnerability database, the reports will generally prioritize the vulnerabilities that are discovered, explain the ramifications of the exposure, and describe how to fix them.

FINALLY, THE WEB SERVER

Everything up until this point has described the general steps that should be taken to secure one's network components when connected to the Internet. But what additional steps need be taken specifically with respect to Web servers?

The first steps that must be taken is to lock down the server software itself at tightly as you've locked down the OS upon which the software runs. Whether you are running Microsoft's IIS over NT or Apache over Linux, you want to be sure that no services are running on the server that you do not specifically want. One simple tool to use is the netstat -a command in both NT and Unix, which will display the TCP and UDP ports (services) that are open on a server. It is amazing how many services are awake and listening by default that system administrators never turned on and are in many cases unaware. And many of these services open holes for an attacker into your Web server.

Another Web vulnerability is related to Java, JavaScript, ActiveX, and CGI code. If you use any such code that you did not write, be sure that you get it from a trusted site rather than just using some code that looks cool. Use these tools only when you really have to; it is usually better to have a slightly less "exciting" but more secure site. Lock down your own code so that nefarious users cannot upload exploitative code to your server. Many firewalls will block known hostile Java and ActiveX applets.

In many cases, however, even these steps are not sufficient. As the Web browser increasingly becomes the universal client, Web servers are increasingly becoming the universal portal to network services and applications. Users don't employ their browsers to only download Web pages and e-mail anymore, but they also access all sorts of back office business databases commonly stored on "internal network" servers.

There is one philosophy that says that the focus of security should be as near to the Internet connection as possible in order to block the "bad guys" as early as possible. Consistent with this philosophy are sites that put the bulk of their Web server protection at the Internet router or, possibly, the firewall. There is another philosophy that says that the focus should be as close as possible to the application that you are defending; by placing the protection near the application, you can be sure of the integrity of the data getting to the application. This latter philosophy has given life to a large number of products that are designed to specifically protect access to intranet and extranet Web servers being used for e-commerce and e-business applications.

We place a heavy reliance on our intra/extranet servers because they are generally tied directly into our corporate information nervous system. The added value that they provide to users is exactly what exposes the owner to potential catastrophe if the back office information is exploited — and the server is often the major externally-accessible vulnerability.

But just as the owner depends upon the servers, so does the individual user who accesses the servers. So trust must be established between the communicating. In particular, the external users (clients) need to be sure that:

• They are communicating with the correct server
• What they send is delivered unmodified
• They can prove that they sent the message
• Only the intended receiver can read the message
• Delivery is guaranteed

The servers, meanwhile, need to be sure that:

• They are communicating with the right client
• The content of the received message is correct
• The identity of the author is unmistakable
• Only the real author could have written the message
• They acknowledge receipt of the message

All of the concerns above can be addressed using digital certificates and cryptography, such as the public certificates shipped with our browsers and the Secure Sockets Layer (SSL) protocol used when we make a credit card purchase over the Internet. While this is the right model, note that secure purchases over the Internet today do not meet all of the criteria listed above. Indeed, the certificate from the secure server confirms the identity of the server to the client, but the client's identity is not similarly authenticated to the server; the server takes the credit card number and gets approval from the credit card authority, and that's all the user verification that takes place.

Intranet and extranet applications, then, require even stronger mutual authentication, but even this is not sufficient to protect your Web server and its data. Certificates prove the identity of a user but they don't tell the application to what resources the user should have access. This last point — authorization — is very important as network administrators may need to define specific access control on a per-user basis.

The approach taken by most products that provide this type of service bind the user's identification to what they are authorized to do or what resources they are authorized to access. Most use a central Lightweight Directory Access Protocol (LDAP) database, making is easy to administer and manage. In addition, X.509 certificates and tokens are commonly employed. Most also employ single sign-on (SSO) which is itself a subject of controversy within the industry; SSO is convenient for users so hopefully they will choose good passwords and protect them somewhat better than the ubiquitous "yellow sticky note on the monitor." But it also means that a single password, in many cases, opens all of the network resources.

Securant Technologies' ClearTrust SecureControl (http://www.securant.com), for example, is a policy-based access management tool that provides authentication, access control, authorization, auditing, and the ability to delegate policy administration for both Web-based and enterprise applications. ClearTrust is truly scalable product that is designed to match the enterprise infrastructure. ClearTrust's administration model uses Virtual Business Units (VBU) to build an administration hierarchy that reflects the site's business organizational structure; VBUs can also be created for business partners accessing a corporate extranet. The security policy is defined in a central database for consistency on an enterprise-wide basis. LDAP directories support a centrally managed user database for SSO and automated authentication and authorization; the single point of management reduces the security risks inherent with multiple administrators and allows a consistent security ruleset for a given user across multiple platforms. ClearTrust also includes auditing and threat detection mechanisms to track what users did and to watch for real-time security policy violations. ClearTrust runs over Unix and Windows NT and can integrate with Apache, Microsoft IIS, and Netscape Enterprise Server Web platforms. Authentication can employ passwords, X.509 certificates (in partnership with PKI vendor Entrust), and Security Dynamics SecurID tokens. Axent's WebDefender (http://www.axent.com) and Hewlett-Packard's DomainGuard (http://www.hp.com/security/products/domainguard) are functionally similar to ClearTrust.

Blockade Systems' Extended Access Control (EAC) (http://www.blockade.com) software is also similar in functionality to ClearTrust although designed specifically to bring large IBM MVS- and OS/390-based business applications to the Web. EAC passes authentication and authorization requests from network devices — such as remote access servers, routers, firewalls, Web servers, or proxy servers — to an OS/390 host security system. The basic authentication and authorization services support requests from SNA, Web, and certificate servers and use the central database at the OS/390 to authenticate the users and authorize access to services and applications.

Gradient Technology's NetCrusader/Web (http://www.gradient.com) product is another scalable access management tool that allows a Web site administrator to control user access to Web-based resources and information. It takes a notably different approach than almost all other products in this space, however, based on a design philosophy that Gradient calls "authenticate centrally but authorize locally" NetCrusader/Web uses an LDAP-enabled directory for the central repository of user information, ensuring an enterprise-wide consistent directory for authentication. Authorization for resource access, however, is managed by certificates on a per-application basis under control of the Web site administrator. In this way, different applications and/or servers can use the same authentication directory yet define different authorization lists. This feature is pretty exciting in that it provides a very fine granularity of protection for applications and resources. NetCrusader/Web runs on AIX, Solaris, and Windows NT.

The products above are generally designed for intranet and extranet applications. For public Web servers, there is the Systems Advisory Group Enterprises, Inc. (SAGE) BRICKHouse Web Appliance (http://www.thirdpig.com). The BRICKHouse is a stand-alone box that protects Web-based applications and resources using a scheme called process based security (PBS), designed around the observation that "people don't delete files, processes do." The traditional OS assigns access rights to users. If a hacker cracks the OS or gains access to the administrator/root account, he/she can possibly upload Trojan horses and/or other nefarious code, as well as alter the operating environment of the server. BRICKHouse assigns access rights to applications and users' access to network resources is totally constrained by the application(s) that they are authorized to use. PBS is a Linux-based model, with a security design from the perspective of what a program should be allowed to do; even a user with administrator or root privilege cannot make a program take an unauthorized action. In this way, access to resources can be granted on an ad hoc basis and an individual program's security cannot be circumvented merely by accessing the data files outside of the intended program.

The products above control user access to applications and resources but do not specifically address the more "mundane" issues such as secure remote access and viruses. Network Associates' (NAI) WebShield E-ppliance (http://www.nai.com) is a product family that provides Web-enabled anti-virus, firewall and VPN software in the form of simple plug-and-play hardware appliances. The WebShield 100 E-ppliance provides Internet anti-virus security and content scanning. The enterprise-oriented WebShield 300 E-ppliance integrates NAI's McAfee anti-virus, PGP VPN, and Gauntlet firewall on either a Sun Solaris- or Windows NT-based appliance; an IPsec client is also included for remote users accessing the VPN.

Perfecto Technologies' AppShield (http://www.perfectotech.com) offers another approach to protecting your public Web site. AppShield acts as a Web proxy (for both HTTP and HTTP/SSL) and protects Web applications from their most common vulnerabilities, including buffer overflow attacks, modification of hidden fields, CGI scripts, cookie poisoning, and invalid text entries. Applications can be secured by AppShield to ensure that user selections are always within a legal range, read-only client-side data remains unchanged, and free-format user input is valid. To provide these protections, AppShield is applied to the application but the application itself does not have to be written with AppShield in mind. This software operates on a server running Windows NT or Sun Solaris that sits between the Internet router and the Web server; it is completely server-independent and can work with any Web server, browser, load balancing software, application server, or Web statistics utility.

It should be noted that most of the products in this section are not intended for the faint-of-heart. Complexity is inherent in their power and this software requires ongoing management and monitoring.

CONCLUSION

There are a variety of products designed to secure your Web server. Reviewing the five questions at the beginning of this article will help a user decide what really needs to be protected and what the best available mechanism is. But keep in mind that security products specifically designed for Web servers may be essential to protecting your Web-based applications but they are really just a piece of a larger puzzle. Securing your Web site will continue to mean employing all of the basic tools in the security arsenal — and these include common sense and vigilance.

Even more globally, securing the Web server is only a part of your corporate security policies that have to reflect the reality of your business and workplace. Your security policies need to combine aspects of network operations, corporate policy, culture, politics, and user habits. RFC 2196, the Site Security Handbook, can provide guidance in creating such policies and procedures. And the written policy document must evolve as the company, network, and Web site evolve. Just as information technology (IT) is now generally recognized as integral to the strategic goals of the company, security pollicies must be integral to IT.

About the Author: Gary C. Kessler is a senior network security analyst at SymQuest Group (http://www.symquest.com), a network integration consulting company in South Burlington, VT. His e-mail addresses is kumquat@sover.net.