securing an NT-based DNS server

by William D. Kramp
<krampwd@snyflcc.fingerlakes.edu>

Kramp is a network administrator at the Finger Lakes Community College in Canandaigua, NY. He has long experience from Xenix to VMS, FreeBSD, Linux, and NT. He now uses a mixture of NT, FreeBSD, and Linux to manage the college networking.


With the shift from Novell to Windows NT to provide file- and print-sharing to our users, it was decided that NT might be an option for providing DNS services as well. We soon found that many services beyond DNS were accessible to the outside world. By combining trial and error with monitoring the network, we stripped down the NT box to its bare essentials for providing DNS services.

Console or Remote Management

Beyond using the command line to manage the DNS service on each system, there are two ways of securely managing the Microsoft NT DNS servers using the GUI interface. Either run the windows-based GUI manager locally to each server, or allow remote management from an internal, secure network. Local access only allows access from the console of each server. This is okay for one or two servers, but can be difficult with more servers. The other option is to configure an internal network that the DNS servers can communicate on. All the primary zone information can reside on an internal server that propagates the information out to secondary DNS servers. The secondary then provides DNS services to external networks through a second interface.

The first step is to have only the network protocol TCP/IP loaded. Under the Control Panel, select the Network icon. Click on the Protocols tab and remove any protocols that are listed other than TCP/IP. The next step is based on your need either to have only local, GUI-based access from the console for each DNS server, or have distributed control from an internal, secure network.

Local Console Only
To permit only local, GUI-based access to the DNS service running on that individual system, the Microsoft Loopback adapter needs to be installed. The loopback is needed to allow access to ports 135 and 1028, which are used by the Microsoft DNS GUI interface. These two ports will be blocked on the external interface. Click on the Adapter tab and select MS Loopback Adapter from the menu of choices. Select the frame type of 802.3.

Remote Management
If distributed access is required, a second network device will need to be installed in the system that is attached to an internal network. It is preferable that the internal network be isolated from other systems at the site, but it can use a shared network with other servers and clients. If access over the Internet is required for management of the DNS servers, an encrypted tunnel should be used to access the internal network.

Each interface needs to have a unique IP address. At the Microsoft TCP/IP Properties window, click on the Routing tab, and make sure that IP Forwarding is not enabled. Then click on the IP Address tab. For the loopback adapter, or the internal interface, enter a legitimate IP address for your network, or use one of the reserved addresses like 192.168.100.1, from the RFC 1597. It specifies private addresses in the following ranges: 192.168.0.0—192.168.255.255, 172.16.0.0—172.31.255.255, and 10.0.0.0—10.255.255.255.

Filtering Ports

The next step is to filter the IP access to the ports on the DNS server network interfaces. While still viewing the TCP/IP properties, click on the Advanced button. Click on the Enable Security check box, then click on the Configure button. Within the TCP/IP Security window, select the adapter that is used for the external interface. By default, all

TCP and UDP ports are enabled, as well as all IP Protocols. For TCP and UDP, click on the Permit Only button for each and add port 53. This will allow remote access to the DNS server but will block access to any other services using other ports. Now select the internal or loopback interface and click on the Permit Only button for each. For the TCP connections, add ports 53, 135, and 1028. Port 53 will need to be added for UDP. TCP ports 135 and 1028 will allow the Microsoft GUI-based DNS manager access to the DNS service. Allowing open access to all ports on the internal interfaces would work, but it is safer to keep things as locked down as possible.

Shutting Down NT Services

To limit the vulnerabilities of the DNS server and increase performance, services that are not needed for the operation of the DNS server should be stopped and disabled. Find the Services icon under the Control Panel and select it. Make sure the following services are stopped and disabled: Alerter, Clipbook Server, Computer Browser, DHCP Client, Directory Replicator, Messenger, Net Logon, Network DDE, Network DDE DSDM, RPC Locator, Schedule, Spooler, TCP/IP NetBIOS Helper, and Telephony Service. The License Logging Service is also not needed for the operation of the DNS server, but I am not sure about the legalities of turning it off. It is recommended that each service be set to disabled, not just to manual. If a service is set to manual, another service could start the service up without your knowledge. Some of the services left running should be: Eventlog, DNS Server, NT LM Security Support Provider, Plug and Play, Protected Storage, Remote Procedure Call (RPC) Service, Server, and Workstation. There may be other services running as well, depending on the hardware configuration. These will need to be evaluated as to their risk and in consideration of your site's individual requirements.

Known Problems

Some problems I have seen involve the Enable Security box within the Advanced IP Addressing window not staying enabled. This has the effect of turning off any port filtering. One quick fix that sometimes works is to change the IP addresses of the interfaces, reboot, and then change them back to the original IP addresses. If that doesn't work, reloading the service patch should fix it.

Zone Transfers

The primary DNS servers should be configured to allow zone transfers only to approved secondary DNS servers. This has the side benefit of automatically updating the secondary when a change is made. The secondary will not have to wait till the refresh time expires before updating its zones. Details of restricting zone transfers and supporting DNS under NT can be found in the O'Reilly book DNS on Windows NT by Paul Albitz, Matt Larson, and Cricket Liu.

Extra Security

An extra layer of protection for the DNS servers would be to use a firewall or filtering router to restrict accesses to port 53 of the servers. All appropriate service patches and relevant hot fixes should be installed as well. The Windows NT operating system should be further secured to prevent security breaches. A good source of information is available from the SANS Institute's document "Windows NT Security Step by Step" at <http://www.sans.org>, and from Microsoft's TechNet.