In-Depth

Tickets, Please! Limit User Access with Windows 2000

Use Windows 2000's default security to make sure no one gets in without your permission. First step: Understand what ships in the product.

In the dream world of systems folks, operating systems would install automatically as unpenetrable fortresses. Windows 2000 moves closer toward that Nirvana; but rest assured you’re still guaranteed employment in setting it up correctly and securely. Having said that, there’s no need to make your job any harder than it already is. Follow my explanations here to understand how to make a clean Win2K installation as secure as possible from Day 1. Doing so will also make any extra security you decide to install later easier to learn about and add.

So, what security features come with Win2K? Which install automatically, and which will need some tweaking? For starters, here’s a list of some of the major security enhancements you’ll find in the product:

  • Kerberos
  • More granular file access permissions
  • Tighter default Registry settings
  • Security Configuration Tool Set and Secedit
  • Group Policy Editor
  • IP Security (IPSec)
  • Built-in smart card integration services
  • Windows File Protection
  • Built-in public key infrastructure (PKI)
  • Encrypting File System (EFS)

The list also includes a host of smaller-but-still-handy security features like a way to eliminate NetBIOS, which was a source for many system attacks; tighter file and program access; “super” hidden files that are difficult to view; and a write-protected kernel mode.

Although the product ships with all these features, is it secure on installation? Well, if you buy a house with an alarm system but don’t understand the key codes and therefore don’t set it, is it secure? As with any product you want to secure, you’ll need to delve into the features and how to use them. Let’s begin by taking a look at each security service in Windows 2000 and what you must do to make each work for you.

Kerberos

Like the classical guardian of the gates to Hades, Kerberos denies access to your OS—or any other resource in your enterprise—until you prove your identity. The Kerberos protocol has been an industry standard for many years and is well-proven to be secure.

On one level, Kerberos works by matching your logon identity and the password entered against its own Key Distribution Center; it then provides you with a ticket-granting ticket. Win2K caches this ticket for later use.

For example, if you want to visit the corporate email server to read your mail, use this ticket to hop on board the Kerberos security train. Next stop is the ticket-granting server. This server makes no judgment about your rights to access a particular mailbox; it merely verifies the authenticity of your ticket and issues you another ticket for the mail server. This second ticket authenticates you—it tells the mail server that “the bearer of this document is who he says he is.” The mail server then checks to see if you have permission to read the mail. And so it goes.

Whew! It sounds complicated. But to users, all this extra security is transparent. It’s also transparent to administrators, because Win2K uses Kerberos by default for network authentication. The widespread use of this protocol to secure other distributed systems offers the potential of integration with other implementations of Kerberos Version 5. Here at last is the opportunity for an integrated, truly cross-operating-system, enterprise-wide authentication security system. Of course, implementing that integration and understanding the causes of authentication problems, error messages, and so on, requires an in-depth understanding of this new protocol. (For starters, see Microsoft’s white paper on Kerberos integration at www.microsoft.com/security.) And Kerberos is no different than any other security based on passwords—you must implement a tight password policy in your environment.

Kerberos provides Windows 2000 with a more secure, industry-recognized replacement for logon than the much-maligned NTLM algorithm (also known as “challenge/response”) used in Windows NT (LM is used in Windows 9x). It also adds the capability for single sign-on through SSPI, Microsoft’s implementation of the General Security Service Application Program Interface (GSS-API) standard. GSS-API is an IETF-proposed standard API (RFC 1964) that can be used with Kerberos for this purpose. Single sign-on means interoperability between non-Windows 2000 clients that support the standard, and Windows 2000 clients and non-Windows 2000 Kerberos realms (MIT Kerberos domains).

One caveat: If you choose to integrate previous clients (NT or Windows 9x), you still need support for LM and NTLM logon. By default, support for these protocols is enabled; so to secure a 100-percent Win2K organization, you must remove this support. To limit use of LM and NTLM, implement Registry support for NTLMv2. (For more information on this, see my article, “Top 10 NT Security Fixes” online in this issue.)

