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:
- On the PDC, go to HKLM\SYSTEM\CurrentControlSet\Control\Lsa
and double click on the Notification Packages key.
- Add passfilt.
- Press return.
- Click OK.
- 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.