Thwarting attacks on Apache Web servers

Computerworld - How can you lower the risk of a successful attack on your Apache Web server? This excerpt from Maximum Apache Security, a hacker's guide to protecting your Apache Web server (Sams Publishing), outlines steps you can take to lower the risk of a successful attack on your Web server.

How Security Disasters Develop

The scenarios you'll face are the following:

• 
  
• Intruders gaining simple access
  
• Denial of service
  
• Defacement or total system seizure
  

Let's run through the factors that invite these situations.

Intruders Gaining Simple Access

Simple unauthorized access can happen in several ways:

• 
  
• Insiders who once had authorized access (former employees or developers, for example) return to haunt you.
  
• Your users make bad password choices on other networks that fall to hackers. This leads to cross-network unauthorized access.
  
• Your underlying operating system has holes, and diligent hackers exploit it to gain limited access.
  
• The tools you use in conjunction with Apache are flawed.
  

Research studies show that some 70% of serious intrusions come from insiders. I encounter such cases all the time:

• 
  
• In January 2002, a prominent online porn provider contacted me. A former developer defected to another firm and took the porn provider's client list with him. He also took username/password databases and was using these, through anonymous remailers, to solicit its clients. Adding insult to injury, he also broke into my client's servers.
  
• In 2001, I audited a system that offered bullion-backed credit/debit cards. Developers who had since quit left behind backdoors to secure remote access administrative sections through PHP, with SSL client certificates.
  
• In 2000, a defense contractor contacted me. Its skunk works division used a centralized password server that housed 4,500 username/password pairs. Of users connected to these, more than 800 were no longer with the firm, and of these, 42 were still utilizing network resources without authorization—and these folks build nuclear weapon components.
  

To guard against these situations, when you terminate a user, remove the account. Also, preserve all files and directories associated with that user on backup media. (You may later need these for evidence.) And, you'd benefit by installing monitoring tools that record user activities.

Furthermore, in enterprise environments, try to isolate development boxes from production boxes. That is, have your developers do their work on test bed systems that mirror your production system's setup. That way, developers never actually have access to your enterprise system. A simple code audit prior to moving their work over to the enterprise box can then determine whether malicious code exists therein.

Users and System Security

As a rule, you shouldn?t let many people access your Web host from the inside. For example, Web servers aren't boxes that you'd normally put shell or Windows user accounts on. Rather, you should restrict these machines to Web services alone. That's a given.

However, you'll still have portions of your Web site that only authorized remote users can access, such as areas that house premium Web services for paying customers. This always entails passwords, and you can use various approaches for this, including simple, native Apache password controls, or database-based password access.

These approaches are fine, but harbor the same inherent weakness: If users create their own passwords, those passwords will invariably be weak. So in the end, it doesn't matter what controls you institute.

Encryption is vital, and there's no debating that, but even "strong" encryption fails when users make poor password choices, and they will. Users are lazy and forgetful. To save time and simplify their lives, most users create passwords from the following values:

• 
  
• Their birth date
  
• Their Social Security number
  
• Their children's names
  
• Names of their favorite performing artists
  
• Words that appear in a dictionary
  
• Numeric sequences (like 90125)
  
• Words spelled backwards
  

These are terrible choices, and most cracking tools can crack such passwords in seconds. In fact, good passwords are difficult to derive, even when you know encryption well, for several reasons.

First, even your local electronic retail store sells computers with staggering processor power. Such machines perform many millions of instructions per second, thus providing attackers with the juice to try thousands of character combinations.

Furthermore, modern dictionary attack tools are advanced. Some, for example, employ rules to produce complex character combinations and case variations that distort passwords well beyond the limits of the average users' imagination. Thus, even when users get creative with their passwords, cracking tools often prevail.

Worse still, cross-network password attacks and compromises are common. Suppose that your users have Hotmail or AOL accounts (or any account that provides them with mail, chat, or other services elsewhere). Ninety percent of users aren't savvy enough to make different passwords for different accounts. Thus, their Hotmail accounts have the same username/password pair as their AOL account.

These conditions invite cross-network password compromise. Suppose that crackers expose several thousand Hotmail passwords—this has happened before. Suppose further that within that lot, twenty such victims also have accounts on your system. Suddenly, attackers have twenty valid username/password pairs from your system.

