[ISN] Steel-Cage Security for Windows NT

From: mea culpa (jerichoat_private)
Date: Fri Jun 19 1998 - 16:19:34 PDT

  • Next message: mea culpa: "[ISN] A gaggle of new ciphers"

    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