Athena, Euripides, and a Dog Named Kerberos
“Athena and Euripides are working at neighboring terminals...” Thus begins a delightful, fictitious account written a dozen years ago about the design of Kerberos. In this account, Athena is tired of sharing a mainframe with others and wants to develop a system in which users can access resources across a network from their PCs. Euripides sees the inherent insecurity of such an arrangement. Together they hash out the design of a secure authentication protocol, which Athena names Kerberos after her Uncle Hades’ three-headed watchdog. This story, written by Bill Bryant and added to by Theodore Ts’o, is a good, easily understandable introduction to the Kerberos protocol. To read it, go to “Designing an Authentication System: a Dialogue in Four Scenes” at http://web.mit.edu/kerberos/www/dialogue.html. You’ll also find additional information on Kerberos at this MIT site.

More Granular File Access Permissions

With NT, you can explicitly deny file or folder access to any user or group. With Win2K, you can explicitly deny any permission to a file or folder to any user or group. That’s right—you can deny full control, or deny read, or deny write permission. This gives you much more granular control.

Let’s say Sharon Rollins is a member of both the Accountants Group and the Managers Group. The Managers Group is given read and write permissions to a folder; the Accountants group is given read permission. Without any other entries, Sharon has read and write access. In NT, giving Sharon read-only access to a certain file while maintaining read and write permission for the Managers Group meant you either had to make a new group, or remove Sharon from the Managers Group. You could deny her access, but that wasn’t what you really wanted. With Win2K, you simply deny Sharon write access to this particular file. She still maintains any other access granted by each group to other files and folders, and read access provided by the Accountants Group.

