Proxy Server Security

In the February issue, I showed you how to install Microsoft Proxy Server 2.0 correctly, including how to choose the appropriate hardware and select the appropriate options with security in mind. Addressing security concerns at installation makes for more secure Web and proxy servers (remember that you have to consider both) and leads to fewer problems, such as preventable intrusions and defacement of Microsoft Internet Information Server (IIS) Web sites. Administrators of existing proxy servers have an even greater concern: They have to address the security issues I raise in this article individually on each IIS and proxy server before they apply any fixes to ensure that they're not breaking existing functionality. (It's easier to address security when you first install the server than it is to apply security retroactively to an existing production server.) This month, I discuss the security topics that all proxy server administrators need to consider—in particular, why you need to disable the Server service binding on the external interface and how to minimize risk on the external interface. The sidebar "Additional Proxy Server Security Resources," page 2, provides a list of helpful materials and Web sites.

Many security and penetration analyses attempt to identify risks to the enterprise with the intent of minimizing or eliminating them. Proxy Server can either help you achieve that goal or swiftly help you contribute to its demise. One key to successful installation is knowing in advance what risks Proxy Server brings to your network. Most major problems are identifiable from your keyboard and require only a few minutes each week for keeping up with the latest trends.

Evaluate Your Exposure
Default installations of network-related software tend to leave gaping holes in security. Applications, OSs and even major firewall-software makers can leave default software settings that can later result in potential security breaches. As an administrator, you must make the system as secure as possible. Therefore, you must read the product manual before installation and use other auxiliary resources, such as this newsletter and the Internet, to look for tips from other administrators before going production with your server. You also have to evaluate the security risk your new software or hardware introduces to the network, and Proxy Server is no exception.

As part of your due diligence, consider using a popular security evaluation method—the port scan. (A port is an interface through which a computer and a network or peripheral device—e.g., a printer or keyboard—transfer data.) Port scans look for assets (servers that respond to the incoming connection thinking it's a potential client) and services (such as FTP and Telnet) visible on a NIC from the untrusted network (e.g., the Internet). Port-scanner software typically runs on a machine other than the scanning target. The software is widely available on the Internet and therefore is readily available to those with good intentions and bad. For the best results, I recommend scanning from the same physical segment as your external interface to eliminate any missed responses because of slow WAN connections. Also, scan from a typical point on the untrusted network. If the untrusted network happens to be the Internet, make sure you scan from more than one ISP.

The goal of using a port scanner is to look for exposed ports and services on interfaces exposed to the external, untrusted network. Some products even inform you about the risk of having a particular port open on your proxy server. After a typical IIS 4.0 and Proxy Server installation, you can expect to find one or more of the ports in Table 1 identified as being open on the external interface (depending on the selected options). Your individual port scan might even show ports I haven't listed here. The TCP/IP stack and Proxy Server can open ports above 1024 (also called the registered ports) dynamically to satisfy individual proxy requests. Sometimes, extra services or software that you install on the proxy server can open additional ports. The Internet Assigned Numbers Authority (IANA) is the entity responsible for the registration of registered ports, among many other tasks. You can get a definitive listing of assigned ports (commonly called well-known ports) and services at http://www.isi.edu/innotes/iana/assignments/port-numbers. If you're not already familiar with the IANA site, plan to spend some time on it. The site contains a wealth of information and is a must for any IT professional concerned with security and related topics.

Minimize Your Exposure
When you've evaluated the extent of the security risks to your system, you must take steps to minimize those risks. One of the easiest ways to minimize security risks to your server is to close ports and remove unnecessary services on the external interface.

Port 21. You can close down port 21 by stopping the FTP Service in the Microsoft Management Console (MMC).

Port 80. Port 80 is tougher to lock down because both IIS and Proxy Server might be using it. The easiest way to prevent Proxy Server from using this port is simply not to enable Web Publishing. However, Reverse Hosting and Reverse Proxy sites depend on using Web Publishing. To find out whether you've enabled Reverse Proxy or Reverse Hosting,

Port 135. Unfortunately, you can't lock down port 135. If your proxy server is in an IP-routed environment, investigate dropping or blocking traffic at the router for this or any of the other ports I've mentioned.

Ports 137­139. You can use Control Panel to disable ports 137 through 139. Use Ipconfig to determine the description, or long name, of your external adapter. Note the description of the external adapter. Open the Control Panel Network applet, and click the Bindings tab, which Screen 2 shows. Select all adapters from the Show Bindings for drop-down list. Identify the name of the external adapter, and make sure that you disable all protocols, including WINS Client(TCP/IP), leaving only the TCP/IP Protocol binding. Disabling these protocols prohibits external users from using Server Message Block (SMB)—the Windows NT 4.0 networking protocol of choice—to connect to the external adapter on your server.

Ports 1024­1029. You can use the Registry to disable ports 1024 through 1029, but this approach takes more work. Using the Ipconfig command, look for the heading of each adapter entry beginning with

Ethernet Adapter  :

where is the abbreviated driver name the card manufacturer assigns and refers to the number of the adapter installed in your system, which Table 2 shows. This card is a Netelligent 10/100 TX PCI unshielded twisted pair (UTP) card, which you might find in a Compaq server and which NT knows as device name N1001. Look for your internal adapter by its IP address, and record its device name. Start regedt32, and go to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices Registry key.

Verify that a key exists that matches the device name (e.g., N1001). If no key exists, go back to Ipconfig and reverify your card's device name. When you've verified the internal card's device name, create the following keys beneath the Services key, where you found the card name (not beneath the card's name).

