Security Tips & Tricks

During the past year, we upgraded our entire domain to Windows 2000. We recently analyzed network traffic and noticed that we were capturing NetBIOS packets. Didn't Microsoft eliminate NetBIOS from pure Win2K environments because it's not a secure transport protocol?

NetBIOS isn't a transport protocol; it's a high-level interprocess communications (IPC) protocol that a transport protocol such as IP, IPX, or NetBEUI must carry. IP carries NetBIOS traffic on UDP ports 137 and 138 and TCP port 139, which is called NetBIOS over TCP/IP (NetBT). To handle file and printer sharing, Microsoft uses the Server Message Block (SMB) protocol, an even higher-level protocol. Windows NT 4.0 and Windows 9x use NetBIOS to carry SMB, and of course NetBIOS rides inside IP, IPX, or NetBEUI.

NetBIOS includes name-resolution and resource-publishing features, but be-cause these features don't scale well to large networks, Microsoft developed WINS, which has had its share of problems. With Win2K, Microsoft broke from naming limitations inherent to NetBIOS and enabled the OS to rely solely on proven Internet technologies such as DNS. Win2K can directly host SMB on IP by using TCP and UDP port 445, which is known as the Common Internet File System (CIFS).

By default, Win2K servers support clients that use NetBT or CIFS to connect, so these servers have no problem supporting NT 4.0 or Win9x clients. But how does a Win2K client know whether to use NetBT or CIFS when it tries to connect to another computer? Win2K doesn't contact the server first to determine which OS the server is running; instead, the Win2K client sends connection requests to ports 139 and 445 at the same time. The server answers on one port, and the client communicates on that port and resets the other. If a Win2K client attempts to connect to an NT 4.0 server, the NT server ignores the port 445 connection request and responds on port 139. If the Win2K client attempts to connect to a Win2K server, the server chooses to respond on port 445. These dual connection attempts are causing the "NetBIOS" packets that you continue to see.

As for security, NetBT isn't really the risk*leaving file sharing active on a server is. The risk of intruders accessing the security service is the same whether they use port 445 or 139 to gain entry to your machine. The advantages of eliminating NetBIOS are enhanced network performance and better name resolution, both of which enable greater scalability. Mark Minasi does a great job of describing how to disable NetBIOS and the effects of doing so in "Life Without NetBIOS," August 2001, http://www.winnetmag.com, InstantDoc ID 21537.

We migrated our entire domain to Windows 2000 and moved the domain from mixed mode to native mode. Recently, I ran a Windows LAN Manager (NTLM) sniffer and discovered that I can still detect NTLM packets when users connect to a particular server on my network. The server is a Win2K machine and is a member of my Active Directory (AD) domain. I thought that a Win2K domain in native mode eliminated NTLM, which I know is much weaker than Kerberos and relatively easy to sniff and crack. What's the deal?>

Native mode and mixed mode have nothing to do with whether computers in the domain use NTLM or Kerberos for authentication. Native mode requires that all domain controllers (DCs)*not all computers*in a domain be Win2K machines. Mixed mode is a temporary mode that a domain starts out in that lets AD support legacy NT BDCs. In mixed mode, AD disables certain features that an NT BDC's SAM can't reflect, including the nesting of global and local security groups and the creation of universal security groups. After you decommission or upgrade all your BDCs to Win2K, you can bring the domain to native mode and regain the functionality you lost while in mixed mode.

As a client, Win2K tries to use Kerberos to authenticate, and if the server or DC doesn't answer, the client falls back to NTLM. Regardless of the domain mode, Win2K DCs and servers support clients that use NTLM. However, because you've upgraded all your computers to Win2K and made them part of an AD domain, the fact that you continue to see NTLM packets when clients connect to your server is interesting. Are the clients all Windows XP or Win2K and part of the overall forest? If not*if, for example, the clients are NT 4.0 machines in a trusted NT domain*they can authenticate to the server only by using NTLM. Another possibility is that although your server and clients are Win2K computers in the same forest, the clients connect to the server by using local user accounts on the server's SAM (which you created in the Computer Management\Local Users and Groups snap-in) instead of with AD domain user accounts. Win2K doesn't support Kerberos for local user accounts, so whenever you connect to a computer by using a local account, you authenticate by using the weaker NTLM protocol.

Win2K gives you no option to completely disable NTLM, so you're left to configure your network to avoid using NTLM (i.e., keep all your computers in the same forest, don't set up trusts with NT domains, and don't use local accounts) and strengthen NTLM where you do use it. NTLM supports two hash and response types: LM and NT. NTLM is weak because of the LM response. Microsoft addressed these weaknesses with NTLMv2. Go to any Group Policy Object (GPO) and implement the LAN Manager Authentication Level policy under Computer Configuration, Windows Settings, Security Settings, Local Polices, Security Options to use NTLMv2 and configure your computers to refrain from sending or accepting the LM response and to use the much stronger NTLMv2 response. However, be aware that this transition isn't always a smooth one. You must make sure that NT and Win9x are properly updated and configured to use NTLMv2 before you configure your DCs to refuse weaker credentials. For more information about NTLMv2 and how to configure your clients to use it, see "Inside SP4 NTLMv2 Security Enhancements," September 1999, http://www.winnetmag.com, InstantDoc ID 7072, and the Microsoft articles "LMCompatibilityLevel and Its Effects" (Q175641, http://support.microsoft.com) and "How to Enable NTLM 2 Authentication for Windows 95/98/2000 and NT" (Q239869, http://support.microsoft.com).