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

results matching ""

    No results matching ""