This won't get them far, but it will get them inside your premium service area, which probably deploys JSP, ASP, PHP, Perl, Python, ActiveX, or other technologies that interact with your database. Attackers can then study that technology and try attacks that they couldn't otherwise try if they had access only to the home page. Over time, if there's a weakness, they'll find it.

To ward off such situations as best you can, implement the following controls whenever possible:

• 
  
• Set passwords to expire every 60 days, with a 5-day warning and a 1-week lockout, if your operating system supports it.
  
• Install proactive password checking, enforcing the maximum rules (using at least a 100,000-term dictionary).
  
• Periodically check user passwords against the largest wordlist you can find. You can automate this procedure using Perl on Windows, Unix, and Mac OS X.
  
• Watch security lists for new password exploits.
  
• Force users to create a new and unique password for each host they have access to. Take logs from your proactive password checker that contains passwords users previously tried and append these to proactive password checking wordlists on other hosts. This way, users' bad password choices follow them across the network.
  
• Provide your users with basic education in password security. Even a simple Web page explaining what makes a weak password is good. Users will read this material if you offer it.
  

Denial of Service

A denial-of-service (DoS) attack is any action (initiated by a human or otherwise) that incapacitates your host's hardware, software, or both, rendering your system unreachable and therefore denying service to legitimate (or even illegitimate) users.

In a DoS attack, the attacker's aim is straightforward: to knock your host(s) off the Net. Except when security teams test consenting hosts, DoS attacks are always malicious and unlawful.

Denial of service is a persistent problem for two reasons. First, DoS attacks are quick, easy, and generate an immediate, noticeable result. Hence, they're popular among budding crackers, or kids with extra time on their hands. As a Web administrator, you should expect frequent DoS attacks; they're undoubtedly the most common type.

But there's still a more important reason why DoS attacks remain troublesome. Many such attacks exploit errors or inconsistencies in vendor TCP/IP implementations. Such errors exist until vendors correct them, and in the interim, affected hosts remain vulnerable.

An example is the historical Teardrop attack. This attack involved sending malformed UDP [user datagram protocol] packets to Windows target hosts. Targets would examine the malformed packet headers, choke on them, and generate a fatal exception. When Teardrop emerged, Microsoft quickly re-examined its TCP/IP stack, generated a fix, and posted updates.

However, things aren't always that easy, even when you have your operating system's source code, as Linux users do. As new DoS attacks arise, you may find yourself taking varied actions depending on the situation (such as patching software, reconfiguring hardware, or filtering offending ports).

Finally, DoS attacks are especially irritating because they can crop up in any service on your system. In a moment, we'll examine a DoS attack that Apache sustained in 2001. However, even though Apache has a good record in this area (not many DoS vulnerabilities), that's no cause to rejoice. Your operating system may harbor weaknesses, too, as can many of its services. So, even when you have a bug-free Apache distribution, this doesn't offer any guarantee that you'll escape DoS attacks.

An Apache-Based Denial-of-Service Example

A serious Apache vulnerability surfaced on April 12, 2001, when Auriemma Luigi discovered (and William A. Rowe, Jr. confirmed) that attackers could send a custom URL via Web browser and thereby hang Apache, or run the target's processor to 100% utilization.

Attackers could perform this DoS attack in one of three ways:

• 
  
• Issue a GET request consisting of 8,184 / characters
  
• Issue a HEAD request consisting of 8,182 A characters
  
• Issue an ACCEPT of 8,182 / characters
  

As Mr. Luigi explained, in both Windows 98 and Windows 2000, if an attacker sent two or more strings from different connections, the targets would crash (and all connections would thereafter fall idle).

The problem affected all Apache versions earlier than version 1.3.20 on the following platforms:

• 
  
• Microsoft Win32
  
• Microsoft Windows NT
  
• Microsoft Windows 2000
  
• OS/2
  

As reported by the Apache team:

Apache patched this problem in version 1.3.20. However, as I related earlier, Apache isn't your only concern. You must be ever diligent to monitor security advisory lists for your operating system and any applications or modules that run on your Web host.

Defacement or Total System Seizure

Your security should never lapse so far that attackers could deface your site or seize control of your Web hosts. Yet, this happens at least 50 times a day, all over the world. I could enumerate a dozen reasons why, but they all trace back to two root problems: the failure to adequately plan initial Web host configuration, and the failure to keep systems patched and up-to-date.

