11.5 Countermeasures

Place Web Servers in Separate Secure Server Security Segment on Network

• An ideal web hosting network should be designed with at least three segments namely Internet segment, secure server security segment often called demilitarized zone (DMZ), internal network.
• Place the web server in Server Security Segment (DMZ) of the network isolated from public network as well as internal network.
• The firewalls should be place for internal network as well as Internet traffic going towards DMZ.

Countermeasures: Patches and Updates

• Scan for existing vulnerabilities, patch, and update the server software regularly.
• Before applying any service pack, hotfix, or security patch, read and peer review all relevant documentation.
• Apply all updates, regardless of their type on an "as-needed" basis.
• Test the service packs and hotfixes on a representative non-production environment prior to being deployed to production.
• Ensure that service packs, hotfixes, and security patch levels are consistent on all Domain Controllers (DCs).
• Ensure that server outages are scheduled and a complete set of backup tapes and emergency repair disks are available.
• Have a back-out plan that allows the system and enterprise to return to their original state, prior to the failed implementation.
• Schedule periodic service pack upgrades as part of operations maintenance and never try to have more than two service packs behind.

Countermeasures: Protocols

• Block all unnecessary ports, Internet Control Message Protocol (ICMP) traffic, and unnecessary protocols such as NetBIOS and SMB.
• Harden the TCP/IP stack and consistently apply the latest software patches and updates to system software.
• If using insecure protocols such as Telnet, POP3, SMTP, FTP, take appropriate measures to provide secure authentication and communication, for example, by using IPSec policies.
• If remote access is needed, make sure that the remote connection is secured properly, by using tunneling and encryption protocols.
• Disable WebDAV if not used by the application or keep secure if it is required.

Countermeasures: Accounts

• Remove all unused modules and application extensions.
• Disable unused default user accounts created during installation of an operating system.
• When creating a new web root directory, grant the appropriate (least possible) NTFS permissions to the anonymous user being used from the IIS web server to access the web content.
• Eliminate unnecessary database users and stored procedures and follow the principle of least privilege for the database application to defend against SQL query poisoning.
• Use secure web permissions, NTFS permissions, and .NET Framework access control mechanisms including URL authorization.
• Slow down brute force and dictionary attacks with strong password policies, and then audit and alert for logon failures.
• Run processes using least privileged accounts as well as least privileged service and user accounts.

Countermeasures: Files and Directories

• Eliminate unnecessary files within the .jar files.
• Eliminate sensitive configuration information within the byte code.
• Avoid mapping virtual directories between two different servers, or over a network.
• Monitor and check all network services logs, website access logs, database server logs (e.g., Microsoft SQL Server, MySQL, Oracle) and OS logs frequently.
• Disable serving of directory listings.
• Eliminate the presence of non web files such as archive files, backup files, text files, and header/include files.
• Disable serving certain file types by creating a resource mapping.
• Ensure the presence of web application or website files and scripts on a separate partition or drive other than that of the operating system, logs, and any other system files.

Detecting Web Server Hacking Attempts

• Use Website Change Detection System (WDS) to detect hacking attempts on the web server.
• Website Change Detection System involves:
  • Running specific script on the server that detects any changes made in the existing executable file or new file included on the server.
  • Periodically comparing the hash values of the files on the server with their respective master hash value to detect the changes made in codebase.
  • Alerting the user upon any change detection on the server.
  • For example: WebsiteCDS is a script that goes through your entire web folder and detects any changes made to the your code base and alert you using email.

How to Defend Against Web Server Attacks

• Ports:
  • Audit the ports on server regularly to ensure that an insecure or unnecessary service is not active on your web server.
  • Limit inbound traffic to port 80 for HTTP and port 443 for HTTPS (SSL).
  • Encrypt or restrict intranet traffic.
• Server Certificates:
  • Ensure that certificate data ranges are valid and that certificates are used for their intended purpose.
  • Ensure that the certificate has not been revoked and certificated public key is valid all the way to a trusted root authority.
