Maximizing Proxy Server Security
Learn how to plug the security holes in your Proxy Server-secure network using special tricks and techniques.
September 14, 1999
Can you improve your network's security?
For many organizations, Microsoft Proxy Server acts as the network's front line for security. Proxy Server's ability to hide a company's internal IP address space combined with the ability to prevent IP routing between the internal network and the Internet gives companies a good security baseline. Proxy Server also attracts many customers by promising plug-and-play security and by leveraging a company's existing Windows NT and Microsoft BackOffice infrastructure and user account database.
Even with Proxy Server in place, however, clever intruders can find ways into your network. Unfortunately, many companies rely solely on Proxy Server's default configuration to provide all their security. This reliance often leaves them vulnerable to attack.
To maximize network security, you need to consider implementing some advanced security measures, including Proxy Server's advanced security features and special network configurations to enhance its security potential. In this article, I show you techniques to tighten your network's security beyond the basic default configuration.
Most of these techniques require only minor changes to existing networks and servers and are steps that you can take right now to protect your company against Internet-based attacks. In addition, these techniques can help you get the most from your Proxy Server investment.
Basic Security Steps
In many customer applications, Proxy Server sits at the Internet-exposed network's edge and provides secure Internet access via application- and circuit-level gateways. These gateways sit between internal computers and Internet servers. The application-level gateway includes three proxy services (i.e., Winsock, Web, and SOCKS) that accommodate different client-access methods and Internet services.
The three services use Network Address Translation (NAT) to translate private internal IP addresses to one routable IP address assigned to an Internet-connected network adapter. Because Proxy Server directly connects to the Internet, Internet-based intruders see an opportunity to probe, hack, and attack.
One NIC proxy server is hard to secure and prone to causing problems with certain applications and services, so I'll assume that you're running Proxy Server in the recommended configuration using at least two network cards: one connected to the internal (private) network, and another connected to an Internet-exposed network or router. Before I jump into an advanced discussion, consider some basics central to any Proxy Server implementation. Microsoft also covers many of these basic concepts in Proxy Server's installation documentation.
Consider This
The first security consideration relates to the NT Server service, which provides Server Message Block (SMB) access to file and print shares and the Registry on NT systems. You need to disable this service because exposing it directly to Internet-based computers presents a major security risk.
Luckily, you can easily disable this service on only the external NIC while leaving the service enabled on the internal NIC so that the server remains accessible to internal network clients. To disable the NT Server service on the TCP/IP binding to the Internet-exposed NIC, go to the Network applet in Control Panel and select the Bindings tab. Display all services in the Show Bindings for list box, and double-click Server, WINS Client(TCP/IP). Highlight your Internet-connected adapter, and click Disable. Screen 1 shows how the Internet-connected adapter looks after you click Disable. Click OK, and restart your system. After the system restarts, the NT Server service isn't available over TCP/IP with this network adapter.
If you think that this change will limit trusted Internet-based users' access to Proxy Server's Server service, you can investigate a VPN-based solution, such as PPTP-based RAS connections. You need to avoid directly exposing the Server service to the Internet. (See Eric Pearce, "Managing VPNs with PPTP," January 1999, and Douglas Toombs, "DNS and PPTP for Network Security," August 1997, for more information about VPNs and PPTP.)
In addition, an alternative method of securing access to the resources provided via the NT Server service (and other NT network services) is to disable or control access to the specific ports that clients use to connect to these services, specifically UDP ports 135, 137, and 138, and TCP port 139. In most cases, you implement this control at your Internet-connected router or firewall product. Limiting access to these ports can provide an equivalent degree of security, but I recommend disabling the Server service binding on all Internet-exposed NICs. Using both methods creates an even better solution and provides a fallback in the event that someone upgrades or replaces a router and forgets to include these filters, or someone accidentally reenables the Server service binding.
Disabled Default Configuration
You need to verify the default configuration for IP forwarding (routing). Disabled IP forwarding is the default Proxy Server configuration except with RAS, in which case the application leaves IP forwarding enabled. (Proxy Server disables IP forwarding during installation, but administrators can always enable the option after installation.) Disabling IP forwarding prevents NT from forwarding packets between any two interfaces on the system—an essential condition for a fully secure Proxy Server.
However, IP forwarding is necessary in at least one situation: When Proxy Server acts as a RAS server. IP forwarding is necessary in this case because it permits RAS clients to communicate with the internal network. For this reason, I recommend leaving RAS off a Proxy Server whenever possible. When the Proxy Server acts as a PPTP-based RAS server, you can use a special configuration to maintain security. This configuration involves the PPTP-filtering feature and a special PPTP-specific Registry modification. (See Watch Your RAS, "Securing a RAS Proxy Server," August 1999, for details.)
Unless absolutely necessary, don't install Proxy Server on a domain controller on your internal network. Domain controllers house NT's SAM database, so installing the application on your network can expose you to more risk. Intruders can run dictionary and brute-force attacks against the database to gain additional user and password information. When you must run a Proxy Server on a domain controller, use Service Pack 4 (SP4) or later, and consider using the Syskey (SAM encryption) utility included in SP3 and later. (See Mark Joseph Edwards, "Service Pack 3 Is Really Security Pack 3," August 1997, for details.)
Filtering Finesse
Last on the basic Proxy Server configuration checklist is one of Proxy Server's strongest and most overlooked security features—filtering. Filtering lets you specify, on a service-by-service basis, exactly what types of traffic you permit to access your network through Proxy Server's external NIC. Proxy Server's filtering feature uses a security policy that denies all traffic except that which is highly secure. In addition, you can easily add commonly required services (e.g., DNS, HTTP, FTP, PPTP) through predefined filters.
At this point, stop and ask yourself whether using Proxy Server with these features is sufficient security for your network. Your answer depends on your specific security needs. A network secured with Proxy Server in a standard configuration is far more secure than one without a firewall, but no security solution is perfect or impenetrable.
The goal in securing any network is to provide the maximum number of barriers to intruders while giving internal network users the minimum-required level of functionality. The special network configuration scenarios enhance Proxy Server's usefulness and remain fairly unobtrusive to legitimate network users.
Proxying in the DMZ
Proxy Server's flexibility of integration into your network architecture is one of the product's best features. Although Proxy Server must always have a real, routable IP address on one adapter, you can use several methods to position the application within the externally exposed network. Sometimes referred to as a demilitarized zone (DMZ), this externally exposed network is an intermediate layer between two other networks that don't trust each other. You can place Proxy Server at the back of the DMZ where the application runs alongside other public servers, such as those providing Web, FTP, DNS, and other services. This configuration option, which Figure 1 shows, is probably the most common.
However, you can also configure an Internet-accessible DMZ that benefits from additional security via the Proxy Server. Figure 2 shows how the Proxy Server sits at the front of the external network and connects to three separate networks: the Internet router's LAN segment; the DMZ, which contains other Internet-accessible servers; and the internal LAN. Use three separate NIC cards in the server (one for each network connection) to produce this configuration. Or, you can assign the DMZ IP address as an additional IP address on the NIC connected to the internal network and ensure that connections exist between the DMZ hosts and the same physical LAN segment. (For details, see Reader to Reader, "DMZ with Proxy Server 2.0," June 1999, and the Microsoft article "How to Create a DMZ Network with Proxy Server 2.0" at http://support.microsoft.com/ support/kb/articles/q191/1/46.asp.)
Both of these configurations use Proxy Server's filtering feature to offer additional security to the DMZ. And both configurations require you to enable IP forwarding on the NT server. Enabling IP forwarding sounds like you're reducing security, but in these two scenarios, you aren't. The application enables the packet-filtering feature that creates specific servers (IP addresses) and services in the DMZ. Because these scenarios don't let other traffic into the network, the internal LAN remains safe. In addition, the DMZ-based systems benefit from Proxy Server's packet-filtering security and are less susceptible to malicious behavior originating from the Internet.
However, Proxy Server represents a single point of failure for all Internet-connected servers, not only the internal LAN clients behind the Proxy Server firewall. You can accomplish similar results to this Proxy Server/DMZ scenario by using many brands of routers or dedicated firewall products, such as Sonic Systems' SonicWALL DMZ. As a hardware-based alternative, this product provides multiple Ethernet interfaces (i.e., one each for the router, DMZ, and internal networks) and the ability to define rules about how traffic flows between each interface.
Proxying in Another Domain
The majority of Proxy Server configurations that I see as a consultant implement Proxy Server as a member of the same NT domain as the internal network. The previously discussed security features make this implementation appear fairly safe. However, this configuration contains risk. A machine running Proxy Server is a legitimate, trusted computer in the internal network, and thus becomes a potential launching point for a variety of attacks and probes.
If Proxy Server contains sensitive security information about the internal domain, it becomes an even more dangerous liability. Making Proxy Server a domain controller in the internal-company domain can leave the SAM database vulnerable to an intruder's attempt at gaining access to usernames and passwords. By making the Proxy Server a member server, you remove direct access to the SAM database.
However, even a member server running Proxy Server can be a potential security threat. A member Proxy Server is still in the same domain as the rest of the company's network, so the computer can contain data in the Registry or user files that provides an intruder with the information required to access additional network resources. And from Proxy Server, intruders can launch rogue services or commands that run in the system-security context, a trusted account within the domain.
Because most attackers work their way through a network by using a stepping-stone method (i.e., intruders use one compromised service or machine to provide access to another), you need to always keep a Proxy Server far away from internal resources. The best way to create an additional security buffer zone is to place the Proxy Server in a separate domain.
Setup Made Easy
Fortunately, setting up Proxy Server in this scenario doesn't mean a lot of extra administrative overhead and headaches. You simply make the Proxy Server (and other potential NT systems in the DMZ) the PDC of a secondary domain. This secondary domain won't contain any user accounts beyond those required to make Proxy Server work. And the secondary domain trusts users from the primary domain (via a trust relationship), so the secondary domain can provide services to the primary domain.
Although Proxy Server's domain trusts the internal network, the internal network doesn't trust the Proxy Server's domain. The advantage of this solution is that internal users gain access to the Proxy Server and Internet, but a compromised Proxy Server represents little or no threat to the internal domain. Figure 3 shows a diagram of a two-domain Proxy Server network configuration.
To set up Proxy Server in a secondary domain, follow these steps:
Reinstall Proxy Server as the PDC of a new domain. For simplicity's sake, refer to the internal domain as DOMAIN1 and the Proxy Server domain as DOMAIN2.
In User Manager, add DOMAIN2 as a Trusting Domain on a domain controller in DOMAIN1 (i.e., the primary domain). When you complete this step, you'll need to supply a password to use later to establish the trust, as Screen 2, page 96, shows. You must complete this step to permit the trusting domain to trust the new domain.
In User Manager, add DOMAIN1 as a trusted domain in DOMAIN2 on a domain controller. The system will ask you for the password you provided in step 2. When you successfully establish the trust, you'll receive the message that Screen 3, page 96, shows.
Use accounts and global groups from DOMAIN1 inside local groups in DOMAIN2. By placing these groups inside a local group that has permissions on Proxy Server resources (e.g., a local group in DOMAIN2 called Internet Users, which contains users or global groups from DOMAIN1 called Domain Users), you can provide DOMAIN1 users with access to the Proxy Server in DOMAIN2.
Assign permissions to the DOMAIN2 local group(s) containing DOMAIN1 users and groups that have Proxy Server permissions. You complete this step by configuring the Permissions tab of the Properties dialog box of either Winsock or Web proxy services and assigning access to the appropriate groups or users, as Screen 4 shows.
Test access through the Proxy Server by configuring a workstation in DOMAIN1 for access through the Proxy Server and attempt to access an Internet resource. You'll know that you've missed a step if you see the dialog box that Screen 5 shows.
To make this scenario even more secure, have another server act as the PDC of the Proxy Server domain and configure the Proxy Server as a member server that communicates with the PDC via a protocol other than IP. Only organizations with the tightest security requirements need to consider this option because of the additional administrative complexity and costs associated with an additional server.
Proxy Server 2.0 is an excellent foundation for securing your corporate network. (For details, see Zubair Ahmad, "Proxy Server 2.0," October 1998.) Although its default configuration is a good starting place for implementing network security, you can use the techniques discussed in this article to tighten your network's security even further. Best of all, you can easily implement these techniques because they require only minor changes to your existing network.
About the Author
You May Also Like