Highlight the Services key. Now, create an Rpc key (leave the Class field blank), then create a new Linkage key beneath Rpc, again leaving the Class field blank. Beneath the Linkage key, create a Bind key. When you create the Bind key, enter REG_SZ into the Class field. Your new key will be HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRpcLinkageBind.

Now, add a new value to the Bind key with the device name of the internal card, as Screen 3, page 4, shows. Don't worry about assigning a string value: It's not necessary. This value lets only the device names mentioned as values in this key bind to the remote procedure call (RPC) listener ports. By leaving the external device name off this list, you effectively close those ports to the external network. As always, use extreme caution when you edit the Registry.

These changes are meant for standalone proxy servers. Changing these Registry settings on a Microsoft Small Business Server (SBS), Microsoft BackOffice server, RAS/VPN server, or an application server might have adverse effects. If you're running one of these servers and are experiencing performance or security problems, consider breaking out the proxy server installation to a separate server or moving some of the other products to help isolate the proxy server installation. The gains in performance and security might well be worth it.

Dynamic Packet Filtering
Another way in which Proxy Server improves security is in its ability to selectively accept and reject packets based on the packets' characteristics—dynamic packet filtering. To understand the beauty of dynamic packet filtering, you need to understand the alternative. In static packet filtering, the firewall administrator explicitly names the ports traffic can pass through. For example, the firewall administrator might state that only outgoing Web, FTP, mail, and DNS requests can pass. Static packet filtering is doomed to fail here because of the nature of some of these services to dynamically assign ports.

As an example, let's take a closer look at FTP. By looking at the well-known-port list (http://www.isi.edu/in-notes/iana/assignments/portnumbers), you can see that you can commonly find FTP services at TCP port 21. However, FTP requires two ports—a control connection and a data connection. For more detailed information about FTP port assignments, see Internet Engineering Task Force (IETF) Request for Comments (RFC) 959. The control connection usually exists at port 21. After the initial connection to port 21, the FTP server and FTP client negotiate the port used for the data connection. If the firewall administrator hasn't opened the newly negotiated port in the firewall beforehand, the FTP session will fail. The firewall administrator has to open every possible negotiable port to make static packet filtering work.

Dynamic packet filtering solves the static dilemma by examining the headers of outgoing packets and dynamically opening and closing ports as needed. As the first outbound packet leaves the firewall, the packet leaves the connection open, understanding that additional return traffic to the internal firewall client might occur. If return traffic destined for the originating internal client arrives at the same outbound port, the firewall is responsible for matching up that traffic and forwarding the packets back to the originating client. If no return traffic occurs within a reasonable time, or the connection unexpectedly closes, the firewall is responsible for immediately closing down that port in order to protect the internal network from intruders.