You also have the choice of stopping inheritance. To do this, uncheck the “allow inheritable permission from parent to propagate” box on the “security” tab of the file or folder properties dialog box when setting permissions. You can do this for any file or folder. If inheritance is blocked on subfolders, you can’t destroy their settings by bulk propagation from higher-level folders. (That closes a security hole in NT in which the OS could be destroyed by removing the group Everyone from the root and selecting “replace permission on subdirectories.”

Tighter Default Registry Settings

Fire up good old regedt32.exe and peek at the security settings for sensitive keys. You’ll find that many formerly wide-open areas are more tightly controlled. For example, the System group is already entered everywhere for you, with access rights of Full Control. The new thing here is that it’s actually listed. Remember trying to implement tighter security in NT? If you forgot to enter the System and give it Full Control, you were in danger of locking the OS out of its own files. Win2K prevents that administrative blunder by entering System controls for you.

Check out a few keys, and you’ll run into a new group called “Restricted.” This is an implicit group whose membership is determined by membership in one of the built-in sensitive groups, such as Administrators, Server Operators, Print Operators, and Account Operators (you can add your own groups to the Restricted group as well). Having this identity can serve to automatically provide security membership, and thus give or maintain special access to resources. The Restricted identity can also be leveraged to control membership in these sensitive groups.

In many cases, Administrators are given full control, Authenticated Users given read permission, and Server Operators given special permission. (Server Operators are not initially given permission to change permissions, make links, or change ownership.) Creator Owner is given Full Control, but only at the sub-key level. One of the keys thus treated is HKLM/SOFTWARE/Microsoft. Other keys are tightened, giving Server Operators read access only. Those keys are HKLM/SYSTEM/CurrentControlSet, and both HKLM/SOFTWARE/Microsoft/Windows/Current Version/Run and /Run Once.

An insidious hole is closed by assigning Creator Owner’s “Full Control” access to sub-keys only. In Win2K, applications may create Registry keys and can rightfully control those keys. Users running these applications can be given rights to access and modify keys, but this right doesn’t translate into the ability to create or modify other keys in that branch. This permission definition can also help control, at a granular level, exactly what can be done if key ownership is compromised.

But what about applications that had problems running in NT because they didn’t have access to needed areas of the Registry? Applications written to Win2K logo standards will ensure that users can run the applications they have the right to run, without compromising security. In truth, though, legacy applications and applications not written to standard will continue to have problems; you’ll need to audit their activities to find out which keys and what types of access they need. This is the bane of tighter security—additional work for administrators. Many applications will require twiddling with Registry and file security settings to maintain your sanity and security, while still allowing users access to their applications. To curtail this, be sure to shop for the Win2K application logo on new purchases. Developers, check out the specifications at www.msdn.microsoft.com/winlogo/win2000.asp and write your applications to conform to them. [See News in this issue to read about the slow growth of the Windows 2000 product certification program.—Ed.]

Security Configuration Tool Set and Secedit

The Security Configuration Tool Set is implemented in the Security Configuration and Analysis Snap-In in Win2K. It’s a collection of tools that lets you analyze, configure, and maintain anything from the security policy of a local computer to that of an entire Win2K enterprise. This tool became available the same time as NT 4.0 Service Pack 4, but was known as the Security Configuration Editor and could manage only a local computer.

In Win2K, this tool can be used to reduce administrative costs and ease the burden of maintaining security. Think about it. Security means constant vigilance. Most of the time, you’re too busy responding to new requests and fighting inaccurate or inadequate configuration to give maintenance the place it deserves. Besides which, don’t you like to think that once something’s put into place, it shouldn’t arbitrarily change? Get real. Things don’t arbitrarily change, but people change them. Maybe there was a temporary need to give a group special permission or access until a better solution could be found. Then life intervened, and no one remembered to reset it. Maybe corporate politics have placed you in the position of having to deal with immature or vindictive administrators. And what happens when there are 10 new servers to put into production without adequate time to apply a thorough security lockdown?

In Win2K, you can address these problems with the Security Configuration Tool Set, which has several pre-configured templates that can be modified to your specifications. You use Group Policy to apply security settings across an organizational unit (OU) or a domain. Want to make sure settings are maintained? Settings applied at this level override settings made at a lower level. Need to configure several new computers? No problem, since settings can be configured to propagate. Are auditors knocking at your door looking for a way to analyze your compliance with corporate security policy? No problem. You can easily ask for an analysis of current settings against any policy database.

Now the real kicker: Secedit is a command-line tool that you can use to run these programs in batch mode, or as a task while you sleep. Take two seconds to make sure the task is active, then view the results in the morning.

You’ll still have to do an analysis to determine what the settings should be for your systems and then put them into place. When first installed, the Windows 2000 default security settings (known as the local computer policy) are disappointingly weak. The default length of the password is zero characters, account lockout policy isn’t set, and no auditing is turned on. On the upside, some new user rights and security options give us more granularity in the interface to lock down the system. Study the available settings in the local policy, and make your own policy part of any installation in your site.

Checklist for Stiffening Default Win2K Settings
  1. _ Assign access control rights on a group basis.
  2. _ Rely on inheritance from group assignments.
  3. _ Apply rights to propagate through the container tree.
  4. _ Delegate container administration to administrators of the computers where the containers reside—that is, decentralize administrative operations and issues.
  5. _ Set Auditing On, and use the following:
    1. _ Failure audit for logon/logoff.
    2. _ Success audit for user and group management, security change policy, restart, shutdown, and system events.
    3. _ Success and failure audit for file access and object access for suspect users and sensitive files.
    4. _ Failure audit for printers that print sensitive documents like checks.
    5. _ Success and failure audit for write access for program files (.EXE and .DLL).
  6. _ Train users in the proper use of EFS. Have them encrypt their My Documents and temp folders. Encrypt folders rather than files.
  7. _ Use the Secedit command line tool for batch analysis when a large number of computers needs to be configured and analyzed.
  8. _ Use the Security Configuration Tool Set with Group Policy to implement security settings at the domain or site level, not at the local computer level.
  9. _ Create personal databases into which you import security templates for analysis.
  10. _ Test predefined templates before applying them to production systems.
  11. _ Make the size of the security event log large, and don’t allow event log wrapping. Archive frequently so as not to miss events.
  12. _ Track system services used on a computer, and set unnecessary or unused services to manual start.
  13. _ Enforce password history, remembering the last 12 passwords.
  14. _ Use a maximum password age of 42 days.
  15. _ Set minimum password age to 30 days.
  16. _ Set minimum password length to eight characters.
  17. _ Set “Passwords must meet complexity requirements.”
  18. _ Set “Store passwords using reversible encryption for all users in the domain.”
  19. _ Set Account lockout policy.
  20. _ After trust development, set additional restrictions for anonymous connections to a minimum of “Do not allow enumeration of SAM accounts and shares” and maximum of “No access without explicit anonymous permissions.”
  21. _ Enable “Automatically log off users when logon time expires.”
  22. _ Enable “Clear virtual memory pagefile when system shuts down.”
  23. _ Enable “Do not display last user name in logon screen.”
  24. _ Create a logon banner.
  25. _ Configure LAN manager authentication level: minimum =”Send LM &NTLM, use NTLMv2 session security if negotiated.”

Group Policy Editor

You use Group Policies in Win2K to define a user’s desktop, and the Group Policy Editor to create Group Policies. It’s similar to using the Systems Policy Editor in NT. However, Group Policies aren’t primarily applied to groups of users. Instead, they’re applied to affect Active Directory objects such as the Site, Domain, or Organization. That lets you use Group Policies to control such things as programs available to users; programs that appear on a desktop; application settings; Start menu options; restrictions to files, folders, and Registry keys; rights granted to users and groups; when and what scripts run; and account policy settings. Group Policy, then, provides a single place for configuring, analyzing, and maintaining security for a Win2K enterprise. Group Policy Settings override settings made at the local computer level.

When you install a Win2K system, it’s configured with default security settings. You can view them by accessing “Local Security Policy” from the Administrative Tools menu. This opens the “secpol” Microsoft Management Console (MMC) snap-in, which displays security settings for this machine. You can view settings on Account Policies, Local Policies (Audit policy, User Rights Assignments, and Security Options), Public Key Policies, and IP Security Policies. You can gain additional information by examining file and folder settings, and security on Registry keys. If you join the system to a domain that has a policy configured for it, the local security policy will propagate to this computer.

It’s important to note that “override” does not mean all settings at the lower level are overwritten. Settings not explicitly set in the Active Directory will take on the settings from the local computer policy. I’ll address this in more detail in an upcoming article.

IP Security

IPSec is an enterprise standard for secure communication over IP. It can be used to create a virtual private network (VPN) with branch offices or trusted business partners by tunneling across the Internet. It can also be used to secure network communications between two users, or between a user and an application interface. After it’s configured, IPSec acts like an upside-down firewall. Whereas a firewall filters external access to your internal network or individual computer, IPSec filters packets leaving your network or individual computer. You can establish conversations between computers or security gateways (routers, firewalls) with a high degree of granularity. A policy database records the settings, and every packet is reviewed before it leaves the system. If a filter is found, it’s applied. If there’s no filter, the packet is dropped.

Here’s how IPSec works:

  1. Fred Smith wants secure communication over the network with Peter Jones.
  2. Fred uses an IPSec-enabled application to send a message to Peter. (Note that most inter-process communication mechanisms will work with IPsec transparently to the application itself, so no special application is needed for this.)
  3. The driver on Fred’s computer checks the IP filter list (policy database) for an address or traffic-type match, and finds one.
  4. The driver starts security negotiations with Peter’s computer.
  5. The computers do a secret key exchange, create a secure connection, and create a session key. More security negotiations ensue to determine the correct level of security.
  6. Packets leaving Fred’s computer are signed by the IPSec driver (to maintain integrity), and may be encrypted for confidentiality if desired.
  7. When they arrive at Peter’s computer, they’re checked for integrity and decrypted if necessary.

Fred and Peter are unaware of, and do not participate in, any of this. The policy establishing this activity has been pre-configured for them. Any routers between their computers don’t have to be configured for IPSec. (However, if any of these routers are acting as a firewall, they need to be configured to allow IPSec traffic to pass through.)

IPSec comes with Windows 2000, but you’ll need to plan and configure an IPSec policy before it can be used. (This is typically done after installation, unless you create installation scripts to do it for you.) You don’t have to install the protocol since it’s part of the new TCP/IP stack, but it isn’t used unless you configure it—no simple trick.

Built-in Smart Card Integration Services

Smart cards are credit card-sized hardware devices that add an additional layer of security to Win2K systems. They provide additional support for software implementations used for logon, authentication, and secure email. Used as a part of a public key infrastructure (PKI), they can provide tamper-resistant storage for private keys and other pieces of personal information. Security-critical computations are isolated from other parts of the system. Credentials can be made portable. Win2K supports the Personal Computer/Smart Card specifications developed for the PC/SC Workgroup (www.pcscworkgroup.com). Based on ISO 7816 standards, these standards are compatible with the Europay, MasterCard, and VISA (EMV) specifications, and with the European telecommunications Global System for Mobile Communications (GSM) spec.

To use smart cards with Win2K, you must install a smart card reader device and use a vendor-supplied installation program.

Windows File Protection

Ever been to DLL hell? Sure you have—that’s where an application installs a newer version of a DLL when an existing app needs that older DLL to work. It’s an unintentional denial of service (DoS) attack. If it’s this easy to replace DLLs, what about the system DLLs? Yep, I can see you’ve been there, too. Win2K, however, has two new features that will help prevent DLL hell.

First, DLLs for applications designed for Win2K will all use side-by-side DLLs. This means vendors should be writing applications to allow the use of different copies of DLLs for their new versions of products instead of writing new versions of Windows DLLs. (For more information, refer to Microsoft’s list of Win2K application logo standards.

Second, Microsoft has implemented Windows File Protection (WFP) in Windows 2000. This means that all .SYS, .DLL, .EXE, and .OCX files, along with some fonts that are part of the system itself, can’t be replaced except through a special file replacement mechanism controlled by Microsoft. That means that vendor applications (or viruses, or Trojans, or malicious mavericks) won’t be able to replace system files. Ever. When the system detects an application trying to change a system file, Win2K will change it right back. The only (supported) way to replace system files will be using Microsoft service packs and hot fixes. This makes for a more stable OS, and one that is less vulnerable to this type of attack.

Virus protection programs need to be aware of this function, as well as any backup or restore applications.

Built-in Public Key Infrastructure

Win2K provides the pieces to establish a Public Key Infrastructure, but you’ll have to configure them yourself. Why would you want to?

Perhaps it’s overkill to obsess about the dangers posed by internal users of your networked systems, but what about that Internet access you give them? Do you have trading partners that you work with? What will prevent unauthorized access to monitoring or altering email, electronic commerce transactions, and file transfers? Do you supply your users with multiple passwords because they must access multiple systems? Perhaps you can’t implement single sign-on in your networks just yet. But in the multiple-password world, be aware that users typically choose less secure passwords because they’re easier to remember.

As a systems administrator, network administrator, manager, auditor, or concerned user, how can you be sure of the identity of anyone accessing your systems? Can you be sure you’re controlling what information they have access to? How can identification credentials (user ID, password, etc.) be securely distributed across an organization and with trading partners? Kerberos will solve some of these issues, such as authentication, but you might also need a public key infrastructure. This so-called PKI feature is a major security enhancement in Win2K.

A public key infrastructure (PKI) includes digital certificates, certificate authorities (CAs), and other components that authenticate and verify legitimate access using public key cryptography. (See my column on cryptography, “Keeping Your Secrets Secret,” in the October 1999 issue for more information.)

In a public key infrastructure, you issue certificates rather than passwords. Certificates bind a public key to the identity of a person who holds the corresponding private key. With Win2K, you can take advantage of Certificate Services integration with the Active Directory and Group policy.

Data and files can be securely exchanged over public networks such as the Internet. Secure email can be implemented with Secure Multipurpose Internet Mail Extensions (S/MIME), and secure Web connections can be made using Transport Layer Security (TLS). Non-repudiation can be established whereby the author of digitally-signed data can’t deny being the author, whether it’s the person placing the e-commerce order or the merchant receiving the information for that online order.

Win2K uses a standard X.509v3 digital certificate. Certificate Services are used to create and manage Certificate Authorities, which are responsible for establishing and verifying the identity of certificate holders. The CA also revokes certificates and publishes a certification revocation list (CRL). Win2K also sets up Web enrollment pages when a CA is created. These Web pages allow certificate requestors to submit certificate requests via a Web browser. Certificates can be used for authentication and authorization and are used with smart cards and to identify recovery agents in the encrypting file system (see “Understanding the Encrypting File System”).

You can find additional information on Certificate Services at www.microsoft.com/security and www.microsoft.com/windows2000/
library/technologies/security/default.asp.

Miscellaneous Security Features

Along with the biggies like Kerberos, PKI, and Group Policy Editor are a host of smaller security features, many of which are installed right out of the box. Here’s a sampling of what you’ll get.

Unprivileged User Account Privileges Reduced

Applications that install or require user accounts to run a service will no longer have the same rights as the regular user accounts you and I log on with. These service accounts, called unprivileged user accounts, will have fewer privileges on the system than user accounts. Thus, while they can be used by the service, it will be harder to use them to attack the system. For example, this type of account can’t write to any part of the systems directory. If service accounts are given additional rights, or are members of groups other than Users, these rights aren’t affected.

No More NetBIOS!

Well, almost. The default configuration for Win2K will include NetBIOS, but unlike NT, it will be possible to set up your system so that NetBIOS isn’t loaded or present. Hurrah! You’ve just eliminated the source for many attacks and scans on your system information. Applications that try to use NetBIOS on a system where it’s no longer present will return errors.

Write-Protected Kernel Mode

Many existing device drivers are written improperly for NT. They override the protections on write-protected regions of memory and can cause NT to crash. To respect these areas of memory, drivers written specifically for Win2K will be required. Device drivers that are correctly written can be certified; their code will be signed by Microsoft and provided through Microsoft channels. You can configure Windows 2000 to accept only signed device drivers, to warn you that an unsigned driver is trying to load, or to accept any device driver. Any OEM device driver provided by Microsoft will be an approved driver, for example. Configure your policy to accept only signed drivers, and you can help protect your system from corruption.

Understanding the Encrypting File System
The ease with which you can use EFS during installation belies its usefulness. Simply right-click on the file or folder that you want to encrypt and click Properties. From the General tab, click Advanced, then select the “Encrypt contents to secure data” check box. Presto! Now your data’s secure! This new feature of NTFS v5 allows encryption of files and folders. Encrypt at the folder level to encrypt all folders in the file and to ensure all new files added to the folder are encrypted. Encrypt the Temp folder if using programs that add temporary files. No files are encrypted by default, but the feature is. By the way, it isn’t necessary for users to apply passwords separately to files. And use of the system is transparent to the user.

Proper use of the encrypting file system can keep files safe, but there are some rules to learn:

  1. Files can become unencrypted if copied or moved to FAT volumes.
  2. Files created in encrypted folders will be encrypted automatically.
  3. Use Edit/Copy and Edit/Paste to retain encryption when moving encrypted files into encrypted folders. Don’t use drag-and-drop, as files aren’t automatically encrypted that way.
  4. Compressed files can’t be encrypted.
  5. Users can’t share encrypted files.
  6. Encryption doesn’t protect against deletion. If users have the right to delete files in a folder, they can delete files encrypted by other users.
  7. Temporary files created by applications will be encrypted only if they’re created in an encrypted folder. To maintain encryption, encrypt the Temp file folder.
  8. Users can encrypt or decrypt folders and files on a remote computer if it has been configured for remote encryption.
  9. Data transferred over the network isn’t encrypted during the transfer—you must use an encryption protocol, such as SSL/PCT or IPSec.

Tighter Default File and Program Access

A clean installation of the new OS onto an NTFS partition creates file system permissions designed to prevent users from compromising the integrity of the operating system and installed applications. Users can’t modify settings on operating system files or program files, and can only install applications that can be run by themselves (if they’re provided access to the file system) and not by other users. Win2K Professional “Power Users” may install applications for use by others (this eliminates the need for an administrator to do so, or for us to give users administrative privileges on a machine just for this purpose.) A Power User’s default settings are backward-compatible with NT 4.0 user settings. Power Users can install any application that doesn’t install system services.

Super-Hidden Files

Some files will be marked with System and Hidden attributes and won’t be visible in Windows Explorer even if the option “Show Hidden Files” is checked. These files can, of course, be used, and an attribute on the folder can be checked to make them visible—but it must be checked on every folder that might have hidden files in it. This feature should be useful in keeping users away from certain system files.

And Now, for Our Next Act...

Win2K ships with a variety of security services. Although I’ve outlined some suggestions, you’ll still need to make choices about which ones to implement in your enterprise. I’m afraid you’ll still have to work hard to establish security in your Win2K enterprise. Remember, if you don’t know what you need to secure, or how tightly, all these new gee-gaws don’t mean much. Yes, Virginia, you still need to design a security structure, then put Win2K security services to work for you. The beauty is this: It’s now the design that’s difficult, not the implementation, maintenance, or control.

comments powered by Disqus
Most   Popular