Lesson 2: Securing Internet-Accessible Resources in a DMZ

Within the DMZ you must secure resources to ensure that only authorized access takes place. This lesson explores methods for securing Internet Information Server (IIS) and other services commonly located within a DMZ. In addition, the lesson discusses ways of securing data transmissions between resources located in the DMZ.


After this lesson, you will be able to

  • Design a secure configuration for all services and servers located within a DMZ

Estimated lesson time: 60 minutes


Securing IIS

The most common network resource exposed to the Internet is the content on a Web server. Internet Information Server (IIS) 5.0 is included with Windows 2000 Server and allows an organization to host Web sites. This lesson examines the additional configuration that's required to fully secure an IIS server when it's exposed to the Internet.

Although Windows 2000 has increased the default security level from Windows NT 4.0 for computers, you should consider additional security configurations for securing an IIS server. By applying the following recommendations to your Internet-accessible Web servers, you ensure that maximum security is applied to prevent attacks against the Web servers:

  • Change all default account names. Attackers commonly attempt to connect to a Web server using the default account names included with Windows 2000. Make sure that the Administrator and Guest accounts are renamed, but don't choose names that are easy to guess when you rename them.
  • Ensure that the Web server isn't a member of the same forest as the private network. If the Web server is compromised, your Active Directory could become compromised, too. By placing the Web server as a stand-alone server or as a member of a separate forest, you ensure that a compromised Web server won't compromise your organization's internal or private Active Directory.
  • Separate available content into different folders by type. By separating the Web site by content type, you can apply security specific to each content type. For example, you can create the folder structure shown in Figure 14.10 to separate content into the categories of executables, scripts, include files, images, and static Web pages.

    Figure 14.10 Proposed folder structure to secure Web content

  • Secure available content by type. Once you've separated the Web content by type, you can then apply discretionary access control lists specific to the Web content type, as shown in Table 14.7.

    Table 14.7 Securing Web Content by Content Type

    Content Type Recommended DACL Settings
    Executables (.exe, .dll, .cmd, and .pl) Everyone (Execute)

    Administrators (Full Control)

    System (Full Control)

    Scripts (.asp) Everyone (Execute)

    Administrators (Full Control)

    System (Full Control)

    Includes (.inc, .shtm, and .shtml) Everyone (Execute)

    Administrators (Full Control)

    System (Full Control)

    Images (.jpg, .gif) Everyone (Read)

    Administrators (Full Control)

    System (Full Control)

    Static content (.htm, .html) Everyone (Read)

    Administrators (Full Control)

    System (Full Control)

  • Remove all sample applications from the Web server. The sample application files that are included with IIS 5.0 are installed by default and could provide tools to an attacker. Be aware of the sample applications shown in Table 14.8.

    Table 14.8 Sample Files Included with IIS 5.0

    Sample Name Folder Virtual Directory
    IIS Samples C:\Inetpub\Iissamples \IISSamples
    IIS Documentation C:\Winnt\help\Iishelp \IISHelp
    Data Access C:\Program Files\Common Files\System\Msadc \MSADC
  • Disable unnecessary services. If the Web server is dedicated to hosting Web applications, disable all unnecessary services, such as the Telnet or FTP service. If the service isn't being used to connect to the Web server, disable it to protect against attacks.
  • Block commonly attacked ports with IPSec. A block policy drops all connection attempts to the port described by an IPSec filter.

    NOTE


    Alternatively, you can assign a negotiate policy so that computers from the private network that match the IPSec filter based on their connection attempt can still connect to the IIS server. All other connection attempts would fail as if a block policy had been applied.

  • Enable IIS logging. IIS logging will help you determine whether your IIS server has been attacked. By using the World Wide Web Consortium (W3C) Extended logging you choose exactly which properties will be logged for each connection attempt to the IIS server. Consider storing the log results in an Open Database Connector (ODBC)–enabled database to improve the ability to query the log results.

    IMPORTANT


    IIS logging is resource intensive and can affect the performance of your IIS server. If you plan to implement logging, make sure that you enable IIS logging when testing the performance of your IIS server. Also, consider changing the IIS log storage location to move the IIS logs from the Windows 2000 boot partition where the operating system files are stored.

  • Implement Secure Socket Layer (SSL) protocol to protect secure areas of the Web server. Any areas of the Web server that require visitors to enter confidential information such as addresses, credit cards, or password information should be protected by using application-layer SSL protection. SSL encrypts all data transferred between the customer on the public network and the Web server.
  • Deploy an intrusion detection system. Intrusion detection systems look for tell-tale signs of a hacking attempt aimed at your Web server. The intrusion detection system should inform you when the attack occurred, what kind of attack was attempted, and whether the attack was successful.
  • Disable the use of parent paths. Parent paths allow you to use ".." in function calls to view a parent folder. This could lead to an attacker gaining access to a folder on the IIS server that wouldn't normally be accessible. You disable parent paths in the properties of the Web site in the Internet Services Manager MMC console.
  • Apply the IIS 5.0 security checklist. Microsoft has developed a security checklist for IIS 5.0 servers. You can obtain it by going to http://www.microsoft.com and searching for "Secure Internet Information Services 5 Checklist." The IIS 5.0 security checklist includes a high-security Web server security template (Hisecweb.inf) that you can apply to secure the Web server.
  • Mitigate against successful attacks. By configuring the Web server to participate in an NLBS cluster, you can host the Web site on multiple servers simultaneously. When a public network user connects to the shared address of the NLBS cluster, the connection is directed to one of the nodes in the cluster. If a server in the NLBS cluster is rendered inaccessible by an attack, the NLBS cluster recognizes that the node is down and directs future traffic to the remaining servers in the cluster.

    NOTE


    NLBS allows weighting of nodes. This means that you can direct a higher percentage of the incoming traffic to the server with the most resources. For example, if your NLBS cluster is comprised of a Pentium 166 MHz server and a Pentium 933 MHz, you'd want a higher percentage of the connections to be established with the higher performance Web server.

  • Maintain the latest service packs and hot fixes for the Web server. Ensure that regular updates to the operating system are applied so that security fixes included in the updates are applied to the Web server.

