Lesson 2: Event Monitoring in the Private Network | MCSA/MCSE Self-Paced Training Kit (Exam 70-214): Implementing and Administering Security in a Microsoft Windows 2000 Network (Pro-Certification)

Lesson 2: Event Monitoring in the Private Network

Security breaches are just as likely to come from users with valid credentials as they are to come from hackers, but the effects of security breaches by insiders can be far more serious. Users have wide access to the network and they know exactly where valuable information is stored.

Because insider security breaches can be so serious, you must preserve the event logs, which document these breaches. This lesson shows you how to preserve event logs as evidence in case of a serious breach of security by internal users. It also shows you how to search through event logs across your network for security breaches. To complete this lesson, you need a domain controller for the domain.fabrikam.com domain.

Be certain you understand how to detect internal security violations and how to preserve evidence when security events occur.

After this lesson, you will be able to

Manage event log retention to preserve evidence
Configure auditing to detect internal security breaches
Search for security events across a number of servers simultaneously

Estimated lesson time: 30 minutes

Establishing Intrusion Detection in Private Networks

Intrusion detection in private networks is performed through strong auditing. By enabling auditing for files and objects that are critical to security, you can track exactly which users have accessed sensitive objects and in what manner.

The major difference between anonymous hacking from the Internet and abuse by valid users is that you can easily determine the identity of valid users and hold them legally accountable for their behavior.

Intrusion detection in production private computers is simpler but less effective than intrusion detection in public sites. Internal users won't be fooled by decoys they know the network architecture. They also have no need for the signature attacks like port scanners used by hackers, because they know exactly where servers are and what they service. In Chapter 3, "Restricting Accounts, Users, and Groups," you learned how Windows 2000 provides strong support for interior intrusion detection through object access auditing. In this lesson, you learn to use an additional tool logging to detect intrusions by valid users.

Detecting Attack

You probably examine the system and application logs on your servers routinely, looking for evidence of services that are malfunctioning or improperly configured. It's a simple process you scan through the log looking for red-flagged events, read them, research the cause, and fix them or determine that they're not important.

Examining audit logs is fundamentally different. Success and failure notices both routinely appear for a variety of reasons a mistyped user name is not an indication of hacking, nor is a document that a user is denied access to once. Isolated security events are routine and not cause for serious examination.

When you examine audit logs, look for patterns rather than isolated incidents. A few mistyped passwords for a single user account don't indicate an attack, but a single mistyped password for a number of accounts does, and so do a number of mistyped passwords for a single account. Certain user accounts are also immediate indicators of attack for example, even a few failed attempts to log on using administrative accounts are indicative of attack.

When you look at audit logs, look for long chains of failure operations. Automated brute-force password attacks appear as long chains of logon failures in audit logs. Be especially vigilant about examining the account logon audit logs of machines in your perimeter network, because these machines are highly likely to be attacked in this manner. Remember to look at the success entry at the end of every chain of failure event it might indicate that a password was successfully guessed!

An attempt by one user to open a restricted document is something to analyze, but it could simply be accidental. If the same user tries to open numerous secure documents, or if a number of user accounts attempt to open the same document, you have evidence of inappropriate behavior.

Consider extensively auditing delete activity on file servers. File servers usually have excess computing power that can be used for stronger auditing than you would be able to perform on resource-limited machines like SQL servers or mail servers. If you track deletion, you'll be able to see whether a user has (accidentally or otherwise) initiated a mass deletion of files that the user shouldn't be deleting.

Rename the Administrator accounts for your domain and local computers, and then create a user account named "Administrator" that is not a member of any group. Set up strong auditing on this user account to identify any attempt to use it to log on to the network. Because it's not a real account, no valid administrator would use it. Any attempt to use it is an immediate indication of a serious attack against your network.

The Worst-Case Scenario

The worst-case scenario for attack on a network is a disgruntled network administrator. These attacks are extremely rare, but when they occur they are the most damaging form of attack that can be perpetrated against a network. Network administrators typically have extremely wide access to the network, they know what sort of security measures are in place, and they can take steps to disable the auditing measures designed to track their activities.

