Protecting Web Servers

Web servers can be protected from threats in many ways. Firstly, we recommend that the administrator keeps an inventory of what applications are on the web server and maintains patch levels for all of them. A host-based Intrusion Detection System, such as mod_security for the Apache web server may be used to block certain common attack vectors, such as "wget" and "curl" appearing in GET and POST requests. This will not provide complete protection from remote code inclusion attacks in particular, but will block many common attacks. If the attacker can include arbitrary code in the running application, they will be able to evade most keyword filters. Alternatively, an application proxy can be deployed in front of the web server to filter out these types of malicious requests. A Host Intrusion Detection System (HIDS) program such as Tripwire may be used to monitor the integrity of critical system files.

 HTTP/1.1 500 Internal Server Error
 Connection: close
 Transfer-Encoding: chunked
 Content-Type: text/html; charset=iso-8859-1
 Request: - - [22/Dec/2005:05:26:34 -0600]\
  "POST /xmlsrv/xmlrpc.php HTTP/1.1" 500 603
 Handler: (null)
 POST /xmlsrv/xmlrpc.php HTTP/1.1
 Content-Length: 269
 Content-Type: text/xml
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)
 mod_security-message: Access denied with code 500. Pattern match "wget\x20" at POST_PAYLOAD.
 mod_security-action: 500

 <?xml version="1.0"?><methodCall><methodName>test.method</methodName><params><param>\
 <value><name>',''));echo '_begin_';echo `cd /tmp;wget;chmod +x\
 mirela;./mirela         `;echo '_end_';exit;\/*</name></value></param></params>\

Figure 5. An example of mod_security blocking an attempt to exploit the PHPXMLRPC vulnerability

Correct configuration of web servers such as Apache and scripting languages such as PHP is also crucial. We mentioned register_globals earlier which allows an attacker to set variables which can cause problems if the developer has not specifically initialized them. The allow_url_fopen configuration directive should be disabled if possible as this prevents remote code-inclusion attacks. The Open Web Application Security Project provides further details on securing web servers and applications.

Programmers can create more secure applications by rigorously validating all input they receive. Where 'include' statements exist in PHP there should be no way for an attacker to control the name of the file being included. If input is going to be echoed back to the user, the application must take care that Cross-site scripting (XSS) attacks cannot occur. The typical example is to disallow or escape '<' and '>' characters to prevent the attacker from entering javascript code. Ideally SQL operations should be in the form of prepared statements so that data is treated purely as data and does not have the chance to become code, as it does in an SQL injection exploit. A full treatment of this subject is beyond the scope of this article but a good reference for PHP developers is "Essential PHP Security" by Chris Shiflett and published by O'Reilly press. There is also a good set of recommendations for programmers and system administrators as part of the SANS top 20 vulnerabilities, in section C1.3. These include making use of the Hardened-PHP Project's Suhosin tool to control the execution of PHP scripts, migrating to the latest version of PHP and making use of the PHP Data Objects extension when performing SQL queries.

We also recommend that a Network Intrusion Detection System is used which should alert the administrator to events such as connections from web servers to an IRC channel outside the organisation, the port-scanning activity that will be associated with some of the worms and scanning tools, and possibly the increase in traffic that may occur if the server is sending spam email or hosting a phishing web site. Lastly, the administrators should be responsive to the postmaster and abuse email addresses at their domain, which often provide rapid warning of incidents in progress.