Making the Decision

Table 14.9 outlines the design decisions you need to make when securing an IIS server that's exposed to the Internet.

Table 14.9 Securing a Web Server

To Do the Following
Track all access to the Web server Implement auditing at the Web server and ensure that the logs are stored in a format that facilitates inspection of the log files.
Provide the strongest security to Web-accessible data Separate the data by content type and apply the most restrictive permissions that still allow functionality.
Prevent an attacker from accessing unauthorized areas of the disk subsystem Disable the use of parent paths in the Web site's property pages.
Prevent port scans against common attacked ports Apply an IPSec block policy to commonly attacked ports that shouldn't be available on the Web server. This prevents a port scanner from detecting the status of the port.

Remove all unnecessary services from the Web server to eliminate ports from inspection.

Detect hacking attempts Deploy intrusion detection software to detect hacking attempts. Be aware that some normal traffic patterns may appear as hacking attempts.
Prevent a successful attack against the Web server from compromising other data stored on the network Don't make the Web server a member of the private network forest.

Don't store confidential documents on the disk subsystem of the Web server.

Ensure that the latest security fixes are applied to the Web server Ensure that the latest service packs and hot fixes are applied to the Web server.

Periodically connect to the Windows Update Web site (windowsupdate.microsoft.com/).

Limit the effect of a successful hacking attempt Configure the Web server to participate in an NLBS cluster. If one node is brought down, all incoming traffic will be redirected to the remaining servers in the cluster.
Apply the recommended security configuration for your Web server Use the IIS 5.0 security checklist tool.

Applying the Decision

Configure the Web server for Market Florist as an NLBS cluster. Because all of the component servers in the cluster use an identical hardware configuration, you can configure the NLBS cluster to load balance equally between the four nodes.