• Machine.config:
  • Ensure that protected resources are mapped to HttpForbiddenHandler and unused HttpModules are removed.
  • Ensure that tracing is disabled <trace enable="false"/> and debug compiles are turned off.
• Code Access Security:
  • Implement secure coding practices.
  • Restrict code access security policy settings.
  • Configure IIS to reject URLs with "../" and install new patches and updates.
• UrlScan:
  • UrlScan is a security tool that restricts the types of HTTP requests that IIS will process.
  • By blocking specific HTTP requests, the UrlScan security tool helps to prevents potentially harmful requests from reaching applications on the server.
  • UrlScan screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator.
• Services:
  • UrlScan can be configured to filter HTTP query string values and other HTTP headers to mitigate SQL injection attacks while the root cause is being fixed in the application.
  • It provides W3C formatted logs for easier log file analysis through log parsing solutions like Microsoft Log Parser 2.2.
• Registry:
  • Apply restricted ACLs and block remote registry administration.
  • Secure the SAM (Stand-alone Servers Only).
• IIS Metabase:
  • Ensure that security related settings are configured appropriately and access to the metabase file is restricted with hardened NTFS permissions.
• ISAPI Filters:
  • Remove unnecessary ISAPI filters from the webserver.
• Shares:
  • Remove all unnecessary file shares including the default administration shares if not required.
  • Secure the shares with restricted NTFS permissions.
• Sites and Virtual Directories:
  • Relocate sites and virtual directories to non-system partitions and use IIS Web permissions to restrict access.
• Script Mappings:
  • Remove all unnecessary IIS script mappings for optional file extensions to avoid exploiting any bugs in the ISAPI extensions that handle these types of files.
• Auditing and Logging:
  • Enable a minimum level of auditing on your web server and use NTFS permissions to protect the log files.
• The following is a list of actions that can be taken to defend web servers from various kinds of attacks:
  • Do use a dedicated machine as a web server.
  • Create URL mappings to internal servers cautiously.
  • Don't install the IIS server on a domain controller.
  • Use server-side session ID tracking and match connection with time stamps, IP address, etc.
  • If a database server such as Microsoft SQL Server is to be used as a backend database, install it on a separate server.
  • Use security tools provided with the web server and scanners that automate and make the process of securing a web server easy.
  • Do physically protect the webserver machine in a secure machine room.
  • Do not connect an IIS Server to the Internet until it is fully hardened.
  • Do not allow anyone to locally log on to the machine except for the administrator.
  • Do configure a separate anonymous user account for each application, if you host multiple web applications.
  • Limit the server functionality in order to support the web technologies that are going to be used.
  • Screen and filter the incoming traffic request.

How to Defend against HTTP Response Splitting and Web Cache Poisoning

• Server Admin:
  • Use latest web server software.
  • Regularly update/patch OS and Webserver.
  • Run web Vulnerability Scanner.
• Application Developers:
  • Restrict web application access to unique IPs.
  • Disallow carriage return (%0d or \r) and line feed (%0a or \n) characters.
  • Comply to RFC 2616 specifications for HTTP/1.1.
• Proxy Servers:
  • Avoid sharing incoming TCP connections among different clients.
  • Use different TCP connections with the proxy for different virtual hosts.
  • Implement "maintain request host header" correctly.

How to Defend against DNS Hijacking

• Choose an ICANN accredited register and encourage them to set Registrar-Lock on the domain name.
• Safeguard the registrant account information.
• Include DNS hijacking into incident response and business continuity planning.
• Use DNS monitoring tools/services to monitor DNS server IP address and alert.
• Avoid downloading audio and video codecs and other downloaders from untrusted websites.
• Install antivirus program and update it regularly.
• Change the default router password that comes with the factory settings.

• UDP source port randomization technique defends servers against blind response forgery.
• Limit the numer of simultaneous recursive queries and increase the Times-to-Live (TTLs) of legitimate records.
• Domain Name System Security Extensions (DNSSEC)
• Strong Password Policies and User Management
• Better Service Level Agreements (SLAs) from DNS Service Providers
• Configuring a Master-Slave DNS within your Network
• Constant Monitoring of DNS Servers