In this new monthly column, I will bring you a healthy dose of tips and tricks on securing your network’s perimeter. I’ll cover nearly every aspect of network security, so hold onto your hats!
With the inevitable passage of time, the network operating system (NOS) continues to evolve. Feature sets expand, and directory services, Web services, and other services are added. Over time, the complexion changes from a basic NOS model to an NOS that includes a lot of additional integrated services.

Changing the paradigm
As the NOS changes, the network security paradigm often must change with it. New protocols may come into play, and the manner in which they are used on the network may change from server-to-Internet, server-to-server, and server-to-workstation. As these protocols are added and as the NOS becomes more complex, the new and more advanced services they provide may require us to rethink how we look at network security. For example, in Windows 2000, should you continue to apply the old rules that governed your security in Windows NT 4.0? What about the new services that Windows 2000 provides? And what about the old protocols and services for backward compatibility with NT 4.0 that have been included in Windows 2000? How about servers on the edge of the network? Don’t they deserve a closer look? Most important, what about Windows 2000 servers functioning as firewalls?

With Windows NT 4.0, we were always concerned with security issues. It seemed that we regularly heard CERT alerts and horror stories about NT 4.0 systems being compromised in one fashion or another. Now, with Windows 2000, you have access to a host of new services, including Active Directory Services (ADS), which is a distributed directory service that’s spread across domains and domain controllers. What can you do to ensure that only domain controllers are talking to domain controllers, instead of spoofs? What about firewall servers that are directly connected to the Internet? The good news is that Microsoft is finally beginning to address many of these issues. It has included new security components such as IPSec, firewall-type services, and Kerberos. But are these additional measures enough? In an effort to answer these questions, let’s look at security from a network perspective.

Regardless of any NOS flaw or vulnerability, the underlying network protocols are generally used to take advantage of the NOS. You’ll want to take a close look at the protocols and services traversing your network.

NetBIOS
One of the most common problems you’ve probably dealt with is the NetBIOS, which is used to provide such services as name services and file sharing. Although this method may be necessary to incorporate on your internal network, it is rarely required for external communication beyond your network. If you’re dealing with a firewall server inside your Internet router, you can always block certain services at the router using a filter or access list. However, for an extra measure of protection, it’s a good idea to also limit the specific services at the server. File sharing via NetBIOS on Windows NT used ports 135-139, and in Windows 2000, it now makes use of port 445 (TCP and UDP).

Generally speaking, there should be no need for NetBIOS name resolution or file sharing across a firewall to the Internet. However, if you intend to use the new VPN services in Windows 2000 to implement a site-to-site VPN between offices, you may need servers or workstations in one office to communicate with a remote office across the VPN. This shouldn’t be a problem because you’ll probably encrypt and tunnel the traffic within IPSec.

Server names
Configuration and naming become very important at the edge of your network. Don’t name the server in such a way that makes it obvious to a would-be intruder which NOS or firewall you’ve installed. I’ve seen instances where server names at the edge of the network were so descriptive that they included the name of the firewall product and the server’s function within the internal domain. You’ll want your firewall server to be a standalone system rather than a member of your Windows 2000 domain structure. This will help minimize exposure to ADS if the perimeter is circumvented. Also, don’t install NetBIOS services on these systems. Be careful about which routes you set up on your firewall, as a careless entry may expose your internal addressing scheme.

NTLM weaknesses
Let’s not forget about the historical NTLM weaknesses. NTLM was originally included with Windows NT 4.0 for backward compatibility with LAN Manager. It’s now included with Windows 2000 for compatibility with NT 4.0 systems. Some time ago, the LAN Manager authentication method was discovered to be relatively easy to compromise. Microsoft released an update with NT Service Pack 4 to overcome this problem, but even though Microsoft claims the fix makes LAN Manager much more robust, there is no need to tempt fate. It may be appropriate to run NTLM on internal Windows 2000 servers for authentication of older Windows systems on your network. However, this is a service you should consider removing on edge systems because you shouldn’t have to authenticate an older system at the firewall.

SNMP
The Simple Network Management Protocol (SNMP) can also be an issue. By default, SNMP community strings are often “public” or “private.” SNMP is used to monitor and manage many types of network devices. Unfortunately, SNMP does not use encryption to authenticate to devices. Therefore, intruders may try to use this protocol to disrupt devices on the network. If the intruder has physical access to your network, he or she can easily analyze network traffic for SNMP, which can divulge a great deal of info about network devices, including their layout and addressing structure. This sensitive information can then be used to compromise the network. For these reasons, I recommend not running SNMP services on an edge system. You will also want to block the standard ports 161-162 UDP at the router and firewall.

Learn from the past
Remember to keep the past in mind as you move forward. Systems are often compromised by older, well-known techniques that have either been forgotten or have fallen out of the spotlight. Review your configurations carefully. When a server is installed, it is often installed with all optional services. Fortunately, many commercially available firewall software systems will shut down any risky services on the host where it is installed. However, I recommend that you review the services running on your servers to determine which are really necessary. You will then want to disable or remove unnecessary services, thereby reducing the avenues available to intruders.

Always consider the problem from an overall network perspective. If you can provide dual protection by filtering at the edge router as well as the server, do so. If you are concerned about an application or a service but don’t know what ports to filter, research it on the Microsoft site or use a sniffer to analyze the traffic on your network. All common ports are listed in the Services file under the NOS. You’ll also want to keep servers up to date with current service packs, as these often contain patches and fixes that are security and protocol related. Finally, read the log files on a regular basis. It may seem mundane, but it is one of the best tools to discover intrusion or the attempt to do so. For a more complete list of known security issues and fixes, visit the Microsoft Security site, the SANS Institute, or the COAST Hotlist.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.