Plugging the most well-known holes in your Windows NT network is surprisingly easy. The author takes you step by step through her favorites.

Top 10 Security Fixes

Plugging the most well-known holes in your Windows NT network is surprisingly easy. The author takes you step by step through her favorites.

• By Roberta Bragg
• 03/01/2000

I was chatting with some heathens today. You know who I mean. They hate Microsoft so much that they meet any good thing Microsoft has done-especially anything to improve security-with the response, "But no administrator will ever do that, so it's useless." Here's your chance to make them liars by implementing the 10 security fixes to Windows NT that I recommend here. And even though I know that plenty of you haven't moved to Windows 2000, I'll offer some tips on that too for future reference. [Also see the author's article in this issue on security in Windows 2000. --Ed.]

1. Filter Passwords

Brilliant hackers aside, the single most important thing you can do to strengthen your network defense is to insist that everyone have strong passwords. That means at least six characters long; with upper and lower case letters, numbers, and punctuation symbols; and changed frequently. If I could make everyone do that on my network, of course, it would be a miracle. Passfilt.dll isn't magic, but it can help. The file, introduced with NT 4.0 Service Pack 2, should reside in your %systemroot%\System32 folder. Passfilt requires users to create passwords with these combinations. Users also can't have any part of their names in their password. To make users change passwords frequently, you must make other changes in User Manager for Domain | Account Policy. To make it work, do this in the Registry:

1. On the PDC, go to HKLM\SYSTEM\CurrentControlSet\Control\Lsa and double click on the Notification Packages key.
2. Add passfilt.
3. Press return.
4. Click OK.
5. Exit the Registry.

If the fpnwclnt entry is already there, place passfilt on its own line, below fpnwclnt.

Passfilt doesn't invalidate current passwords. To make users change their passwords, go to User Manager for Domains and select all users, then click the box, "User must change password at next logon."

It's unnecessary to make this change on your BDCs; the PDC is the only place changes are made to the domain account database. However, you may wish to change this at the BDC in case an emergency arises and you have to promote the BDC to PDC; in all the excitement you'll never remember to add it.

Three caveats. First, administrators can interactively change a password to something that doesn't meet these requirements. Direct changes (not over the network) to the SAM aren't filtered.

Second, users logging on from Windows 9x clients can use lower case letters in their passwords. If my password is Put13thuP, from Windows 95 I can log in using put13thup, Put13thup, or any other combination of upper or lower case letters. But if I'm working on NT, I must use the Put13thuP form. Windows 9x doesn't allow case-sensitive passwords.

Third, although passfilt is supposed to block users from including names in passwords, there are some cases when this doesn't work well. For example, I could create a password xxx*Bragg123. Microsoft has announced a hotfix for this problem but advises waiting for the next service pack unless this is a serious issue in your environment. The hotfix is available from Microsoft Product Support.

For more information on passfilt, refer to the following Knowledge Base articles:

• Q151082, "HOWTO: Password Change Filtering & Notification in Windows NT."
• Q174075, "Strong Passwords With PASSFILT.DLL Are Not Enforced."
• Q174076, "Invalid Password Message When Strong Passwords Are Required."
• Q196465, "Err Msg: Your Password Must Be at Least 0 Characters Long..."
• Q247975, "Strong Passwords May Contain Parts of the Full Name."

For more on passfilt.dll, visit http://msdn.microsoft.com/library/psdk/logauth/pswd_about_9x7w.htm.

In Windows 2000, use of strong passwords can be enforced by using the local Computer Policy snap-in and enabling "passwords must meet complexity requirements" setting in Configuration\Software Settings\Account Policy\Password Policy. Alternatively, you can set the policy for a site or organizational unit by using Group Policy.

2. Restrict Administrator Logon

