Windows XP is the first release of a new generation of Microsoft OSs that combine the strength and security of Windows 2000 and Windows NT with the flexibility and ease of use of Windows Me and Windows 98. To further enhance XP's security and ease of use, Microsoft has beefed up several familiar GUI and command-line tools and added some new ones. Microsoft has chosen not to ship utilities with the Microsoft Windows XP Resource Kit. Instead, the company has moved the more useful utilities from the Microsoft Windows 2000 Resource Kit and the Microsoft Windows NT Resource Kit into the base XP OS and into the Support Tools folder on the installation CD-ROM. If you've rolled out XP in your organization or you plan to do so, these tools will help you monitor, manage, and secure your XP installations.
Gathering System Information
The first step in securing your organization's XP systems is to determine their configuration. In the past, administrators had to visit each system and run a battery of utilities to discover which OS, service packs, and hotfixes were installed and to determine the network configuration. XP simplifies this task with the introduction of the Systeminfo command-line tool (systeminfo.exe). Systeminfo enumerates system configuration information by using the Windows Management Instrumentation (WMI) API and formats the results into OS, hardware platform, installation configuration, and installed hotfix sections. You can use the tool's /s (system) switch to run Systeminfo against remote systems; you can also use the tool's /u (username) and /p (password) switches to specify the security context under which to run the command. If you supply a username but no password, the system prompts you to enter a password—a prompt that's especially useful when you need to run the command interactively with others watching. (The password isn't echoed as you type it.)
Another useful utility for determining a system's configuration is the Spcheck tool (spcheck.exe), which is included in XP's Support Tools. (Previously, this utility was available only from Microsoft Product Support Services—PSS.) Although Spcheck's output can be cryptic, it's helpful when you want to make sure that key XP networking components such as drivers, DLLs, and the command-line tools you use to monitor networking components are up-to-date. Spcheck uses a data file called spcheck.ini, which contains information about the individual files in each networking component. Spcheck.ini doesn't come with XP; you must obtain the latest version from Microsoft's Web site. The Microsoft article "How to Use the SPCheck Tool to Determine the Service Pack Level of Components" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q279631) contains a link to the data file for XP, Win2K, NT 4.0, and Microsoft Exchange Server 5.5 as well as instructions for using Spcheck. The Microsoft article "How to Use the SPCheck Tool in Windows XP" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q312646) contains more information about using this handy utility with XP.
Monitoring Your Systems
I'm amazed by the number of people and organizations who don't proactively monitor their systems and networks, giving intruders free reign to attempt to circumvent security without anyone knowing. Routine monitoring is useful not only for thwarting intruders but also for discovering potential configuration problems that might cause difficulties for users.
When you monitor running processes on your system, you probably use Task Manager. If, however, you want to determine which processes have started subprocesses or which processes services are running, you probably use the tlist.exe command-line utility. Unfortunately, this useful tool isn't available in XP, so you need to use the Tasklist tool (tasklist.exe) instead. Tasklist, which developers created for XP's multiuser environment, reports session information about each running process. However, unlike tlist.exe, Tasklist doesn't list subprocesses under their parent process. (I hope Microsoft will reintroduce this useful feature in a future version.) You can use Tasklist to query remote systems and use the /v switch to get a verbose listing of useful information such as Windows Titles and usernames. As Figure 1 shows, you can use the tool's /m switch to display processes that have loaded a particular DLL—a particularly useful ability when you suspect that a DLL is actually a Trojan horse.
I often see a lot of network activity on my firewall/router. With earlier versions of Windows systems, I use the Netstat utility (netstat.exe) to show me which TCP or UDP endpoints are in use on my system, then I work out in my head which process or processes are likely to be sending and receiving data. If I want to accurately correlate endpoints to processes, however, I need to use third-party tools. XP's updated Netstat tool has a new feature that lets me see which processes are using endpoints. When you use the /o switch, Netstat shows the process identifier (PID) next to the endpoint information, as Figure 2 shows. When you use the tool with the /a switch, you can see all endpoints, whether active or listening.
I also like to monitor the files that each process has open. In previous versions of Windows, you can install and use the resource kit's oh.exe utility. Although the XP Support Tools' Help file documents oh.exe, the Support Tools installation doesn't include the tool. You can, however, use the new Openfiles command-line tool (openfiles.exe), which lets you view files that processes have open. Like oh.exe, Openfiles requires you to turn on monitoring in the kernel, which will consume more memory and might degrade performance on systems such as file, print, email, and database servers. To turn on monitoring, go to a command prompt and type
openfiles /local on
This command creates the global flag "Maintain a list of objects for each type" in the registry. (You can view what flags are set in the registry or in a running kernel by using gflags.exe.) Reboot the system to activate the flag. Then, to view a list of processes and the files they have open, go to a command prompt and type
openfiles
To see which user is running the processes that have the open files, type
openfiles /query /v
Other command options let you control how the tool displays the information. You can also use Openfiles to monitor open files on remote systems that have monitoring enabled.
Users of Win2K Server Terminal Services or NT Server 4.0, Terminal Server Edition might be familiar with the Query command-line utility (query.exe). XP includes a form of Terminal Services but doesn't include Query. However, you can use other commands to get similar information (query.exe just invokes these commands, anyway). For example, to display a list of logged-on users on an XP system, use the Qwinsta command-line tool (qwinsta.exe), as Figure 3 shows. You can also use Qwinsta with the /server:servername switch and argument to query users on remote systems running Terminal Services or XP. To see a list of processes each logged-on user is running, you can run the Qprocess command-line tool (qprocess.exe). As with the Qwinsta command, you can also use Qprocess to query a remote system for processes belonging to users.
The event log is one of the most difficult areas of a Windows system to monitor. Servers running many applications or systems with security auditing enabled can generate megabytes of auditing information. Searching the information for a specific event can be difficult and time-consuming. XP's new Eventtriggers tool (eventtriggers.exe) lets you execute commands in response to events in any of the event logs. For example, to invoke the command script C:\Admin\FailLogn.cmd whenever someone fails to authenticate with the system, you can use the following command:
eventtriggers /create /l security /eid 529 /tr "catch failed logon" /tk c:\admin\faillogn.cmd /ru:administrator
The script runs under the security context of the Local System Administrator. The system will prompt you to enter the password of the user you specify through the /ru switch. If you don't specify a user context, the system uses the Local System context instead. Using Local System can lead to problems with certain commands that require a valid security context, so I suggest you use a real account. I've found that the lag between an event occurring and the trigger firing can be as much as 60 seconds. As with many of the new XP tools, you can apply the command to remote XP systems. You can also combine this command with eventcreate.exe to build triggers that fire in response to specified events.
Monitoring Your Network
If you've ever tried to troubleshoot communications problems between a client machine and a server, you've probably used the Network Monitor utility (netmon.exe), which is included in Microsoft's server OSs. XP has a command-line utility called Netcap (netcap.exe), which is installed with the XP Support Tools. As with Network Monitor, you can use Netcap to capture network traffic. The first time you run the utility, you see a message informing you that the network driver is being installed. Netcap can read filter files created by Network Monitor 2.0 or later, and Network Monitor can read the capture that Netcap produces.
Administrators who use IP Security (IPSec) on their networks might be surprised to find that Ipsecmon (ipsecmon.exe), a useful utility for monitoring IPSec associations, doesn't ship with XP. The good news is that Microsoft has replaced Ipsecmon with a Microsoft Management Console (MMC) snap-in called IP Security Monitor, which provides enhanced monitoring of both local and remote XP systems. To access the snap-in, run mmc.exe and select File, Add/Remove Snap-in. Click Add to open the Add Standalone Snap-in dialog box. Select IP Security Monitor from the list of snap-ins, then click Add. Click OK in the Add/Remove Snap-in dialog box to return to the MMC console. When you expand Local Machine, you see two nodes: Main Mode and Quick Mode. These modes correspond to Phase I and Phase II of the IPSec negotiation process. Expand the Quick Mode node, then expand the Security Associations node to see a list of established Phase II security associations (SAs), as Figure 4 shows. You can double-click an SA to get more information about it. The other nodes contain details about the filters and policies that control the SA. You can right-click the Machine node and select Statistics to see an overview of the IPSec state on that system, as Figure 5 shows.
Managing Your System
You're probably responsible for managing, as well as monitoring, your organization's systems. As with monitoring tools, Microsoft has expanded and added to the range of management tools available in XP.
In earlier Windows versions, you could use the Support Tools kill.exe utility to end a process. Microsoft replaced kill.exe with taskkill.exe and added the ability to kill processes on remote systems, to kill processes by name or window title, to kill subprocesses, and to kill processes that match a set of conditions including status, memory, CPU usage, loaded DLLs, username, and service name.
The ability to disconnect users connected to shares and close the files that they had open has been present in Windows since NT 3.1. With XP, you can now instruct the OS to close files that a remote or local user opens. To close files, use the openfiles.exe command-line utility with the /disconnect switch. As with tasklist.exe, you can specify conditions such as username, filename, and open mode. You can also use the command to close files on a remote system if you have administrative rights on the system.
If you need to log off a user on an XP system, you can use the Logoff command-line utility (logoff.exe). Although earlier Windows versions include a version of this utility, that version lets you log off only users who are connected remotely to a server. The XP version of the tool lets you log off a console user.
The security tools I describe in this article provide you with some long-needed features. Microsoft doesn't provide utilities with the XP resource kit, but the company does support the utilities that now ship with XP. This support is a welcome change for many administrators who were frustrated when the resource kit tools didn't work as described. If you were one of the administrators who used some of the more obscure resource kit tools, you'll need to do some research to find suitable alternatives. Most administrators, however, won't miss the old tools.
