Securing Your Web Server
Ray Soriano and Gary Bahadur In today's dynamic and competitive economy, being seen on the Internet can make or break an organization. Having a Web site is a must if you are serious about conducting business, achieving profits, or providing reliable information. A Web site is the display window to the electronic passerby, capturing their interest and trust. However, one can easily lose this trust with a click of a button. It is not uncommon to read about famed Web sites that have become victims to "electronic crime" either because of exploits to server configuration, information mismanagement, or inadequate security design and architecture. Abuses of these types are occurring more frequently because of the "point and click" age. All it takes is some easily accessible public exploit code, persistence, and a little caffeine for a cracker to humiliate an organization by way of a Denial of Service attack, data manipulation, data corruption, or public defamation - none of which would read well in the New York Times. This article will concentrate on the finer points of securing a Web server and should not be mistaken as a complete security framework. The objective is simply to provide you with a better understanding of Web server security and provide a list of items to review to protect your new or existing Web servers. For a complete secure implementation of a Web server, the application, operating system, network, and transmission of data must be taken into account. Encryption is a key element of Web-based transactions that should also be made secure, but we will cover just the basic concepts of using encryption with SSL and SET, and not go into details of implementation or usage. Although there is an assortment of Web server software available freely and commercially, we cannot possibly describe each of their unique security features within one article. Rather, we will focus upon the basic components of a Web server and the general precautions that an administrator must consider. Methodology for Testing and Securing a Web Server It is always in the interest of the Web administrator (the individual responsible for the operating system and functioning of applications) and the Web site's organization to conduct periodic reviews on the Web server. This can be as simple as network port/service scans against the Web server to expose blemishes in the configuration or as complex as a thorough Web site assessment conducted by reputable outside security experts. Whatever type of Web server diagnostic you choose, periodically conducting a Web server security review helps fortify a sound and secure Web site. Remember that an ounce of precaution may aid in the prevention of Web conundrums such as buggy code, configuration errata, and troublesome vandals. The logical progression for testing and securing your Web server is as follows: I. Footprint Analysis As discussed in the article by George Kurtz and Chris Prosise in the March issue of Sys Admin, "footprinting" is the method of discovering what information about your company is available to the public. For the purpose of performing a diagnostic review of your Web site, attempt to gather as much information about you Web site as possible. Try to determine what possible weaknesses exist from the external environment. II. Penetration Testing From the list of possible weaknesses found through "footprinting", attempt to compromise your own Web site from the external and internal environment with systematic, controlled penetration testing. There are a number of freeware, shareware, and commercial tools available for penetration testing. III. Diagnostic Testing Once you have determined weaknesses existing from external access to the Web server, you must perform host-based testing. This means installing diagnostic software on the server to determine what configuration or installation weaknesses exist. IV. Policy and Procedure Review Even the best security tools can be compromised through lax security policies and procedures. Review your security policies to determine if they fall in line with your organization's security measures. In some cases, the organization's policy may not be strict enough. Organization policies and procedures must address the secure transmission of data and data content Current procedures must also be reviewed to determine the points of weakness in how the system in administered. V. Architecture Review The architecture of your network design plays an important part in penetration testing and overall security. For example, if you have placed a publicly available Web server on the Intranet behind the firewall, you will be letting attackers through your firewall into the internal environment. If the Web server is on the external DMZ, and there are unsecure servers on the DMZ, an attacker could compromise an adjacent server and use the compromised server to sniff traffic or as a launching point to attack your Web server. At the minimum, a DMZ should be used to provide segregation for your internal network from externally reachable devices such as your Web server. Penetration testing and a comprehensive architecture review will help identify unsecure systems and potential points of entry to your internal environment. VI. Continuous Testing Once you have conducted a full review of your Web server, do not assume it is secure forever. Continuous testing should be done. As new weaknesses are discovered in the operating system or applications you are running, diagnostic and penetration testing should be redone. Installation and Configuration Issues for the Web Server Whether your choice of operating system is UNIX, Windows NT, Novell, Mac, or something else, when setting up a Web server, keep it simple. The more functionality you add to a Web server, the more complicated and prone to attack the environment will be. Therefore, the next ten items describe a simple checklist for a Web administrator to perform prior to exposing the Web server to the world. 1. Harden the Operating System It almost goes without saying that maintaining current versions of the operating system is a must with any system, whether it is a Web server, firewall, or application server. Without properly updating the server's operating system, a site risks the chance that an unauthorized user may be able to exploit the weakness in the software that was fixed in later versions. This also holds true for the Web server application itself. Many of these exploits are posted and explained in gory detail within many of the Internet mailing lists. We recommend keeping up with latest security alerts from CERT at: http://www.cert.org, UNIX exploits at the Bugtraq archive: http://www.geek-girl.com/bugtraq/, and Windows NT equivalent: http://www.ntbugtraq.com. A good beginning resource for tracking down exploits and security industry news is:
http://www.infoworld.com/cgi-bin/displayNew.pl?/security/links/security_corner.htm At a minimum, you should keep atop of Microsoft, Sun, Netscape, Apache, and any of your vendors for the latest patches or product releases. They're posted for a reason; so use them. 2. Network Services Typically, new UNIX or NT systems come with various features enabled by default. In the case of a system working solely as a Web server, the system doesn't need to have the variety of TCP/IP nonessential services enabled anxiously awaiting to serve the public. Remember that the more services running on a system, the more possible portals there are for intrusion. The optimal solution is to determine which services are essential for your specific operation. Balance the trade-off between security and administrative convenience. Ask yourself whether you are exposing the Web site by enabling this service. Are you willing to accept this risk? To help you determine which Internet services are listening on a UNIX system, a simple command to run is netstat -a (command arguments vary with AT&T SVR4 versus Berkeley BSD flavors). The ports listed display those services that have a server process registered with the operating system. Generally, the servers launched at system startup are done by the daemon inetd. This daemon has all its authorized server processes listed in the file /etc/inetd.conf. To disable a particular server process that is unnecessary for your operation, comment it out by placing a hash mark in front of the appropriate server process line. For the change to take effect immediately, you must determine the inetd program process number or pid using the ps command. Once you've determined the inetd pid, send the server process a HANGUP signal using the following command: kill -HUP pid. On NT systems, one major point of attack is via TCP/IP access to the NetBIOS service. TCP/IP and UDP/IP access to NetBIOS (e.g., ports 137, 138, & 139) can be blocked by your firewall. For added security, disable or unbind the NetBIOS service from the adapter on the untrusted network side or use the advanced TCP/IP security features to block all but the essential port access. The services you have available to the rest of the world can be determined through TCP and UDP port scanning. 3. User and Group Management A typical way that attackers compromise the Web server is by obtaining a user account and password and logging into the server. In many cases, this is due to either poor password selection or mismanagement of accounts on the server. On some systems, predefined system accounts are available and delivered with default passwords associated with them. Therefore, you should review these accounts and ensure that none of these accounts are victims to unauthorized login. As a prudent measure on your Web server, you should limit the number of authorized users who can login. Generally speaking, the only accounts necessary on the Web server should belong to the Webmaster, system administrators, possibly content providers, and necessary system and Web server process accounts. We say "possibly" content providers because depending on your site's content update process, you may want to limit updates to your Web server via a single account. As an example, you can create an ftp account on the Web server and only permit this account to do this function. You should also enhance file transfers with special software packages such as Wietse Venema's tcp_wrappers available at:
http://www.cert.org/ftp/tools/tcp_wrappers/tcp_wrappers_7.6.tar.gz This tool restricts access to TCP/IP services by IP address or host name. Another useful tool for transferring files is scp (packaged as part of ssh available free for UNIX at: http://www.cs.hut.fi/ssh; the commercial version is available at: http://www.datafellows.com/f-secure), which securely copies files using encrypted communications. Any administrative login sessions to the Web server should be done though an encrypted connection. In addition to limiting accounts, you should consider categorizing authorized users into a handful of authorized Web server groups. You can create unique groups to lump administrators, code developers, and content providers. By creating these groups, you minimize the risk of providing unauthorized access to system files and resources, and simplify the access control rules of your Web server. 4. File and Directory Permissions After you have installed your Web server software, a critical aspect to remember is the appropriate establishment of file and directory permissions for both the operating system and your Web server software. Generally, for your operating system permissions, look out for kernel files and directories that are writeable by anyone. Question these, because they could be a disaster waiting to happen. The directory structure of a Web server varies from one brand to another. Overall, they share a common set of directories. We've put together a short list of typical directories found on a given Web server with an explanation of their operational relevance and protection. Each site may have its own special set of access requirements, but we provide a guideline based on our experiences in the field.
cgi-bin or scripts - This directory contains scripts or compiled code that, when executed, provide dynamic Web content, access to backend databases, or perform specific server tasks. Although everyone generally has read access to this directory, only the Webmaster and code developers require write privilege. conf - This directory contains the files that control the basic operation of the Web server. Restrict this access to only the Webmaster. htdocs or documents - This is where all the static HTML pages are contained and is often referred to as the "document root". Often, one may find that a site will create a subset of directories associated with the document root to store icons, images, and java context. For the sake of simplicity, we've combined all of these types of files under the htdocs directory. Public Web sites will provide read capability to everyone and limit write access to authorized administrators and content providers. logs - This is the home location for the various logs that the Web server records during its operation. Generally, one will find access logs, error logs, and referrer logs located under this directory. Because of the importance of the information provided within these logs, you should permit read-only access to the Webmaster to this directory and the files stored within. admin or tools - This directory will hold all the nifty utilities and programs necessary for the proper maintenance and operation of your site. Limit access to the Webmaster with read privilege.
Following these guidelines for securing the Web server directories and the files within will help you create an environment that encourages not only security, but also productivity and integrity for your Web development process. The basic rule of thumb with Web server access controls is to establish "least privilege" for all objects that are available. 5. Special Features Many modern Web servers come with a variety of convenient and appealing features that aid in the appeal for a particular Web site. These can include really nifty features such as automatically listing directory contents, executing code directly on the server to dynamically modify the output returned to a browser request, and extending your Web site's document tree to other parts of the server's file system. However, if these features are not suitably configured, they can also wreak havoc. If these fancy features aren't absolutely necessary, don't make them available. 6. Physical Controls You can have all the file and directory access controls properly configured, strong passwords enabled, and even encryption available, but without proper physical security controls, all your security is for naught. From our experience, you would be amazed at how lax some organizations are regarding the physical security of their servers. Even if there are proper measures in place for entrance to the building, you still need to be concerned about internal threats and take appropriate precautions. According to a 1998 FBI survey, 80% of most break-ins come from the inside, not the outside. Don't be just another statistic; set the example. A few things that you can do to protect your Web server include: placing it in a locked room, enabling the timeout or terminal lockout feature, or even locking or removing bootable devices on your server. A key point to realize about security is that nearly all operating systems place the foundation of their security architecture at the physical server level. Unfortunately, physical security is often an afterthought when deciding where to place a server. Such consequences can leave servers completely open to a security breach. 7. Auditing and Accountability The logs offered by the Web server offer a plethora of information and messages critical to its operation and security. The more you know about what is occurring on your server, the easier it will be to track down problems and potential abuse. Besides the operating system logs, there are two primary logs generated by the Web server that you should review on a daily basis: access logs and error logs. The access logs provide details of any access to your server including the URL object requested, the hostname and sometimes the userid of the requestor, and the date and time of URL request. The error log provides information regarding problems of the Web server. These include such interesting tidbits as identifying documents that don't exist on the server, attempts to access restricted documents, and errors generated from CGI scripts. Your habit should be to review this daily for anomalous entries. If you feel overburdened by looking at all that data, then use utilities such as swatch, found at:
ftp://ftp.stanford.edu/general/security-tools/swatch/swatch-2.2.tar.gz to help sift and manage all that voluminous data and swiftly pull out all the juicy security stuff. 8. Access Control Methods Besides providing simple password management and directory access controls, you can provide advanced access controls to limit authorized Web users to specific documents or locations within your Web server. Some of these methods are described below. Modern Web servers provide the ability to restrict access to authorized parties based upon the browser's host IP address or domain name. Although this is not necessarily a control that you would like to apply to your public Internet Web server, you could do this for restricted Web servers such as ones that you may have on your Intranet. Another method to restrict access to the Web server is through the use of specialized network security protocols such as MIT's Kerberos or DCE authentication. At present, the only restriction with using these type of network protocols is that there isn't a lot of support in the commercial Web server market; therefore, expect to use them primarily with free Web server products such as Apache. Many Web servers provide the ability to restrict by user authentication credentials. This can be enabled uniquely for each type of Web server and comes in a variety of forms including userid/password combinations, challenge-response dialogues, or public key certificates. Regardless of the mechanism, the Web server is requiring the user to provide proper identification before permitting access to the restricted HTML documents that it serves. 9. Active Content "Active content", the ubiquitous term used for Java, ActiveX, Server-Side Includes, Active Server Pages, and Common Gateway Interface scripts, is often utilized by many Web sites to provide interactive, user-initiated applications. While the Web has dramatically excelled in popularity due to the appeal of these enriched codes, this content has also brought a new age of security concerns. For example, CGI scripts are one often overlooked loophole in your security design and configuration. CGI scripts generally pass user-specific data to a program(s) running on a Web server. The program processes that data and the server passes the program's response back in HTML format to the Web browser. If the code improperly processes inputted data, the script could execute arbitrary commands on the Web server under the effective userid of the httpd process. When installing a Web server, make sure that it does not run under the ID of a privileged user, because that can lead to compromise. In most cases, the httpd process typically runs as nobody, but you may find a careless server running under a privileged account, even root. Thus, the relentless attacker will attempt to input data that can confuse the script and ultimately exploit the security of the Web server and its data. A good place to start learning about Web security weaknesses is the Unofficial Web Hack FAQ at:
http://www.nmrc.org/faqs/www/index.html http://www.rstcorp.com/javasecurity/applets.html http://www.w3.org/Security/Faq/www-security-faq.html#contents You may consider using programs like CGIWrap (http://www.umr.edu/~cgiwrap/dist/) or suEXEC (http://www.apache.org), which can run CGI scripts under another userid outside of the httpd process id. Although CGIWrap and suEXEC are not a panacea for all CGI exploitations, their goal is to reduce the risk that malformed data passed to a particular script doesn't execute under the server's httpd user account. Sanitizing your code is the best way to secure your code; check out http://www.cert.org/ftp/tech_tips/cgi_metacharacters for a good explanation of general sanitizing guidelines. As part of your Web server check-up, you should include a comprehensive review of all custom code and scripts available on the server. Many scripts are written in the Perl language. To aid in your own Perl code review, you can use automated utilities, such as Tom Christiansen's latro (short for Latrodectus Cyberneticus):
http://language.perl.com/news/latro-announce.html or even taintperl, which is available as part of the Perl interpreter. Additionally, here are a few common items that should be investigated on a periodic basis for your code reviews:
a. Interpreters placed within the cgi-bin directory b. CGI scripts located in a central location, preferably cgi-bin or scripts directory c. Improperly coding for memory management prior to performing an operation d. Passing unchecked input to command interpreters e. Opening files based on unchecked user input f. Writing unchecked input to system resources g. Cleaning user input, such as parsing out non-allowable characters h. Functions which may have access to system commands
j. For Win32 systems, attempting to compile your Perl code to executables (see www.perl2exe.org for more information) will limit the impact of having your program exploited once it is pilfered or stolen 10. Remote Administration There are multiple methods to administer a Web site; the key is selecting the method that doesn't compromise the overall security of the Web site. Many sites rely on obscure URL directories with basic password combinations. While this may discourage the nave and impatient, this won't keep the persistent and wily hacker from revealing this treasure. When trying to create a suitable remote access method to administer your Web site, use common sense and prudent controls to keep the unauthorized out. If your site has the budget, we recommend enhancing your authentication into your administrative Web functions using tools that provide either encrypted channels or one-time based password mechanisms. Encryption Schemes The ability to keep Web transactions secure has long been a concern since the early '90s. Fortunately, there are many fundamental technologies that protect information as it traverses the Internet. Encryption has become a much more mainstream topic than in years past. While the focus of this article is not of encryption, a discussion of Web security wouldn't be complete without it. Therefore, we will briefly discuss two popularly used and influential protocols: Netscape's Secure Sockets Layer (SSL) protocol, and Mastercard and Visa's Secure Electronic Transaction (SET) protocol. SSL is a generic security protocol that can protect various TCP/IP communication channels. While SSL is notorious for providing confidentiality and integrity for HTTP transactions, it can be used to protect such services as ftp, NNTP (news), SMTP, POP3, and an assortment of others. SSL's primary goals are to provide authentication and nonrepudiation, data confidentiality, and integrity to data streams. For more information on SSL, go to Netscape's SSL reference site at: http://www.netscape.com. SET is a specific protocol used to encrypt credit card transactions among customers, merchants, and banking institutions. Unlike SSL, SET doesn't bother with encrypting arbitrary TCP/IP transactions; rather it provides confidentiality of privacy to financial data for electronic commerce-based transactions. SET requires a specific exchange of cryptographic credentials between the merchant and the participating bank so that the customer's account number is kept private. There are three components that make up the SET payment system: the "virtual wallet" storing the customer's credit card information which can be downloaded from vendors such as Microsoft at:
http://www.microsoft.com/wallet/downloads/default.asp second, a merchant Web server with a site certificate capable of digitally signing payment information; and third, the payment server running at the financial institution. For further information regarding SET, see:
http://www.software.ibm.com/commerce/payment/whatisset.html You may be asking yourself how to enable your Web server to provide SSL or SET based transactions. In either case, you must register your site with a Certificate Authority (CA). A few of the well-known CAs that you can select from are Verisign, Thawte, Netscape, and ATT. The details of the process to obtain a certificate with a CA may vary for the type of Web server and CA you use, but will typically follow these basic steps. After you select the CA, fill out the appropriate application form, and pay the fee, you will send in the application for approval. The CA will review the application and verify items such as your organization's domain name and possibly its Dun & Bradstreet number. If the CA approves, they will notify you via email to submit a public/private key pair for certification. You then can generate a key pair using the Web server genkey (used in Apache, varies per Web server) facility. The key generation process will prompt you to follow a series of steps. First, you must pick a desired key length (the higher the better); second, type in random letters to seed the random-number generator; third, provide the name of your CA; fourth, provide information specific to your organization; and finally, provide a secret pass-phrase used to store your private key on your site. You then must email your key pair to the CA for them to acknowledge, and generate your final site certificate using this key pair, and mail back to you. After all of this formality, you can install the block of electronic data that the CA provides onto the Web server's hard disk. Conclusion After you have gone through the involved process of securing the Web server, you are ready for business. We have provided a basic guideline of what you should do and look for when securing your Web server. Securing the Web server involves the operating system, the application, and the network to which it is attached. An unsecure network device could lead to your Web server's being compromised. After all these security measures are in place, can you go to bed at night feeling secure? Probably not. Security issues change on a daily basis. New exploits come out daily; your daily administration of the site may introduce weaknesses you don't know about. Thus, we recommend the continuous process of administering security. Security measures can never be static, or you may find your hacked Web site of the front page of the newspapers someday. Bibliography Garfinkel, Simson and Gene Spafford. Web Security & Commerce. 1997. O'Reilly & Associates, Inc. Rubin, Aviel, Daniel Geer, and Marcus Ranum. Web Security Sourcebook. 1997. John Wiley and Sons. Stein, Lincoln D. Web Security: A Step-by-Step Reference Guide. 1998. Addison Wesley.
About the AuthorRay Soriano is a Manager in the Information Security Services practice for Ernst & Young LLP. Mr. Soriano has been specializing in Attack and Penetration testing, extranet security, and architecture design and implementation for a number of years.
Gary Bahadur is a manager in Ernst & Young's Information Security Services group specializing in UNIX and Internet security attack and penetration testing. He can be reached at: gary.bahadur@ey.com.
|