The best way to prevent attacks by disgruntled administrators is to create separate administrative accounts for each administrator and leave the password to the built-in administrative account in the hands of non-administrative executives of the organization. The built-in accounts should be used only to create subordinate administrative accounts and change their passwords. Restrict the rights of subordinate administrative accounts so that they can perform only administrative tasks within their purview, such as creating user accounts, changing passwords, and installing drivers. You can perform this by assigning user rights for these accounts.

By having separate administrator accounts for each administrator and maintaining secrecy about administrative passwords, you can at least retain the ability to audit use by administrators.

You should realize that it's not possible to prevent damage by administrators who have wide access to your systems if they don't care about being identified. You will have to use rigorous hiring procedures and be extremely selective about the individuals to whom you entrust your network in order to avoid these types of problems.

You can also limit the scope of damage by treating attacks by administrators as natural disasters that cannot otherwise be prevented. By handling administrator attack like an earthquake or fire, you focus on restoration rather than prevention as a method of security. The best way to do this is to separate backup and archiving from all other administrative functions, and have a separate group of people handle these processes. Establish a role whose only administrative function is to handle changing backup tapes and moving backup sets off site. This process eliminates an administrator's ability to destroy backup sets as well as online data, and backup operators can't destroy online systems or offsite backups. It is typical to have a clerical worker or executive handle offsite tape backup rotation, or to use an outsourced firm to collect and store backup tapes on a daily basis.

Administrators and Passwords

Administrators usually know the passwords of non-administrative co-workers and even their administrative peers because the passwords have been given out for the sake of convenience to trusted administrators. Most users assume that administrators can access their passwords anyway, so telling it to them to solve a problem is not a big deal.

While it's true that administrators usually have wide access to systems, you should instill a culture of secrecy about passwords. To cause malicious damage to the system, a disgruntled administrator could log on using other people's user accounts. The audit logs would point to those user accounts rather than to the administrator's account. Even if you suspected an administrator was to blame, you'd have no solid evidence to support your conclusion.

Unfortunately, administrators often must log on as users to perform certain tasks such as modifying a user's profile. To cover these cases, establish a policy that administrators will not ask for the user's password rather, they will change the password to one known to them, and then assist the user in changing the password back when they're finished. This way, administrators don't need to know a user's password, and users always know if an administrator has logged on using their account.

Beware of using remote control software such as pcAnywhere or VNC that allows an administrator (or hacker) to connect to a user's computer and remotely control it. Be sure that users know that they should watch the on-screen activity any time anyone is controlling their user account, because it's their account that will show up in audit logs if anything happens.

Preserving the Evidence

Evidence preservation is key when you suspect that an internal security violation has occurred, because the burden of proof is on the IT staff. You also want to eliminate the possibility of error.

If the problem is minor, you should make backup copies of the Event log files located in the C:\WINNT\System32\config directory. If you are logged on as the administrator, you can copy the files using any normal file copy method. Table 13.1 lists the files.

Table 13-1. Event Log Files
File name	Log file
AppEvent.evt	Application Log
SysEvent.evt	System Log
SecEvent.evt	Security Log

If the event has caused damage to the system, shut down the server and make an image of the hard disk drives. If the computer has mirrored disks, you can remove the mirror, replace it with new blank disks, and reboot the server to regenerate the mirror. Otherwise, you will have to use a third-party imaging utility to copy the disks. The reason for using images rather than a backup is to retain the sectors that contain deleted data, which could be used to prove exactly what has happened using third-party information forensics tools.

Searching Audit Logs with EventComb

While the Event Viewer console provides easy access to logs on a single computer, you will often need to examine log files on a number of servers. The EventComb utility allows you to search log files on one or more servers in a domain simultaneously for the events of your choice.

Obtaining and Installing EventComb

The current version of EventComb supports multiple threads for a more efficient search, and is called EventCombMT. This tool is distributed with the Security Operations Guide for Windows 2000 Server.

The text of the Security Operations Guide for Windows 2000 Server provides more details about EventComb's features. It is available for download from the Microsoft TechNet Web site at http://www.microsoft.com/technet.

EventComb is distributed as a self-extracting executable file with other Security Operations Guide tools. Double-click the downloaded .exe file to extract the tools to a folder.

Using EventComb

