Windows 2000 makes it easy to keep track of events that happen on your network. These include file and folder access and modification, password changes, and logon sessions, just to name a few. The automatic recording of information about the events that happen on your network is called auditing . The file that stores this information is called a log.
How many times a day do you open, close, or save a file? How many times do you log in to or out of a system? Have you changed your password or moved a folder lately? Multiply these numbers by the number of people who have access to your network, and you begin to see that the amount of information that can be stored in log files can be enormous.
You have to decide what really needs to be audited. It’s very easy to tell Windows 2000 to keep track of an event, so you may be tempted to just track everything. That way if something goes wrong, you can search the log files for evidence of what happened. Many security-conscious system administrators take this approach, but you have to balance that with the actual benefits and the workload it will add.
If you’ve never set up auditing or dealt with log files before, the process can seem a bit overwhelming. The trick to designing a good audit system is to make a plan ahead of time, implement it, and, most importantly, use it. It is useless to tell Windows 2000 to monitor all failed and successful login attempts if you aren’t going to check the logs for suspicious activity.
Windows 2000 comes with nine built-in audit policies that can track the success, failure, or both for different types of events. The more of these policies you implement, the greater the disk space, RAM, and CPU usage you take away from the rest of the system. You should create a baseline of server performance before turning auditing on and check it after each policy you implement. If performance is suffering significantly, you should add a dedicated machine or load balance across multiple machines.
Most of the information you store through auditing is stored in the security log and can be viewed using the event viewer. Be sure to look at each type of log file to see if the information is both legible and useful to you. Otherwise, you may want to adjust the audit policies to optimize the log files. Table 33-3 shows the nine built in audit policies and the type of event they can track.
Table 33-3. Built-in Audit Policies
|
Policy Name |
Events Tracked |
|---|---|
|
Audit account logon events |
Success and failure |
|
Audit account management |
Success |
|
Audit directory service access |
Success and failure |
|
Audit logon events |
Success and failure |
|
Audit object access |
Success and failure |
|
Audit policy changes |
Not defined |
|
Audit privilege use |
Not defined |
|
Audit process tracking |
Not defined |
|
Audit system events |
Success and failure |
In addition to providing built-in audit policies, Windows 2000 has several security templates that can get you started on deciding which events should be tracked. When you first install Windows 2000, the basic security template is applied. The basic security template is simply the default security settings that come with Windows 2000.
If you need to add to that security, there are two incremental templates to help you, secure and highly secure. The secure template mainly applies to local files and folders; the highly secure policy also applies to network communication. A highly secure template requires IPSec to be used.
Two other templates are part of the incremental template set, compatible and dedicated domain controller . Compatible allows non-Windows 2000 certified applications to be run with minimal security risk. Dedicated domain controller applies to local security on a domain controller. These templates are available when the Security Configuration and Analysis Tool snap-in is installed.
Following is a list of the types of events you might want to audit and a description of why auditing them can be helpful in maintaining a secure network environment:
- Logon and logoff
Password guessing is one of the oldest and simplest ways to try to gain unauthorized access to networked computers. Keeping close track of the who, when, and where of all successful and unsuccessful logon attempts is a great place to start.
- Account changes
You can keep track of the addition, deletion, or modification of accounts. Pay special attention to all new accounts to make sure permissions are set properly and that the new account is associated with only one authorized user. Monitoring logon/logoff patterns of new accounts to get a baseline of their activity will help you spot anomalies later on.
- Policy changes
In addition to manually setting security for objects, policies (especially Group Policies) can have wide-ranging effects on security settings. If a new policy changes security settings, that change will be noted.
- Active Directory
Files, folders, and just about every object in a Windows 2000 environment are stored in the Active Directory (AD). Changes to the AD structure also can have wide-ranging effects due to the built-in inheritance structure.
- Access to objects
Almost everything in Windows 2000 is an object. Objects have attributes. You can monitor any modifications to these attributes, which include permissions and ownership. You can also monitor how the objects are used, such as whether a folder was opened or whether its contents have been changed.
- System events
You can keep track of when a computer was turned on and off or rebooted and other events having to do with the system itself, rather than any particular files, folders, or users.
Once you’ve decided what to audit and you actually start generating log files, you have to schedule and plan what you are going to monitor and how often you’re going to monitor it. You’ll also need to determine how far back you want the log files to go. Luckily, log files can pretty much maintain themselves by periodically eliminating older events.
The most important thing to remember about auditing is that it is useless to generate log files if you aren’t going to look at them. There is quite a bit of overhead to this monitoring, so choose the events you want to track wisely.