First, securing your Web host really begins even before installation, when you make your first crucial decision: the decision of what type of host you're building. The most common types are as follows:

• 
  
• Intranet Web hosts—Hosts without Internet connectivity, typically connected to a Local Area Network
  
• Private or extranet Web hosts—Hosts that have Internet connectivity but provide services only to a limited clientele
  
• Public or sacrificial Web hosts—Garden-variety Web hosts that users known and unknown can access publicly, 24 hours a day, on the Internet
  

Each type demands a different approach. On intranets, you may provide network services that you'd never allow on a public Web server (and these would pose infinitely less risk). Pages that interface with ActiveX are good examples. Default Linux or Windows/IIS installations include many services that your Web host can do without, including the following:

• 
  
• File Transfer Protocol
  
• finger
  
• Network File System
  
• R services
  

You must decide which services to provide by weighing their utility, their benefits, and the risks they pose.

File Transfer Protocol

File Transfer Protocol (FTP) is the standard method of transferring files from one system to another. In intranet and private Web hosts, you may well decide to provide FTP services as a convenient means of file distribution and acceptance. Or, you might provide FTP to offer users an alternate avenue through which to retrieve information that is otherwise available via HTTP.

For public Web servers, though, you should pass on public FTP. If your organization needs to provide public FTP services, consider dedicating a box specifically for this purpose. This is especially true if your developers have onsite access to the system. Consider using Secure Shell instead, which ships with an easy-to-use, graphical file manager that allows host-to-host transfers via SCP.

finger

fingerd (the finger server) reports personal information on specified users, including their username, real name, shell, directory, and office telephone number (if available). This is primarily an issue for Unix-based servers.

finger is nonessential, and exposes your system to intelligence gathering. Dan Farmer and Wietse Venema discussed the benefits finger offers to crackers in their paper Improving the Security of Your Site by Breaking Into It:

Crackers can use this information to track your staff's movements, and even identify levels of trust within your organization and network. (At bare minimum, attackers can build user lists and establish other possible avenues of attack.)

Network File System (NFS)

Network File System (NFS) provides distributed file and directory access, and allows remote users to mount your file systems from afar. On the remote user's machine, your exported file systems act and appear as though they're local. NFS services therefore vaguely resemble file and directory sharing on Windows and Mac OS.

In internal networks, you might well use NFS for convenience. For example, using NFS, you can share out a central directory hierarchy located on a RAID (and containing essential tools) to workstations system-wide. Or, you can use NFS to share out user home directories. This will ensure that users have access to their files even when they login to different machines. Hence, user bozo can login to linux1.samshack.net, linux2.samshack.net, or scounix.samshack.net and still have an identical /home directory.

Note, however, that basing or placing critical services on NFS volumes is a dangerous practice on enterprise systems. Here's why: Attackers need only knock out a single service (NFS) to down thousands of sites. For example, imagine if you RAID-out all your virtual domains to individual co-located boxes so that your customers can manage their files, but you still have central control. If attackers knock out your NFS, all your customers' Web sites will experience outages until your engineers restart NFS. Try to avoid basing your enterprise on systems that have such a vulnerable single-point-of-failure.

If you do use NFS, though, take these steps:

• 
  
• Create separate partitions for file systems you intend to export, and enable the nosuid option on them.
  
• Export file systems read-only unless otherwise necessary.
  
