7. Manage Group Policy with GPresult
Win2K's Group Policy feature lets you manage system and user-profile configuration from a central point. But diagnosing exactly how Win2K is applying Group Policy to a given system or user can be tricky. Your system's configuration might be the result of many Group Policy Objects (GPOs) defined at the local system, site, domain, and organizational unit (OU) level. (For more information about Group Policy, see "Controlling Group Policy, Part 1," November 2000, and "Controlling Group Policy, Part 2," Winter 2000.)
GPresult, a command-line utility that installs as part of the resource kit's Network Management Tools component, helps you solve this diagnosis problem. GPresult's reports are too long to include here, but the tool provides a wealth of diagnostic information about how Win2K has applied Group Policy to the current computer or user. GPresult reports the Win2K version you're running (e.g., Win2K Professional, Win2K Server), group membership, privileges, date and time of the most recent application of Group Policy, which DC provided the GPOs, and most important, which GPOs Win2K applied from AD.
6. Scan for Vulnerabilities with System Scanner
I was excited about the resource kit's inclusion of CLA, but I was amazed to find that Internet Security Systems' (ISS's) System Scanner 1.1 was also included. ISS is one of the leading producers of security scanners, and System Scanner is a host-based vulnerability tool, as well as a policy-based assessment tool. Version 1.1 is admittedly several steps back from the current version 4.0, but it still excels at tackling the known vulnerabilities of workstations and servers exposed to the Internet. More important, System Scanner offers several policy and baseline checks that ISS originally designed for Windows NT but that apply equally well to Win2K.
To protect workstations, System Scanner checks for Internet browser vulnerabilities, ensures the correct configuration of virus protection, and watches for dangerous Microsoft Office settings. For Web servers, System Scanner checks for known Microsoft IIS-related exploits such as 8.3 filenames, server-side includes, and indexed ASP pages. System Scanner also checks for subtle risks. For example, when I ran the tool on a lab system, it warned, "Microsoft Office is installed on Web server." The message explained further, "A dedicated production web server should not have Office installed. Office exposes a large number of DCOM objects which can be used with scripting languages and may enable an attacker to subvert the web server." System Scanner checks for arcane NT vulnerabilities such as weak permissions on the registry's Winlogon and Run keys. You can also assess policy settings such as password, account lockout, and auditing.
My favorite System Scanner feature is its baseline capability, which lets you catch system modifications. System Scanner takes a snapshot, or baseline, of your system configuration. Upon subsequent scans, the tool compares the current system configuration with the snapshot and reports any changes. You can reset the baselines at any time, so you can take legitimate changes into account.
To track registry-value data, registry-key audit settings, ownership, and permissions, you can create registry baselines. To track changes to file content, and to audit settings, attributes, ownership, and permissions, you can create file-system baselines. (Figure 3 shows a custom scan policy for catching changes to content and permissions.) To identify new, unauthorized services and suspicious processes, you can create service and process baselines. Process baselines also let you track which programs and commands run at system startup and logon. You can create user baselines to monitor group membership, user-logon settings, RAS user settings, and rights assignments. You can even create share baselines to catch new shared directories or changes to share permissions.
To use System Scanner, run setup.exe from the resource kit CD-ROM's \appssystemscanner directory. Next, open System Scanner, and select File, Scan Now. Select an appropriate policy, and click OK. (Policies define which of the aforementioned checks you want to perform according to the type of system you're scanning.) System Scanner lists the vulnerabilities that it finds, as Figure 4 shows. When the scan has completed, the tool saves all findings to a scan history database, from which you can run reports that analyze scan results over time. You can run a simple Vulnerabilities Report that lists each vulnerability that System Scanner finds during one scan. Each Vulnerability Report includes an explanation of risk and instructions for fixing the problem. You can also run a Services Report, which identifies well-known Internet services that were open on your system during a scan. To quantify your progress in securing a system, you can run a Trends Report, which lets you compare the vulnerabilities that System Scanner finds in two or more selected scans. With the Differential Report, you can compare two scans and view vulnerabilities in the first scan, in the second scan, or common to both scans.
System Scanner is an impressive tool for scanning Win2K and NT systems. However, ISS clearly didn't write version 1.1 specifically for Win2K, and a few minor problems result. System Scanner doesn't check for all the open TCP/IP ports common to a Win2K DC, such as Common Internet File System (CIFS). However, you can use a custom policy to define additional ports to scan. System Scanner 1.1 also doesn't recognize all the base installation services (e.g., Kerberos, DFS) common to Win2K systems, and Microsoft has renamed some services between NT and Win2K. Therefore, the resource kit's version of System Scanner generates more "unknown service" vulnerabilities than it should. If you can't afford System Scanner 4.0, the resource kit's version will nevertheless prove very useful—and it won't cost you a dime.
5. Secure IIS Web Servers with Security Templates
The resource kit offers two new security templates for securing intranet and Internet Web servers when you use the Security Configuration and Analysis Tool. The Security Configuration and Analysis Tool is an exciting tool that lets you define nearly every aspect of a Win2K system's security configuration in an .inf template file. Using the MMC Security Templates snap-in, you can create different templates for each type of system, from workstations to servers. You can then apply a template to a system and secure it in one step. (This capability also helps to ensure standardization among multiple Web servers' security implementations.) For more information about the Security Configuration and Analysis Tool, see Mark Joseph Edwards, "Service Pack 4's New Security Configuration Editor," October 1998.
Win2K comes with predefined templates for different types of workstations, member servers, and DCs—and variants of each—for different levels of security. However, Microsoft hasn't tailored any templates to Web servers.
The resource kit introduces secure-intranetwebserver.inf and secureinternet-webserver.inf for both types of Web servers. Although I was initially excited to discover these templates, that enthusiasm was somewhat diminished when I investigated exactly which policies each template specifies. Unfortunately, the templates do little more than set arbitrary password and audit policies, secure some files under system32, and change a few rights assignments. These templates perform little if any hardening, or locking down, specific to Web servers (e.g., disabling services, restricting browsing users from accessing the Server service). According to the documentation, Microsoft has provided these templates as a useful starting point, which you must use your own knowledge of securing IIS to build on.
4. Audit IIS Web Servers with MetaEdit
When you need to audit an IIS Web server and ensure that authentication and access-control options are correctly configured throughout the Web site, you're in for a daunting task. In IIS, you can use Internet Service Manager (ISM) to configure security settings for each directory and file on your Web server. Security settings in IIS automatically flow down from parent directories to child files and directories, so you'll naturally start to check settings at the top. However, short of opening each object's Properties window, how can you determine whether you've accidentally weakened settings on files and directories below?
IIS configuration information resides in a database called the metabase. IIS arranges the metabase into keys and values. Each directory in your Web site has a corresponding key in the metabase. Each IIS property for that directory, including authentication and access control, has a corresponding value in that key. The metabase is similar to the registry but has one important difference: If you define a value in the metabase, that value automatically flows down to child folders—which is why IIS works the way it does.
Metabase Editor (MetaEdit), which comes with the resource kit's Internet Information Server Tools component, can help you speed up security checks on your IIS server. MetaEdit lets you quickly browse your Web site's configuration by navigating from one directory to another. After you learn the corresponding metabase value names of settings in ISM's Properties window, you can use MetaEdit to quickly traverse a branch of the directory tree and ensure that security is configured consistently throughout.
To test MetaEdit, first install the utility by running setup.exe from the resource kit CD-ROM's \apps\metaedit directory. Next, open MetaEdit. Web sites reside in the IIS metabase under \LM\W3SVC. Each Web site is contained in a subkey and identified by a number. For example, the settings for Default Web Site reside under \LM\W3SVC\1. To identify a Web site, look at the ServerComment value. Figure 5 shows that value for Default Web Site.
An important security setting for each Web directory is AccessFlags. This DWORD value represents preferences determined by check boxes on the Virtual Directory tab of a Web directory's Properties window, which Figure 6 shows. Access flags determine how browsers access the Web directory.
Another important value is AuthFlags, which corresponds to authentication methods for a Web directory. AuthFlags isn't a magic wand for auditing your IIS server, but if you learn your values and value names, you can check Web directory properties much faster than you can in ISM.
3. Restrict Concurrent Logons with Cconnect
Novell NetWare administrators often complain that neither Win2K nor NT has a concurrent logon restriction to prevent a user from logging on to more than one workstation simultaneously. In NT, you can limit a user to a specific workstation by defining a workstation restriction on the user account's properties in User Manager for Domains, but this workaround needlessly limits the user to a specific workstation instead of limiting the number of concurrent logons.
The resource kit's Concurrent Connection Limiter (Cconnect) utility lets you limit concurrent logons in Win2K and NT networks. Cconnect contains two components: Cconnect Administrator lets you view current logons across your entire domain and forcibly log off users when necessary, and Cconnect Client runs on each workstation and enforces the concurrent logon restriction. You must install Cconnect Client on each workstation. When a user logs on to a workstation, Cconnect Client counts the number of currently active logons for that user in a Microsoft SQL Server database, then compares that number to the maximum number you've allowed for that user. If the user has exceeded the limit, Cconnect immediately logs the user off.
To use Cconnect, you first set up a new database and user account on an SQL Server machine. Then, to centrally manage all the instances of Cconnect Client, you need to import some new Win2K Group Policies or NT system policies. The policies, which reside in the cconnect.adm file, define registry values under the HKEY_CURRENT_
USER\Software\Microsoft\Cconnect subkey. These registry values point Cconnect Client to the correct SQL Server database and define the user's concurrent logon limit. (Figure 7 shows these policies imported into System Policy Editor—SPE.) After you import the cconnect.adm file, you can configure Cconnect's policy and SQL Server connection data. Next, to install Cconnect Client on each workstation, run setup.exe from the \apps \cconnect\client directory. To install Cconnect Administrator, run setup.exe from the \apps\cconnect\administrator directory. The first time Cconnect Client or Cconnect Administrator runs within your network, it builds the necessary tables in the SQL Server database you created.
If the only Cconnect function you require is concurrent logon restrictions and you're running Win2K on the desktop as well as on the DC, you don't need to install Cconnect Client. Instead, you can modify your user's logon and logoff scripts to call cconnect.vbs and cclogoff.vbs, respectively. If you define your logon scripts in Group Policy under User Configuration, Windows Settings, Scripts, you can deploy Cconnect throughout your domain without ever touching a workstation.
Register