Implementing dynamic packet filtering on Proxy Server. To implement dynamic packet filtering on Proxy Server, right-click Winsock Proxy Service in the MMC and select Properties. On the Properties sheet, click Security, then click the Packet Filters tab. Select the Enable packet filtering on external interface check box, which Screen 4 shows. (If the option is unavailable, you probably have only one network interface and therefore can't access many security options. Consider redesigning your proxy architecture by using two networks to segregate the internal and external interfaces.) Now you can access the Enable dynamic packet filtering of Microsoft Proxy Server packets check box and the Exceptions window, which lets you list certain exceptions to your filtering policy. Be sure to restart the Web service to force Proxy Server to reexamine the rules.

Dynamic packet filtering in Proxy Server uses a drop-everything rule, which means that unless a satisfying condition grants access, Proxy Server will drop the packet altogether. Proxy Server always enforces this rule unless

Server Proxy uses dynamic packet filtering to force open a port to provide a particular service on the external interface, such as another Web server. (I'll cover Server Proxy in detail in a future issue.) You'll see that some default exceptions for Internet Control Message Protocol (ICMP) traffic and DNS exist. You might want to review this policy to make sure it's in line with your security policy.

Domain Filtering
I've discussed blocking packets, ports, and services, but Proxy Server also lets you further protect the inside from the outside by restricting internal access to external domains that you define. In an ideal situation, your company has a formal acceptable use policy for your network. If not, you might be at risk legally. (If your company doesn't have an acceptable use policy or other common policies, you can see example policies at http://www.sans.org/newlook/resources/policies/policies.htm.)

For example, if I want to restrict my Web Proxy Service users from accessing any Web sites under www.averybaddomain.com, I can use domain filtering to block access to that site. You can use the domain filtering feature to keep your users from visiting sites that might go against the corporate acceptable use policy.

To implement domain filtering in Proxy Server, right-click Web Proxy Service in the MMC, and select Properties. On the Properties sheet, click Security, then click the Domain Filters tab. Select the Enable access control check box. You can block access in two ways:

Choose the appropriate method under By default, access to all internet sites will be, whether it's Grant or Deny. When you've made your selection, you can edit the domain list. You can add one computer, a block of IP addresses, or entire domain names. Add the names as appropriate to complete your restrictions. (If you have to add a long list of domains, see the Microsoft article "How to Add a Large Number of Domain Filters in Proxy Server 2.0" at http://support.microsoft.com/support/
kb/articles/q217/2/00.asp for instructions about using your favorite editor to enter these restrictions.)

Routinely blocking harmful Web sites can be time-consuming. Deciding which domains to block can be even more time-consuming and a political nightmare within your organization. Third-party software can help you with this task and keep the restrictions fresh and timely. See the following vendors' sites for more information about Proxy Server plugins:

In a future issue, I'll examine some of these third-party plugins and the additional functionality they bring to your security policy.

Winsock Proxy Client as an Alternative to Filtering
Many common Proxy Server installations use a combination of dynamic packet filtering and domain filtering. Despite the best efforts of the proxy server administrator, someone always wants an exception to the rules. Sometimes, you get requests from users who have a client application that needs to be able to talk to the Internet through a registered port.

One way to solve this problem is to use Winsock Proxy and grant unlimited access to those who need it. For example, if the big boss wants to use a stock ticker program that needs registered ports to operate, you can install Winsock Proxy Client on his or her workstation and enable the Unlimited Access protocol in the Winsock Proxy Service Properties For proxy dialog box. Screen 5 shows the Permissions tab. This solution gives you the power to follow the company's acceptable use policy, but with some flexibility.

Microsoft Proxy Server and RRAS
Occasionally, administrators install Proxy Server together with RRAS so that both services can exist on one server. Despite the hardware cost savings with running two services on one server, the thought of a router running parallel to my proxy server really bothers me. If you can move the RRAS server to a separate server, I suggest that you do so for security's sake and for added ease of administration.

Moving the RRAS server is a good idea because of NT's ability to become a minirouter. During Proxy Server installation, I disable IP forwarding and set up a manual route to the internal network. The manual route lets me place a barrier between the two networks, and I can feel certain that packets aren't automatically routed from the external interface to the internal interface. The RRAS installation re-enables this option—in fact, RRAS doesn't work without it. Although administrators go to great lengths to make sure the routes don't exist, a simple mistake can decimate the server's security. The packet-filtering abilities of both products can be counterproductive if you don't set them correctly.

Local host filters are key to preventing RRAS and Proxy Server from harming each other and your network. These filters shape the security of RRAS and determine what is allowed between the external and internal interfaces. In the case of the RRAS/Proxy Server combination, you need two local host filters to control the flow. The first filter drops all inbound packets on the external interface except for those destined specifically for the proxy server, such as return traffic for Web Proxy clients and incoming requests for applications available through Server Proxy. The second filter drops all packets on the internal interface except for those destined specifically for the proxy server, such as Web Proxy and Winsock Proxy requests. Even though you've enabled IP Forwarding and your server's nature is to route packets between the networks, RRAS only allows traffic destined for the proxy server. This solution works, but it's not the best security-minded solution.

Next Month
Next month, I'll talk more about using Proxy Server to publish Web sites. I'll discuss Reverse Proxy, Reverse Hosting, and the little-known and oft-misunderstood Server Proxy.