6.7 Web Services Countermeasures

  • You should ensure that all Internet-based server software and components (Microsoft IIS, Apache, OpenSSL, PHP, mod_perl, etc.) have up-to-date patches and are configured to prevent known public exploits and attack techniques from being successful.

  • If you don't use script languages (such as PHP or Perl) in your web environment, ensure that associated Apache components such as mod_perl and PHP are disabled. Increasingly, vulnerabilities in these subsystems are being identified as attackers find fewer bugs in core server software.

  • Many buffer overflow exploits use connect-back shellcode to spawn a command shell and connect back to the attacker's IP address on a specific port. In a high security environment I recommend using aggressive firewalling to prevent unnecessary outbound connections (so that web servers can send traffic outbound only from TCP port 80, for example). In the event of new vulnerabilities being exploited, good egress network filtering can flag suspicious outbound connections from your web servers and buy you time.

  • Prevent indexing of accessible directories if no index files are present (e.g., default.asp, index.htm, index.html, etc.) to prevent web crawlers and opportunistic attackers from compromising sensitive information.

Here are some database and custom-written web application recommendations:

  • Don't expose debugging information to public web users if a crash or application exception occurs within your web server or application-tier software.

  • If you use backend SQL databases, tie down the SQL user accounts used by public web servers so that they have limited access to potentially damaging stored procedures (if any) and have decent permissions relating to reading and writing of fields and tables from the database.

Here are Microsoft IIS and Outlook Web Access-specific recommendations:

  • Microsoft has published security checklists and tools for best practice IIS configuration, including URLscan and the IIS lockdown tool available from http://www.microsoft.com/technet/security/tools/tools.asp.

  • Under IIS, ensure that unnecessary ISAPI extension mappings are removed (such as .ida, .idq, .htw, .htr, and .printer).

  • Don't run Outlook Web Access at a predictable web location (for instance, /owa, /exchange, or /mail), and use SSL in high-security environments to prevent eavesdropping. Ideally, remote access to Exchange and other services should be provided through a VPN tunnel.

  • Minimize use of executable directories, especially defaults such as /iisadmpwd, /msadc, /scripts, and /_vti_bin that can be abused in conjunction with Unicode attacks or even backdoor tools to retain server access.

  • Disable unnecessary HTTP methods such as PUT, DELETE, SEARCH, PROPFIND, and CONNECT. These default IIS features are increasingly used by new exploit tools to compromise servers.

  • If the PUT method is used, ensure that no world-writable directories exist (especially those that are both world-writable and -executable).