To ensure consistency to public network users, you must apply any additional security configurations uniformly against all four servers. Apply the following configurations to the four Web servers:

  • Enable auditing on each of the four Web servers. To allow searching on the audited information, the four Web servers could store their data on the SQL server located on the private network. Storing the auditing information on the SQL server will facilitate searching for specific information in the log files and allow for the consolidation of the log material into a single source location.
  • Separate the content from the rest of the Web site. You should break out the Web servers' folder structure to separate the Flower Power application from the rest of the Web site. The Flower Power application requires custom security to allow customers to download the Flower Power client-side application.
  • Implement SSL on the Web server. This will protect the customer registration portion of the Web site. Likewise, program the Flower Power ActiveX control to use SSL to encrypt customer orders and prevent interception of customer numbers.
  • Apply IPSec to restrict public network access to the Web server. Connections should only be allowed to the ports that are accessible by public network users. Block all other ports with IPSec by using a Negotiate IPSec policy. Negotiate allows connections from the private network while blocking connections from the external network. This would require the IPSec filters in Table 14.10 to be applied to the MFWeb1 server. Each server requires separate IPSec filters based on the cluster member's local IP address.

    Table 14.10 Recommended IPSec Filters for the Market Florist Web Server

    Protocol Source IP Source Port Target IP Target Port Transport Protocol Action
    HTTP Any Any 192.168.7.3 80 TCP Permit
    HTTPS Any Any 192.168.7.3 443 TCP Permit
    Flower Power Any Any 192.168.7.3 6834 UDP Permit
    Terminal Services Any Any 192.168.7.3 3389 TCP Permit
    Any Any Any Any Any Any Negotiate
  • Apply the IIS 5.0 Security Checklist recommendations to the IIS servers. The IIS 5.0 checklist enables recommended registry and file permission settings to ensure the secure configuration of the Web server.

Securing Other Services Within the DMZ

Within a DMZ you can expect to find several common resources. These include external FTP servers, Telnet servers, and DNS servers. Each service requires specific configuration to allow you to restrict access to these services.

  • FTP services. The FTP service isn't loaded by default in a Windows 2000 installation. If you install the FTP service, be aware that the C:\Inetpub\Ftproot folder allows the Everyone group Full Control by default. This default setting could allow an attacker to upload data and fill up the drive partition of the FTP server if Write access is configured in the FTP service property pages in the Internet Services Manager console. Consider changing the permissions and enabling disk quotas to limit the amount of data that can be written to the FTP root.
  • Telnet servers. Telnet provides text-based access to a server's disk subsystem. If it's enabled, all users could access the Telnet service by default. You can restrict access to Telnet servers by creating a group named TelnetClients in either the local Security Account Management (SAM) database of the Telnet server or, if the Telnet server is a member of a domain, within Active Directory. When the TelnetClients group exists, only members of the group will be able to access the server.

    NOTE


    In addition, to ensure that authentication credentials aren't transmitted in plaintext, you should configure the Telnet service to accept only NTLM authentication. Additionally, if confidential data is accessed in the Telnet session, you can use IPSec to encrypt the data transmitted between the Telnet client and the Telnet server.

  • DNS services. Only externally accessible DNS resource records should be stored on a DNS server located in the DMZ. The external DNS server should expose only the externally registered IP addresses to public DNS clients. This practice will ensure that DNS doesn't reveal your private network addressing scheme. To prevent an attacker from obtaining all zone information from the DNS server, consider restricting zone transfers to preconfigured DNS servers.
  • Terminal Services. Restrict Terminal Services to administrators of the network by configuring Terminal Services to operate in Remote Administration mode. Remote Administration mode allows only members of the Administrators local group to connect using Terminal Services.
  • All services. All services listen for client connections on a well-known port. Use IPSec to limit access to these well-known ports by creating IPSec block policies that will block access to other ports found on the server. For example, if you wanted to only allow HTTP, HTTPS, and Telnet connections to a Web server at IP address 10.10.10.10 in the DMZ, you could set the IPSec filters shown in Table 14.11.

Table 14.11 An IPSec Filter that Allows Only Connections for HTTP, HTTPS, and Telnet

Protocol Source IP Source Port Target IP Target Port Transport Protocol IPSec Action
HTTP Any Any 10.10.10.10 80 TCP Permit
HTTPS Any Any 10.10.10.10 443 TCP Permit
Telnet Any Any 10.10.10.10 23 TCP Permit
Any Any Any Any Any Any Block