One way to eliminate the possibility of hackers using a compromised administrator account and password is to prevent the administrator from logging on across the network. You can do this with passprop, an NT 4.0 Resource Kit utility. The utility can also be used to enable password filtering. (Like passfilt, passprop insists on upper and lower case and punctuation passwords. It also rejects new passwords if they're similar to the old. If my password is "Friday12" this month, next month it can't be "Friday13."

After obtaining the utility, use the following commands to implement it:

PASSPROP [/complex] [/simple][/adminlockout] [/noadminlockout]

• /complex enables password filtering.
• /simple disables it.
• /adminlockout keeps the admin out unless he or she is sitting at the console.
• /noadminlockout removes this restriction.

A caveat: Neither you nor the hacker will be able to do any "remote administration."

In Windows 2000, "Accessing this computer from the network" is a User Rights Assignment setting in the Local Policy snap-in in Windows 2000. By default administrators are allowed; however, you can deny them this opportunity by group or individually.

3. Learn Command Line Commands

We should all learn to use the command line. If my monitor goes dark someday, I could administer NT by touch typing and memory. Meanwhile, it's nice to be able to create simple batch files and scripts that will do some work for us. It's certainly easier to run a script at multiple locations than to sit at the console. I have a few favorites to start you out.

First up is Net Accounts. I just love reading undocumented documentation, don't you? It's as if we're being let in on some secret that only the initiated know. We glean the facts, useful or not, and try to find someone who hasn't seen it yet, only to find out it's listed all over the place. Oh, well. Take a look at Q194739 ("INFO: Undocumented 'Net Accounts' Switches"). These switches are important because they allow us briefly to pretend we're Unix administrators. Net Accounts is a command we must issue from a command prompt to make changes to Account Policy settings. The real scoop, though, is that we can put it in a batch file. Who says NT doesn't have utilities that allow you to manage the enterprise! Try them yourself.

Here are the documented switches for Net Accounts you'll want to know about:

• /FORCELOGGOFF: {minutes | NO} forces users to log off.
• /MINPWLEN:length sets the minimum password length.
• /MAXPWAGE:{days | UNLIMITED} sets the maximum password age.
• /MINPWAGE:days sets the minimum password age.
• /UNIQUEPW:number sets a unique password number.
• /DOMAIN indicates information should come from the PDC; if that's left out, information will be pulled from the local machine.
• /SYNC synchronizes the domain user account database.

Here are undocumented parameters:

• /LOCKOUTTHRESHOLD:number sets the number of failed attempts.
• /LOCKOUTDURATION:minutes sets the number of minutes accounts remain locked out before being reset (range from 1 to 99,999).
• /LOCKOUTWINDOW:minutes sets the maximum number of minutes before consecutive failed logon attempts (range from 1 to 99,999).

Entering "NET ACCOUNTS" at a command prompt and pressing Enter returns a list of the values set in the Account Policy as well as the role of the domain controller. You can pipe this information to a text file with:

NET ACCOUNTS /DOMAIN > accounts.txt

A caveat: The Net Logon service must be running.

Here are some other command line commands to consider using:

• NET LOCALGROUP /add adds the user or global group to the local group.
• NET USERS /DOMAIN > USERS.TXT sends a list of the domain users accounts from the PDC to the text file users.txt. To obtain more detailed information about each user, edit users.txt to make it a batch file. Remove the "user accounts for \\server" lines; for each user put the command "NET USER" before the name. Save the file as users.bat and run it to pipe output to another text file.
• NET USER USER_NAME /TIMES:MONDAY, TUESDAY,2 modifies logon hours for user USER_NAME.
• NET USER administrator sets the administrator password to "password". You must be an administrator to run this.
• NET CONFIG SERVER > server.txt lists the server name, version of NT, active network adapter info including MAC addresses, server hidden status, maximum logged on users, maximum open files per session, and idle session time to the file server.txt. Read Q137848, "Creating User and Group Reports in Windows NT" to learn more.
• NET CONFIG WORKSTATION > workstation.txt lists the workstation name, user name, version of NT, network adapter, network adapter information with MAC address, logon domain, open timeout, COM send count, and COM send timeout to the file workstation.txt.
• NET GROUP /DOMAIN > dbrp.txt lists the domain groups to dbrp.txt.
• NET LOCALGROUP > lgrp.txt lists the local groups on the local machine to lgrp.txt.
• NET VIEW/DOMAIN: DOMAINNAME > view.txt returns the resources in the specified domain to view.txt.
• PERMS COMPUTERNAME \USERNAME C:\*.* /S > perms.txt writes USERNAME permissions on all files in all subdirectories on the c:\ drive of COMPUTERNAME.
• ADDUSERS \\COMPUTERNAME /D USERINFO.TXT returns a comma-delimited file containing user and group information to the userinfo.txt file.

4. Use Free, Free, Free Security Utilities

SomarSoft utilities are now available for download on SystemTools' Web site (www.somarsoft.com takes you to the correct page). SystemTools acquired these tools from SomarSoft last year. DumpAcl dumps permissions (DACLs) and audit settings (SACLs). File system, Registry, printers, and shares are listed, as well as user, group, and replication information. DumpEvt dumps event logs into a format for importing into a database. (DUMPEL, a Microsoft utility, also does this.) DumpReg dumps the Registry. You can sort the entries by reverse order of last modified time.

5. Try Jammer, Then Pay for It

Even though some of the features that work with Windows 9x don't work under NT, I like Jammer from Jammersoft (http://jammer.comset.net) This nifty little doohickey runs behind the scenes and monitors your personal system for evidence of attack. It's sort of a personal intrusion detection program.

Jammer places an eyeball on your taskbar. If the eyeball starts winking, you're being attacked or you're infected with a Trojan virus. Jammer can disinfect your system too. It also plays a warning sound, displays a message on the main screen, and writes information to a log file. Jammer catches hackers in the act of scanning your system looking for NetBus or BackOrifice servers. You'll even get a report of their hacker IP address and attacked port numbers. A disconnect button lets you kick the hacker off immediately while you fix your system.

The program also generates an email message with information on the hacker, which you can email to his or her provider. Let's see how they like it when someone reaches out and touches them.

While these features don't yet work on NT, some equally important ones do. Jammer monitors any program-generated changes to your Registry and politely asks if you wish to allow it. That should keep attacks that attempt to change Registry settings (including that game that installs BackOrifice) from getting away with it. Jammer also displays a list of the "run once"-type sensitive keys, so you can look to see what they are. These keys are important because if a hacker can't trick you into running their code but can access your Registry, he or she can get a program to run at system startup.

Jammer also allows you to read the list of processes running on your system. Yeah, I know that's available from the taskbar; but this utility tells you what the process is. I know that navapwa32 is my magical Norton antivirus process, and daemon is my IBM ThinkPad's track point service. When you've got a slew of processes running on every computer-and maybe even some that shouldn't be running there-Jammer helps you to tell the difference between the ordinary and the strange. I've long said that in order to recognize suspicious programs on our systems, we first need to know what's normal for our machines. It's been hard to identify that; now we can easily find out.

You can also use Jammer's netstat window to see what ports your system is listening on (ah, any suspicious activity here?) and what connections you have.

A pretty neat package, and all for $19.95. You can download a 30-day trial version.

6. Mitigate LAN Manager Hash Password Vulnerabilities

You've surely heard the story by now. Because NT needs to allow legacy Windows clients to authenticate, two password hashes cross the network every time you log on: the weak LM hash for backward compatibility and the stronger NTLM hash. Crackers can attack the weak LM hash, find your password, and then more easily get the stronger NTLM hash. This is how LophtCrack sucks your passwords off the wire. Short of rolling out a pure Win2K network and using Kerberos exclusively (Kerberos is the de facto authentication process in Win2K), what can you do?

Enter NTLMv2 (an even stronger version of NTLM), NT Service Pack 4, and some Registry changes. You can eliminate the use of LM or merely set your systems to negotiate the strongest relationship for each session. NTLMv2 uses a 128-bit password-derived key and improves session security. This is especially important in virtual private networks (VPNs).

You control NTLM authentication security at the LSA Registry key:

HKLM\system\CurrentControlSet\Control\LSA\

Add the value LMCompatibilityLevel (REG_DWORd) with a default of 0 and then set its value to one of the following:

• 0-Send LM response and NTLM response; never user NTLMv2.
• 1-Use NTLMv2 session security if negotiated.
• 2-Send NTLM authentication only.
• 3-Send NTLMv2 authentication only.
• 4-DC refuses LM authentication.
• 5-DC refuses LM and NTLM authentication.

Clients: If the SP 4 client chooses level 3 or greater, the client's domain controller must be at SP 4. If the client chooses level 1, it will interoperate with SP 3 servers and negotiate session security with SP 4 servers. If it chooses level 2, it won't be able to connect to Windows 95 or Windows 98. If it chooses level 3 or greater, it will always send the NTLMv2 response.

Servers: If set to level 4 or above , down-level users with accounts on that server won't be able to connect from down-level clients.

After authentication, the connection or session takes place under a security level as well. Applications also may negotiate security. To control the minimum security negotiated for applications using NTLMSSP (the NTLM security support provider), set the key like this:

HKLM\System\CurrentControlSet\control\SA\MSV1_0\

Add the REG_DWORD values NtlmMinClientSec or NtlmMinServerSec. The valid range is:

• 0x00000010-Message integrity.
• 0x00000020-Message confidentiality.
• 0x00080000-NTLMv2 session security.
• 0x20000000-128-bit encryption.

Note: It's this version of NTLM (NTLMv2) used in a PPTP connection making a VPN. You have to make sure you're using an updated client (upgraded versions of Windows 95 and Windows 98) and server (NT SP 4) processes (as documented in Q191540, "VPN Update for Windows 98 and Dial-Up Networking 1.3 Available";Q237691, "Windows 98 Dial-Up Networking Security Upgrade Release Notes (July 1999)"). You'll also use an updated version of MSCHAP (version 2), which provides mutual authentication, stronger data encryption keys, and different keys for transmit and receive paths.

You'll be pleased to know that NTLMv2 for normal (non-VPN) authentication will be available for Windows 95/98 as part of the Windows 2000 Active Directory Client for Windows 95/98. See article Q239869, "How to Enable NTLM 2 authentication for Windows 95/98 clients," for more information.

A caveat: Setting NtlmMinClientSec or NtlmMinServerSec doesn't guarantee that NTLM SSP is used by an application or that message integrity or confidentially will actually be used by the application. These settings just allow the process to take place if the applications are wired for it. To learn more, refer to Q147706, "How to Disable LM Authentication on Windows NT," and Q241338, "Windows NT LAN Manager Version 3 Client with First Logon Prevents Subsequent Logon Activity."

Windows 2000, which uses Kerberos for authentication, accepts LM and NTLM and NTLMv2 for backward compatibility. If you have particular servers to secure, you can adjust these settings as well. When you've upgraded all systems to Win2K, you can eliminate NT, NTLM, and NTLMv2 from your network.

7. Disable Administrative Shares

We all know that C$ and its ilk are hidden shares. So are ADMIN$ (c:\winnt), IPC$ (Interprocess communication share), PRINT$ (C:\winnt\system32\spool\drivers), REPL$ (c:\winnt\system32\repl\export), and NETLOGON (c:\winnt\system32\repl\import\scripts). All are well known, and all are targets for hackers. But we can't turn most of them off and still print, log on, or perform any of a myriad of other useful activities. But can we turn off things like drive roots?

C$ is a particularly bad share to leave open. This share is also an administrative share-that is, no one but administrators can connect to it. This would be a good one to disable if you don't need it in your environment. The way to do this through the Registry is:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Value name: AutoShareServer
Data Type: REG_BINARY

This can be done also using Systems Policy Editor with the "Create hidden driver shares" entry. The shares can also be deleted, one by one, by using net share:

Net share C$ /d

Administrative shares can be re-created by using:

Net share admin$
Net share c$=c:\

8. Sign for Packets

NT 4.0 Service Pack 3 updates the Server Message Block authentication protocol. You can either enable or require that every packet be signed for and verified (or do both). NT, Windows 2000, and Windows 98 can participate in such a setup. If you set RequireSecuritySignature on the server, you won't be able to make shared files available to Windows 95 clients. You must add and configure registry values to enable the feature. For Windows 98, add the value at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\VxD\VNetsup 

In NT go to:

HKLM\System\CurrentControlSet\Services\LanManServer\Parameters

Set the REG_DWORD value RequireSecuritySignature to 1. Set the REG_DWORD value EnableSecuritySignature to 1.

On an NT workstation use:

HKLM\System\CurrentControlSet\Services\
Rdr\Parameters

EnableSecuritySignature
RequireSecuritySignature

Two caveats: Using this feature decreases network performance between 10 and 15 percent. Windows 95 clients won't be able to access share points on the server. To learn more, read Q199714, "Cannot Join Domain Because of SMB Signing," Q230545, "How to Enable SMB Signing in Windows 98," and Q161372, "How to Enable SMB Signing in Windows NT."

9. Put Syskey to Work Properly

I build a fence; you climb it. I build it higher and put razor wire on top. You steal a key to the gate. So goes the security game. Microsoft introduced syskey, a utility that encrypts the SAM using 128-bit encryption. This keeps the SAM safer from attack. Microsoft also should have made the SAM extremely invulnerable to attack even if a copy of the SAM (from a emergency repair disk or the repair folder) was stolen and attacked offline. But those of you who attended my sessions at MCP TechMentor last year saw a demonstration of pwdump2, a hacking tool that breaks syskey and makes the hijacked SAM vulnerable to attack by LophtCrack and other password crackers.

It turns out, as explained in Security Bulletin MS 959-056, that Microsoft incorrectly coded syskey and in doing so reused the keystream (the output of the cryptographic algorithm). This made the syskey'd SAM that was offline more vulnerable to attack. The need to provide a fresh , unique value for initialization is well known, and Microsoft goofed. (Interestingly, it had the same problem with its original implementation of PPTP. That's long since been corrected, but history repeats itself, no?)

A patch is available at www.microsoft.com/downloads/release.asp?ReleaseID=16798 . 

Read more by referencing the Knowledge Base articles Q248183, "Syskey Tool Reuses Keystream," and Q143475, "Windows NT System Key Permits Strong Encryption of the SAM." 

None of this is a problem in Win2K.

10. Install Service Pack 6, er, 6a, er, 7.x…

While I have your attention, take a little trip out to www.microsoft.com/security. Read those security bulletins. You'll find all kinds of security holes you never knew existed-and what to do about them. You'll also see that the hotfix recommended for a specific problem resolves the security issue, but isn't supported, so you'd better wait for the service pack. Well, the service pack's here.