[ISN] Steel-Cage Security for Windows NT

Forwarded From: "Prosser, Mike" <Mike_Prosser@tds.com>


  http://www.data.com/tutorials/cage.html

By Al Lounsbury, MCI Systemhouse

NT Security

Steel-Cage Security for Windows NT

Corporate networkers can significantly boost the security of NT Server
and NT Workstation
 Situation report: A user on the corporate Windows NT network has a
run-in with the IT department. The user goes home that night and plots
revenge: He logs on to the Web via his personal ISP account, since Web
access from the corporate network is tightly controlled. He searches for
NT exploits, knowing that corporate net managers are so busy addressing
day-to-day issues that internal security is low on their list. The user
creates a batch file, which he brings to work the next day, installs on
someone else's computer, and schedules to run after lunch. The batch
file launches the so-called teardrop attack against all the company's
Windows NT servers and then automatically deletes itself. Within
minutes, the NT servers start falling like flies. The IT department
thinks a broadcast storm is responsible- and one user heads home with a
satisfied grin on his face.

Unlikely scenario? Hardly-and worse yet, it's incredibly easy to
recreate. But it also can be prevented, and culprits attempting such an
attack can even be caught in the act.

With Microsoft Windows NT server shipments growing fast, securing
Windows NT servers and workstations has become a top priority for
network managers. It has to be-new exploits are turning up all the time,
sometimes at the rate of several per week. What's more, recent studies
have shown that at least 75 percent of all security breaches are
internal, making NT security all the more important.

Fortunately, it is possible to significantly increase the security level
of both Windows NT Server and NT Workstation. Net managers just have to
know how to go about it.

Seven Deadly Sins
To get started, look at the seven main ways Windows NT from Microsoft
Corp. (Redmond, Wash.) can be vulnerable. Companies may have poor or
nonexistent security policies; they may have weak passwords and password
policies; there could be a lack of audit trails; they might have a lax
approach to file system security; there could be inappropriate registry
security; there might be untrusted client workstations; and there's
sometimes failure to apply Microsoft's many security patches.

The first task, then, is to establish a security policy and fully
document it. It's difficult to hold net managers responsible for
security when there is nothing or little to hold them accountable to.
The same holds true for end-users; remember that most security breaches
are internal.

Establishing a security policy can be a tricky business (see "Network
Security: Locking In To Policy," March 21, 1998;
http://www.data.com/tutorials/locking.html). Contracting with a security
consultant could save significant time at the outset-and it could
possibly save the business in the long run. Training is also an
important part of policy implementation. Since end-users play a critical
role in security, make sure they're aware of the established policy,
including the auditing aspect.

Who Goes There?
Password security at most sites can charitably be described as extremely
lax. There are often no policy-setting rules for password maintenance;
as a result, net managers and end-users choose weak passwords that
sophisticated cracking programs can easily compromise and that are left
in effect for far too long.

NT's User Manager program allows granular control of password attributes
under the headings "Policies/Account." As a starting point, here are
some basic recommendations: Set the maximum password age to 90 days; set
the minimum password age to seven days to prevent end-users from cycling
back to previously used passwords; and set the minimum password length
to eight characters.

Also use passfilt.dll, a password filter that Microsoft includes with
Service Pack 2 (SP2) for Windows NT 4.0 and subsequent service packs.
The filter resides on NT servers and rejects passwords that are easily
cracked. Once this filter is activated, account passwords must contain
at least three out of four conditions: uppercase English letters;
lowercase English letters; numbers; and special characters like
punctuation marks. To activate the password filter, start the program
regedt32.exe and look under HKEY_ LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Control\Lsa for the registry key "Notification
Packages." Add the string "PASSFILT" to this key. As with any change to
the registry (the database of all system settings used by the operating
system), take extreme caution to ensure existing entries are not
removed.

Then take the following steps: Set the password uniqueness to 10
passwords (meaning end-users must go through 10 passwords before they
can reuse an old one); lock out end-users after six bad log-on attempts;
set the lockout duration to one hour, or permanent in some cases
(lockout prevents an account from being accessed after a given number of
bad passwords; the default is five attempts); and set the bad log-on
counter reset to 30 minutes (the counter tracks the number of incorrect
passwords entered).


MORE INFO
Sense of Security


 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 comes 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 object. 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 registry; 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\Control\ 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
used 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 administrator, 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), which 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
are 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 Associates (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.


-o-
Subscribe: mail majordomo@sekurity.org with "subscribe isn".
Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]