The first two packet filters in Table 14.11 allow any IP clients connecting to the HTTP and HTTPS services on the Web server at IP address 10.10.10.10. The third packet filter allows Telnet connections to the Web server. The final packet filter blocks any other protocols from connecting to the Web server.

IMPORTANT


If you want private network computers to connect to other ports on the server, change the IPSec action to negotiate and define the encryption protocols that must be used for the connection. Only members on the private network should be able to negotiate a security association (SA) with the Web server.

In addition to securing the individual servers within the DMZ, you can also use IPSec to configure the security of transmitted data between the servers located in the DMZ. IPSec protects against an attacker's computer intercepting data transmissions between the servers located in the DMZ. You can configure an IPSec SA between two servers in the DMZ to apply Encapsulating Security Payloads (ESP) to all data transmitted between the two servers. For example, you can secure a Web front-end application and an SQL server so that IPSec encrypts data transmitted between the two servers by negotiating a SA between the two servers. This association is shown in Figure 14.11.

click to view at full size.

Figure 14.11 How IPSec SAs protect transmitted data between computers in the DMZ

Making the Decision

Table 14.12 outlines the security configuration options that should be included to protect Internet-accessible resources.

Table 14.12 Protecting Internet-Accessible Resources

To Protect Include the Following in Your Design
FTP services Change NTFS permissions to match the allowed transactions. For example, if only FTP downloads are allowed, configure permissions to allow only the anonymous FTP account Read permissions.

To prevent password interception, allow only anonymous connections.

Telnet services Create a local security group named TelnetClients to restrict Telnet access to authorized users.
DNS services If using the same namespace internally and externally, ensure that the external DNS server doesn't contain private network IP addressing.

Restrict zone transfers at the external DNS server to only approved DNS servers to prevent an attacker from retrieving the entire zone data file.

All services If allowing only specific protocol connections, block all other protocols with an IPSec block action. This will prevent any other ports from responding to port scans or access attempts.

If you require private network access to the restricted ports on a server in the DMZ, change the IPSec action to negotiate so that private network client computers can establish an IPSec SA with the server in the DMZ.

Interaction between servers Configure servers in the DMZ to use IPSec transport mode for data transmitted between the servers. IPSec transport mode encrypts all data exchanged between the servers and prevents unauthorized connections to the server. IPSec transport mode can pass through a firewall as long as NAT isn't performed against the data.

Applying the Decision

Market Florist can implement additional security configuration within the DMZ to ensure the security of the services located in the DMZ. Include the following in the Market Florist security design:

  • FTP service. Market Florist customers use the FTP service to download product brochures. Modify the permissions for the Ftproot folder to assign only Read permissions to the anonymous FTP account. Permissions should allow John Coake and Pat Coleman to modify the contents of the Ftproot folder.
  • DNS service. Configure the external DNS server to only allow zone transfers to configured secondary DNS servers. This configuration prevents attackers from dumping the zone database from the DNS server. In addition, the external DNS server should only refer to the public network addresses of the available services. There should be no references to the private network addresses used in the DMZ.
  • Telnet service. Configure the MFFTP server with a local security group named TelnetClients. Make John Coake and Pat Coleman members of the group to restrict Telnet access to only John and Pat and exclude access to all other users.
  • Terminal Services. To restrict Terminal Services to only network administrators, install Terminal Services using Remote Administration mode on each server in the DMZ. Install Terminal Services on each component server of the MFWEB NLBS cluster to allow administrators to connect to the individual component servers.
  • Interaction between servers. Establish an IPSec SA between the MFWEB NLBS cluster servers and the MFSQL server on the private network to encrypt all data exchanged between the servers. The IPSec agreement can take place because NAT isn't performed between the DMZ and the private network.

Lesson Summary

Don't depend exclusively on firewalls to protect resources exposed to the Internet. When designing your security, imagine each server being exposed on the Internet without the protection of a firewall. Ensure that each server in the DMZ is properly configured so that security will be maintained even if a firewall is compromised.



Microsoft Corporation - MCSE Training Kit (Exam 70-220. Designing Microsoft Windows 2000 Network Security)
MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)
ISBN: 0735611343
EAN: 2147483647
Year: 2001
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net