Defending Your Web Server

Insecure applications and scripts expose Web servers to attack. Here's how to batten down the hatches.

by Rik Farrow

Network Magazine

Some people consider Web site defacement a trivial thing, equivalent to the "tags" spray-painted by street gangs. However, if someone can replace your Web server's home page, you have a security problem.

I recently came across a Web site called Attrition (https://www.attrition.org) that lists Web server defacement statistics. What really caught my eye is that Windows NT servers are consistently getting defaced. For instance, out of 350 reported defacements in April 2000, 64 percent were on Windows NT (which averages about 60 percent in other months).

If you lump all Linux distributions together, they come in second (with an average rate of 17 percent), followed by Solaris (at 10 percent per month). Another interesting fact from Attrition is that statistically, most defacements happen on Sunday.

You might think NT sites get defaced most often because NT has become the predominant Web server platform. However, that's not true. A Web site survey by Netcraft (https://www.netcraft.com/survey/) shows that Apache Web servers outnumber all Microsoft-based solutions by almost three to one. In other words, even though NT Web servers are not the most popular, they are defaced much more frequently.

Regardless of the platform you use for your Web server, you'll want to secure it carefully. This column focuses on things you can do to secure NT-based Web servers, and it also makes suggestions for Unix and Linux-based servers.

On This Page

Unix VS. NT
Scripting Follies
Permissions And Ownership
Bastions
Safe And Sound

Unix VS. NT

On the Internet, there's a lot more information available for securing Unix and Unix-based Web servers than for securing NT Web servers. In general, Unix offers many more potentially vulnerable network services (and has features not present in NT) that make it easier to elevate privileges once you break into the system.

So if NT has better (potential) security than Unix or Linux, why does it get hacked so often? The problems are not so much in NT itself, but in Internet Information Server (IIS). IIS attempts to do a lot more than Apache, which causes problems.

In 1999, a buffer overflow attack for IIS was discovered. An exploit published by eEye (https://www.eEye.com), a New York-based security team, permitted the attacker to upload and execute the code of his or her choice. While this attack relied on the buffer overflow within IIS (yes, you do want to upgrade your server if you haven't within the past year), it also relied on other features of the Win32 API that make it simple to do things like upload code (a single function call).

The Apache Web server has not suffered from buffer overflow attacks in many years. Within the last year, the only security patch to Apache had to do with the CERT advisory warning. The warning, CERT Advisory CA-2000-02, stated that error messages sent back by Web servers could include scripting if an attacker creates the Web page used to access the Web server. Microsoft also released a patch to deal with this issue in IIS.

Besides the buffer overflow, a security specialist named Rain Forest Puppy (RFP) released a Perl script that could execute arbitrary commands on IIS servers that had one of a variety of sample scripts on them (see Resources, page 114). Coincidentally, Attrition reported an all-time, one-day record for defacements shortly thereafter. You might consider writing a script that grabs your home page, compares it to what it should be, and alerts you if it has changed.

The Apache software also comes with example scripts. In older releases, these scripts were installed in cgi-bin, the default scripts directory. If you left these example scripts there, they could be exploited. Newer releases of Apache have moved these scripts to a sample directory not accessible by default.

Whether you are using IIS or some other Web server software, remove all sample scripts. It's OK to keep these scripts for reference, but just don't leave them in the Scripts folder under NT or under cgi-bin in Unix. Both directories are found in the server root directory. IIS and Apache can have additional script directories, so you must treat these the same way, including subdirectories (for example, cgi-bin/photoads, or Scripts/Tools).

Scripting Follies

If you do include scripts in your Web server, you must check them carefully for subtle flaws. The most common error in writing scripts (or programs) for execution on Web servers is to trust client input. A classic Unix exploit includes a command terminator at the end of some expected input; for example, a name or e-mail address. If the script trusts the input, it may pass the input unmodified as an argument to a Unix command, which means the portion after the command terminator (a semicolon, newline, or other character) would be executed by the shell.

This is not just a Unix issue. Microsoft's Visual Basic also includes a shell function that can use cmd.exe to run other programs on the NT server. Perl, which is used on both Unix and NT servers, can also be manipulated with unexpected input.

Besides not trusting user input, the Web scriptwriter must not trust anything passed from the remote client. While the scriptwriter expects that his or her script is receiving input from a browser, an attacker can simulate a Web browser request via either a tool (like RFP's exploit) or by simply hand-entering a browser request using Telnet or NETcat.

Examples of this include trusting the value of HTTP-REFERRER or hidden form variables. An attacker has complete control over what gets sent to your Web server, and it is your job to exclude the unexpected.

CERT put out a sample Perl script years ago that filters out any unexpected characters received as input. The scriptwriter creates a set of expected characters and uses a substitute command that replaces anything not in this set with an underscore character.

An issue specific to NT has to do with passwords. NT's security model means that user names and passwords must be included in scripts that will connect to Access or SQL databases. The scripts' directories should not appear within the Web document hierarchy (webroot or htdocs), and the scripts themselves should be protected. IIS offers one level of protection (on top of NT File System [NTFS] Access Control Lists [ACLs]), and should be configured only to permit execution for scripts.

NT and IIS have had problems preventing read access to scripts. Six tricks for reading instead of executing scripts have appeared in the last several years-all quickly patched by Microsoft. Five of these tricks simply appended some characters to the end of a script's pathname. The sixth one used an example script to read arbitrary files on the Web server.

Permissions And Ownership

Although Web server software does attempt to control access, it still makes a lot of sense to take advantage of the operating system's ownership and permissions, or access control. Whether you are using NT or Unix, documents and scripts should never be owned by the user account that runs the Web server. On NT systems, this account is named IUSR__xxx, where xxx is the system name. Most Unix and Linux systems use the account nobody, although some have a special account name (beginning with www) for running the Web server.

If documents and scripts are not owned by the Web user account, and not writeable by the Web user account, they cannot be modified, even if there's a flaw in the Web server software or in scripts executed by the Web server. By simply correcting ownership and permissions (ACLs under NT) to prevent writing, many defacements could have been prevented- especially those on NT systems.

Directories within the Web hierarchy must also be protected. Both NT and Unix permit files within a directory to be deleted if the directory permits this action. On Unix, this requires write and execute permission. In NT, there is a specific delete permission in NTFS on directories. What is not generally known about NTFS is that delete permission on a directory implies delete-tree, which permits the removal of files and subdirectories.

Bastions

Web servers are most secure when configured as bastion hosts. Bastion hosts, so named because they have been fortified, have software removed and network services disabled.

Within NT, you can unbind NetBIOS from the network interface and disable all services except EventLog, NT LAN Manager (NTLM) Security Support Provider, Protected Storage (if you have this), and Remote Procedure Call (RPC) service. These services are required for running IIS (and for logging in to maintain the system). You can also use IP filtering under the Advanced menu of the Network control panel to permit access only to port 80/TCP, as the RPC services (ports 135, 137, 138, and 139) are the common problem ports for NT systems.

If you are working with Unix or Linux, disable all services started from within /etc/inetd.conf and remove the links to start-up scripts in the /etc/rc.d directories that start network services.

With both NT and Unix, reboot and use netstat-a to list the services still listening (look for the flag LISTENING in the far right column). On Unix, you should see only httpd (port 80) listening, along with local domain sockets if you are running X (using a text console is more secure and recommended). On NT, all you should see are the RPC services and IIS. Note that running the RPC services and IIS results in some ports being open in the 1,025 to 1,035 range: This is to be expected.

Only system administrators should have accounts on the bastion host. Web content is most safely added from the development Web server to the bastion by putting the files on zip disks or writeable CDs and installing them from the console. In the NT world, helpful tools like FrontPage have also been helpful to hackers.

Of course, protect the bastion host with a firewall. While this may look like overkill, it's simply like wearing seatbelts in a car with airbags. The firewall should also protect the internal network from the Web server, just in case it still gets compromised. Most commercial firewalls support three network interfaces, and the Web server(s) belong on the Demilitarized Zone (DMZ, or optional) interface.

Safe And Sound

Operating system vendors have done a lot to make their systems friendlier and easier to use. However, placing a Web server on the Internet has nothing to do with ease-of-use for the owners of the Web server, and everything to do with the tightest possible security.

Just because an operating system has proven security features, that doesn't mean it will be secure when you add insecure applications. For instance, Microsoft made a big deal about NT's C2 certification, a rating that means an operating system and hardware combination reaches or exceeds an evaluation criterion. However, the C2 certification only applies when NT is not connected to a network! The upshot is, don't become a statistic. Secure your Web servers.

Rik Farrow is an independent security consultant. His Web site, https://www.spirit.com, contains security links and information about network and computer security courses. He can be reached at mailto: rik@spirit.com.

Resources

The Attrition security site keeps Web site defacement statistics. Go to https://www.attrition.org/mirror/attrition/os.html.

A survey of Web server types in use is available at https://www.netcraft.com/survey/. Out of 14,322,950 Web servers in the April 2000 survey, the top three were Apache (62 percent), Microsoft (21 percent), and iPlanet (7 percent).

Steve Sutton provides a helpful Windows NT security guide at https://www.trustedsystems.com/tss_nsa_guide.htm.

Microsoft's Internet Information Server (IIS) 4.0 security checklist can be found at https://www.microsoft.com/WindowsServer2003/iis/default.mspx.

Stefan Norberg has an excellent paper and tools for creating an NT bastion host (and a separate paper for HP-UX) at https://people.hp.se/stnor/.

Australian CERT (AusCERT) NT security suggestions are listed at https://www.auscert.org.au/Information/Auscert_info/Papers/win_configuration_guidelines.html. The U.S. mirror site is located at https://www.securityfocus.com/library/2335/.

The World Wide Web Security FAQ by Lincoln D. Stein is available at https://www.w3.org/Security/Faq/.

Security specialist Rain Forest Puppy (RFP) has a Web site with several IIS exploits. Go to https://www.wiretrip.net/rfp/.

For a complete explanation about C2 certification, go to https://www.multics.demon.co.uk/orange/summary.html.

Click to subscribe