• Limit portmapper access to trusted hosts. (Add portmapper and your approved host list to /etc/hosts.allow. After you've done that, add portmapper to /etc/hosts.deny and specify ALL).
• Never export your root file system.
• Your NFS server is configured by default to deny access to remote users logged in as root. Do not change this.

Otherwise, unless you have to, don't run NFS on systems that support public Web servers. The benefits outweigh the risk by a wide margin.

The R Services

The R services (rsh, rlogin, rwho, and rexec) provide varying degrees of command execution on, or interaction with, remote hosts, and are quite convenient in closed network environments. However, these have no place on a public Web server. Let's briefly run through each one and what it does.

rshd (The Remote Shell Server): rshd (the Remote Shell server) allows remote command execution. The client program (rsh) connects and requests a shell on the specified remote host. There, rshd opens the shell and executes user-supplied commands. rsh services are not suitable for publicly available Web servers. Don't install rsh unless you really need it.

rlogind (The Remote Login Server): rlogin is much like Telnet. In fact, once you log in using rlogin, things will work exactly as if you were using Telnet. The difference is this: rlogin is designed to automate logins between machines that trust one another. In intranet environments or closed networks, providing rlogin services is fine, but they're not essential on a public Web host. Don't install rlogind unless you really need it.

rexecd (The Remote Execution Server): rexec services are antiquated, but still available on Linux and many Unix systems. rexec offers remote command execution, much like rsh. The chief difference is that users must supply a password to execute commands with rexec. However, even with this level of protection, I would still recommend disabling rexecd on public Web hosts.

Other Services

Next, we?ll cover additional services that might be running if you didn't personally perform the installation, or if others had previously administered your Web host.

This is a common scenario. Your organization has been using a box for development for several months. Suddenly, you're informed that the box should be converted to a Web or intranet host. Under these conditions, you should perform a re-installation. However, if you don't, you may need to disable services that, although perfectly acceptable on a standalone or internal server, could pose security risks on a Web server.

Things that likely don?t belong on your Web server include the following:

• 
  
• AOL Instant Messenger
  
• CVS (use a separate box for that)
  
• Gopher or other antiquated servers
  
• ICQ
  
• LDAP (unless you really need it)
  
• Networked games (for example, Quake)
  
• PCAnywhere, DoubleVision, or CloseUp
  
• POP or IMAP servers
  
• RealAudio or other sounds clients or servers
  
• Unix talk
  
• Yahoo! Messenger
  

Table 2.3 addresses additional services and utilities that default installations sometimes dump onto your drive, what they do, and suggestions on each one.

Table 2.3 Other Network Services and Daemons
Service	Discussion
amd	amd is a tool for automatically mounting file systems and is often used in NFS-enabled environments. Hence, it's a strong candidate, likely to appear on intranet hosts. If you're migrating an intranet host to a public Web host, check for amd. If it's running, ensure that it isn't needed, and if not, disable it.
bootparamd	bootparamd is a tool for remotely booting Sun systems. It has no place on a public Web host, so if you find it running, disable it.
dhcpd	dhcpd is the Dynamic Host Configuration Protocol (DHCP) daemon. DHCP allows your system to relay vital network information to incoming clients. Users needn't know their IP address, default gateway, or subnet masks before logging in because DHCP does it all for them. Public Web hosts have no need for DHCP. If you find that dhcpd is running, disable it.
gopherd	Gopher is an antiquated (but effective) document distribution system from the University of Minnesota. Gopher was actually the Web's predecessor and was in many ways similar. Originally accessible only via command-line interface, Gopher became the rage following the introduction of graphical Gopher clients. While it's true that most mainstream Web clients also support Gopher, there are comparatively few instances in which you'd actually provide Gopher services. Some distributions turn Gopher on by default so be sure to check for it and disable it.
innd	innd is the Internet News daemon, a service not generally needed on public Web hosts.
lpd	lpd is the line printer daemon, also a service not generally needed on public Web hosts (though often seen on intranet hosts). If you find lpd running, disable it.
portmap	portmap translates RPC program numbers into DARPA protocol port numbers, and is only needed if you're providing RPC services like NFS, rusers, rwho, and so on (which, on a Web host, is inadvisable).
smbd	smbd is the Samba server. It provides Server Message Block/LanManager-like services for Unix systems. This allows Unix boxes to serve as file servers in Microsoft-centric networks, and is therefore a common choice for intranet hosts. On a public Web host, disable smbd.
ypbind	ypbind allows client processes to bind or connect to NIS servers. Generally, you wouldn't run NIS on a public Web server, so I recommend disabling it.
ypserv	ypserv serves local NIS information to remote hosts. Generally, you wouldn't run NIS on a public Web server, so I recommend disabling it.

If you don't know what services your Web host is running, try scanning the system from port 0 to port 65000. This will reveal many (but not all) running services.

Tip

The bottom line is this: When you build your Web host, try the "minimal is better" philosophy by eliminating everything that isn't necessary, including the X Window System, games, multimedia, demos, development example files, sample applications, additional shells, and so on.

This article was excerpted from Maximum Apache Security, a hacker's guide to protecting your Apache Web server, with permission from Sams Publishing, all rights reserved.