Forwarded From: "Prosser, Mike" <Mike_Prosserat_private> 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 majordomoat_private with "subscribe isn". Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:56:26 PDT