EventComb does not require any special installation process. Simply launch the Eventcombmt.exe file included in the extracted folder to start EventComb. The first time EventComb is run, it displays a set of instructions. To search for events with this tool, enter the domain name for the search, as shown in Figure 13.8.

figure 13-8 the eventcomb tool

Figure 13-8. The EventComb tool

If you run EventComb on a domain controller or member server, the current domain will be selected by default. You can then specify the following search criteria:

The log files (System, Application, Security, and other logs installed by specific applications such as the DNS service.)
The events (Error, Informational, Warning, Success, and Audit events)
The event types (ID numbers)
The source (service or protocol) of events

Once you have selected these items, click the Search button to begin the search, which might take several minutes. The events found are stored in a text file, which is displayed on the desktop after the search has completed. Once you have successfully defined a search, you can choose Save This Search from the Searches menu to save it for later use.

EventComb also includes a number of predefined searches on the Searches menu, such as searches for disk errors and account lockouts.

Configuring Event Logs to Support Using EventComb

Configure the logs to a size large enough to capture a significant amount of data but small enough to make reasonable searches; 2048 KB is a reasonable value.

Ensure that events are retained long enough that they will not expire and be removed from the log before you see them. For example, if you intend to search through events once per month, set your log maximum age to a reasonable value such as 30 days.

Practice: Managing Event Logs

In this practice, you configure event-logging settings and practice using the EventComb tool to search for events in logs.

Exercise 1: Configuring Event Logs

In this exercise, you configure event logging using Group Policy.

To configure event logs

Log on to the domain controller as the administrator.
Click Start, point to Programs, point to Administrative Tools, and click Active Directory Users And Computers. The Active Directory Users And Computers management console appears.
Right-click domain.Fabrikam.com, and click Properties. The domain.Fabrikam.com Properties dialog box appears.
Click the Group Policy tab.
Double-click Domain Group Policy. The Group Policy editor appears.
Expand Computer Configuration, Windows Settings, Security Settings, and Event Log.
Select Settings For Event Logs. The management console appears as shown in Figure 13.9.

Figure 13-9. Group Policy management console
Double-click Maximum Security Log Size.
Select Define This Policy Setting, type 2048 in the Kilobytes box, and click OK.
Double-click Retain System Log.
Select Define This Policy Setting, type 30 in the Days box, and click OK. The Suggested Value Change dialog box appears.
Click OK to accept the suggested change to Retention Method For System Log.
Close the Group Policy editor.
Click OK to close the domain.Fabrikam.com Properties dialog box.
Close the Active Directory Users And Computers management console.

Exercise 2: Using EventComb

In this exercise, you use the EventComb tool to search for events matching specified criteria. Perform this exercise from the domain controller.

To search for events using EventComb

Double-click the Eventcombmt.exe file. The first time you run EventComb, it displays a Help screen, shown in Figure 13.10.

Figure 13-10. EventComb instructions
Click OK. The main EventComb dialog box is displayed, as shown in Figure 13.11.

Figure 13-11. The EventComb utility
Verify that domain.fabrikam.com is specified in the Domain box.
Right-click in the box labeled Select To Search/Right Click To Add, and click Add Single Server. The Add Server dialog box appears, as shown in Figure 13.12.

Figure 13-12. Adding a server
Type DC01 in the Server Name box, and click Add Server And Close.
Click on DC01 in the Select To Search box to select it.
Select both System and Security under Choose Log Files To Search.
Select both Error and Warning under Event Types, and select the Get All Events With Above Criteria check box.
Click Search to begin the search.

The search can take several minutes. Statistics are displayed after the search completes, as shown in Figure 13.13.

Figure 13-13. Eventcomb search completed
Click Exit to close the application.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

What should you do after detecting intrusion on a system?
What are the three basic log files used in Windows 2000?
Where can you manage log retention settings?
Which utility allows you to search for events in logs across a network?
Where does EventComb store its results?

Lesson Summary

You can use the Windows 2000 auditing and logging features to detect intrusions by valid users of the system and preserve evidence of the attacks.
After an intrusion occurs, it is important to make backup copies of the log files on the compromised system and create an image of the hard disks if files have been damaged or modified.
The EventComb utility, available for download from TechNet, provides a simple way to search for events in the log files of multiple servers in a domain. You can search for particular events or event types in the system, application, and security logs with this tool.