|
Microsoft's password filter isn't foolproof. Although it works on
NT servers designated as primary or backup domain controllers (PDCs or
BDCs), the filter can be overridden by entering a weak password
directly into the User Manager facility. (This isn't something
available to most end-users, however, since administrator rights are
needed to make changes via User Manager.) Netware Directory Services
for NT from Novell Inc. (Orem, Utah) also bypasses the password
filter, but performs its own password integrity check.
Password Crackers
Even though NT stores passwords in encrypted form, it's amazing how
quickly they can be decrypted using brute-force attack programs. These
programs have become very sophisticated, with full understanding of NT
security policies and speeds that exceed 10,000 attempted passwords
per minute. How do they work? The
program examines the NT network's
domain password policy (available via anony-mous log-in) and extracts
all account names. It then compares passwords against a dictionary
that conforms to the domain password policy (for example, if passwords
must be eight characters or longer, the dictionary will not include
words shorter than eight). Some programs work by capturing the
encrypted password in transit and comparing it to a dictionary of
encrypted words.
Typically these programs start with the privileged account names
like administrator and IUSR_[servername]. If the dictionary attack
decrypts no passwords, the program then compares the passwords against
a dictionary of proper names. If any account password is a word or
proper name, it's sure to be compromised. Fortunately, dictionary
attacks can be thwarted by enabling passfilt.dll.
Another key to password protection is eliminating and disabling
well-known user accounts. Many NT applications require an
administrator or service account to manage
that specific app. These
include Microsoft IIS (Internet Information Server), Microsoft SQL
Server, and various third-party mail and fax apps. A common mistake
when installing these apps is to accept the default account name
instead of renaming it. Unfortunately, these well-known default
accounts are typically attacked first, especially from external users.
One approach is to rename the administrator account to something
innocuous, and then set up a decoy administrator account that's fully
audited. This will quickly detect if the account is under attack.
But simply renaming an account offers relatively little security.
Today's cracker tools make it possible to enumerate account names,
even via anonymous access. Microsoft is addressing this in the
forthcoming Active Directory, where all objects (including account
names) are governed by security certificates. In the meantime (and
even once Active Directory is in place), it's important to audit
account access.
The Audit Trail
Next come
s the enabling of the audit subsystem. By default, NT
doesn't audit any password events. Net managers can enable auditing in
the User Manager application, under the Policies/Audit headings. User
Manager allows net managers to define which log-on events to audit,
and whether they were successes or failures. A good starting point is
enabling audit for log-on and log-off (success and failure); file and
object access (failure); and restart, shutdown, and system events
(success and failure). Note that changes to account auditing are
global. For large organizations, auditing log-ons will significantly
increase the size of the log file.
It's also possible to audit individual objects like directories,
files, and entries in the registry. To audit directories and files,
format disk volumes using the Windows NT file system (NTFS); the older
file access table (FAT) spec doesn't support file- or directory-level
auditing. To set up auditing with NTFS volumes, use the Windows
Explorer app to select the desired objec
t. Right-click the object,
select Properties, the security tab, and then the auditing button. Now
enable the desired set of auditing functions for the selected
accounts.
To audit registry entries, use the regedt32.exe application, but be
careful: Incorrect registry settings can leave a system inoperable or
un-stable. To enable auditing on a registry object, select the desired
object and then select Security/Auditing from the app's menu.
Now choose the users and events to be audited. It may be tempting
to audit every single file on an NT server, but that would have a
significant performance impact. Microsoft has an excellent white
paper, "Securing Windows NT Installation," that recommends appropriate
security settings for both the file and the registry systems (it's
available online at http://www.microsoft.
com/NTServer/Basics/SecServices/ Secure_NTInstall/default.asp).
Besides covering specific settings, the paper also discusses key
security issues like controlling remote access to the registr
y;
controlling access to the run program settings; and limiting the
abilities of the anonymous and guest accounts. Microsoft says it will
release a security configuration editor with Service Pack 4 this
summer (all the more reason to apply hot fixes).
Looking Through Logs
Another key consideration is what to do with security information
once it's been collected. Using the Event Viewer app, make sure the
log is large enough to hold all the audit events before they can be
reviewed and archived (the size can be set under Event Viewer's
Log/Log Settings menu). To ensure no audit entries are erased, select
the "do not overwrite" option, again under Log/Log Settings. Also
consider what action to take when the audit logs become full before
they are reviewed. If they're critical, the server should be set to
shut down on audit failure. This can be accomplished using
regedt32.exe, not Event Viewer. Set or add the registry key
CrashOnAuditFail located in HKEY_LOCAL_ MACHINE\
SYSTEM\CurrentControlSet\Co
ntrol\ Lsa to a value of 1 (enabled).
Inside employees often try to increase their access level and
privileges on the network by having domain administrators log on to
the network at the user's local machine. If the user has local system
(not domain) administrator privileges, then it's easy to plant various
programs to capture passwords, schedule tasks to run under the
administrator's account, and even unlock screen savers remotely.
Domain system administrators need to realize that they should never
log into the network from other networked computers unless they fully
trust the administrator of that specific system.
How Strong a Client?
In assessing which flavor of Windows to deploy at the desktop, be
aware that the NT Workstation client offers considerably stronger
security than other versions of Windows. Windows for Workgroups (WFW),
Windows 95, and Windows 98 all authenticate users with the LAN Manager
(LM) challenge-response scheme developed in the 1980s. The LM scheme
also is us
ed in most implementations of PPTP (point-to-point tunneling
protocol).
Simply put, the LM password-hashing algorithms are not as strong as
the NT versions. Cracking programs available from various Web sites
let users attack the LM hash password. An NT Server by default sends
both the NT and LM password forms to the client during any log-on
authentication request. To eliminate the use of LM, Microsoft has
released a patch called lm-fix that restricts the NT server to sending
the NT passwords only. However, an NT server with this patch applied
will no longer be able to authenticate connections from WFW, Windows
95, and Windows 98 clients. So if the information on a particular
server is deemed highly sensitive, it may be advisable to require
access via NT Workstation as the desktop OS, and not another version
of Windows.
The use of NT clients is also advisable to guard against
"man-in-the-middle" attacks, where an intruder intercepts packets in
transit and changes the security credentials to ad
ministrator, thereby
allowing administrative functions on the server. To counter this,
Microsoft has furnished SMB Signing (Server Message Block Signing):
Every packet sent between NT systems is actually signed for as the
original copy. This verifies that the sender/receiver pair have prior
knowledge of the end-user's password. Here again, strong password
security is required.
Since SMB Signing verifies every packet in the stream, there is a
10 percent to 15 percent performance hit on the server, which is a
small price to pay for securing critical data. However, this feature
is available only for Windows NT.
One limitation of NT is that it authenticates only the client to
the server, and not vice versa. Server authentication is needed in
situations (like e-commerce or extranets) where the client may not
have a trust relationship with the server. Windows NT 5.0, slated to
be released sometime next year, will boost client security with the
use of Kerberos authentication protocol (RFC 1510), whic
h by default
allows mutual authentication of both server and client. However,
Kerberos support will be available only for NT 5.0.
Hot Fixes
New exploits of NT are discovered all the time on various mailing
lists. Microsoft typically releases patches within 24 to 48 hours
after vulnerabilities are announced. These so-called hot fixes have
not been fully regression-tested, which means they may bring
instability to some applications. (Microsoft has withdrawn and
reissued hot fixes where this has been the case.) It's worth the risk:
The hot fixes plug holes that attackers are sure to exploit.
Since the release of Service Pack 3 (SP3) last year, Microsoft has
released more than 30 hot fixes for NT 4.0, including many related to
security. Other fixes cover PPTP denial-of-service attacks; so-called
Land attacks; invalid UDP (user datagram protocol) and ICMP (Internet
control message protocol) packets that cause NT systems to hang; and
several essential system updates.
Microsoft will
bundle all the current hot fixes into SP4, expected
to be released this month after complete regression testing. But if
SP4 ships late, or if an organization postpones the application of
SP4, it's imperative to apply security hot fixes as they're announced.
Since hot fixes are not integrated into one larger package, the
order in which they're applied is critical. Microsoft maintains the
proper hot fix order list at ftp://ftp.microsoft.com/bussys/
winnt/winnt-public/fixes/usa/nt40/ hotfixes-postSP3/postsp3.txt.
Keeping Up to Date
Of course, applying service packs and hot fixes implies net
managers know about them before attackers do. There are several ways
to accomplish this. First, subscribe to a good mailing list. Both the
ntbugtraq and ntsecurity lists are moderated, and both keep current on
Microsoft NT security issues (see http://www.ntbugtraq.com for more
details). Second, visit the Microsoft Web site
(http://support.microsoft.com/ support/ntserver/) to check what hot
fixes ar
e available for NT Server.
Third, consider using some of the third-party tools available for
managing NT security. These can consolidate audit logs, generate
reports, and deploy a consistent security policy across multiple NT
servers. Intrusion detection tools are also an option. Some of these
actively scan NT systems, much the way a virus scanner examines files
for known data patterns. Among the tools in this category are Internet
Scanner for NT from Internet Security Systems Inc. (ISS, Atlanta) and
Ballista from Secure Networks Inc. (Calgary, Alberta).
Another type of intrusion detection system passively monitors the
network and looks for attack signatures or anomalies in normal usage
patterns. When these packages spot a problem, they alert the net
manager; some also shut down servers, routers, or firewalls. Among the
available products are ESM from Axent Technologies (Rockville, Md.);
Netranger from Cisco Systems Inc. (San Jose, Calif.); Realsecure from
ISS; Netstalker from Network Associat
es (Santa Clara, Calif.); and
Network Flight Recorder from Network Flight Recorder Inc. (Woodbine,
Md.).
Remember that no operating system is 100 percent secure—and
that NT is still a hacker's playground. As a result, there will be new
hacker utilities released on the Web that will exploit yet
undiscovered security holes in the operating system and various NT
applications. However, this does not make NT any less secure than any
other operating system—and it's possible that NT will be more
secure than Unix systems in the long run as a result.
|
