Security monitoring and auditing should be implemented on your cluster members in such a fashion that intrusion attempts are detected and notifications are sent out in a timely manner, thus enabling you to respond quickly to threats. Windows 2000 provides several tools that you can use for security monitoring and auditing.
Performance Monitor
You can use selected Performance Monitor counters as a means to flag possible hacking attempts on a server and implement real-time monitoring and detection. By using counters and a threshold that you establish, you can trigger an alert when the threshold is exceeded. You can also specify the following actions to take when an alert is triggered:
A good example of using performance counters and alerts is the counter for logon failures. Figure 12.5 shows the custom alert we created for monitoring failed system logons. In this example, we use the Errors Logon counter for the Server performance object. When the number of failed logons passes the threshold (25), an alert will be triggered.
Figure 12.5 Using Performance Monitor to set up security alerts
Obviously it's not feasible to monitor all the objects in the operating system. Table 12.8 lists the objects that we think you should monitor and generate alerts for.
Table 12.8 Alert Recommendations
Counter | Description |
---|---|
Errors Access Permissions | Indicates whether somebody is randomly attempting to gain access to files in the hopes of finding an improperly protected file. |
Errors Granted Access | Logs attempts to gain access to files without proper access authorization. |
Errors Logon | Display failed logon attempts, which could mean that password-guessing programs are being used to crack security on the server. |
Auditing and the Event Viewer
The Windows 2000 Event Viewer, which consists of the System, Application, and Security logs, records information for all the events that are audited on the computer. You can use the Security Log, which records errors, warnings, or information generated by the operating system, in the Event Viewer to review audited events. This log contains default events, such as logons and logoffs, as well as any others that you want to audit.
System auditing is established at the domain level and can be extended by applying policies on the local computer by using the Local Security Settings option (in Windows 2000, click the Start button, point to Programs, and then click Administrative Tools). Remember, domain security policies always take precedence over local policies when the local policy is weaker than the domain policy.
The audit policies that you can apply at either the domain or local level include:
You should monitor the Windows 2000 Event Log on a regular basis to see if any of the Security Log entries listed in Table 12.9 appear because they could indicate an intrusion or attempted intrusion.
Table 12.9 Security Log Entries That You Should Monitor
Event identifier | Comments |
---|---|
612 | The audit policy has changed. Verify who changed it and why. |
640 | A change was made to the SAM database. Was it you? |
531 | An attempt was made to log on by using a disabled account. Who would attempt this and why? |
539 | A log-on attempt was made and rejected because the account was locked out. Who would attempt this and why? |
529 | An attempt was made to log on by using an unknown user account or by using a valid account with a password that is not valid. An unexpected increase in the frequency of this event could indicate an attempt to guess passwords. |
517 | The Audit Log was cleared. Did you do this, or is it an attempt by an intruder to cover his tracks? |
624 | A user account was created. Did you or a trusted person create it? |
628 | A user account's password was set. Did you or a trusted person do this? |
Remember, the logs that record the events you're auditing are an important part of this process. Make sure that these logs cannot be deleted or corrupted by setting the appropriate level of security access on them. The files that you need to protect are:
Using crash logging and notification as a security tool
Because hackers will attempt to crash a server in order to gain access, it's useful to receive and retain crash information. In addition to the crash log file, you can also enable two other methods of crash notification and logging.First, you can enable an administrative alert by setting HKEY_LOCAL_MACHINE/SYSTEM/CurrentControl/SetCrashControlSendAlert to 1. The next time the server crashes, an administrative alert will be sent.
Second, you can make the operating system log the crash in the Event Log by changing HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/CrashControlLogEvent to 1. Now the exact time of the crash will be permanently recorded.
You can use this information during a security audit to determine whether or not the server was deliberately crashed.