One of the first steps to better computer security is to know exactly what’s going on within the system. This is where your system’s security logs come into play. Events recorded in the security logs allow you to see exactly who is doing what within the system. In this Daily Drill Down, I’ll show you what events are recorded in Windows 2000’s security logs and how to interpret them.
Recording and viewing events
The security logs contain information that helps you to track what’s happening on your server, but to use them you must first enable tracking by making the proper selections in group policies and the Event Viewer. For the purposes of this Daily Drill Down, I won’t go into detail about how to use group policies to enable auditing or how to use the Event Viewer. For details about how to enable auditing, see the Daily Drill Down “Know what’s happening on your Windows 2000 server with auditing.”
To start the Event Viewer, click Start | Programs | Administrative Tools | Event Viewer. The Event Viewer shows you several categories of information, all arranged into columns. For example, there are columns for the type of event, date, time, category, and so on. If you click on a category name, the Event Viewer will sort the log entries by that category. This is an extremely useful feature when dealing with security logs. For example, with the click of a button, you could look at all of the failure audits, or all of the events related to a specific user. In general, the security logs work the same as the other type of logs found in the Event Viewer.
Account Logon events
The Account Logon event, shown in Figure A, refers to an event that occurs any time that a logon request is sent to a domain controller. Unfortunately, this event is one of the more difficult events to spot when it’s mixed in the midst of a long security log. You’ll notice that the event in Figure A has the category of Logon/Logoff.
You can’t really go by the event ID. For example, this particular screen shot uses the event ID 540. However, it isn’t uncommon to have event IDs of 538 and 528 along with a few other more obscure event IDs. The only way that you can really distinguish an Account Logon event is by looking at the event description. If the description lists one of your domains, then the event is an Account Logon event.
|Account logon events occur any time a logon request is sent to a domain controller.|
As you look at the figure, there are a few other things that you should take note of that are common to all types of events. Notice that the log entry records the date and time of the event. You should also pay attention to the event type. The event category only tells you that the event was attempted; the type tells you whether the attempt was successful or not. The user and computer entries tell you which user was responsible for the event, and from which computer the access attempt was made.
Account Management events
Account Management events occur any time that a user account is created, modified, or deleted. Account Management events almost always have an event ID of 643. You can also easily identify an Account Management event by looking at the category name, which will say Account Management. You can see an example of an Account Management event in Figure B.
|Account Management events occur any time that a user account is created, modified, or deleted.|
As you look at the figure, you’ll see that the most important thing with an Account Management event is the description. The event shown in the figure not only tells you that the domain’s password policy was modified, but also which domain was affected. The Caller User Name field under the description identifies the name of the person who changed the account. In this case, I have a server named Bart, and BART$ was a built-in server account.
Directory Service Access events
Most of the time, a Directory Service Access event will only show up on domain controllers, although it’s possible for workstations or member servers to exhibit such an event. Generally speaking, the event simply means that someone tried to access the directory service. The event is recognizable because the category will always be Directory Service Access, and the event ID will almost always be 565.
Again, as you can see in Figure C, the description is the most important part of this type of audit. It tells you which process accessed which object. Although you can’t really tell from the screen capture, the Description window is actually really long and contains much more information than what you can see here. It also contains information about which user, computer, and domain made the access attempt, and exactly what actions were performed on the affected Active Directory object. For example, you would normally expect to see an access list that contains things like Delete, Read_Control, Write_DAC, Write_Owner, ConnectToServer, and so on. In fact, those accesses were about half of the actual accesses associated with the event shown in the screen capture.
|The Directory Service Access event entry contains a lot of information.|
Earlier I showed you a type of audit entry called an Account Logon event. However, there is also a type of log entry called a Logon event. The only real difference between the two types of events is that while an Account Logon event logs logon requests sent to a domain controller, Logon events refer to local logons. As you can see in Figure D, a logon event shares the Logon/Logoff category name with the Account Logon event, and the 528 event ID is also often used by the Account Logon event. However, if you look at the domain name in the Description field, you’ll see that the domain name is DR-EVIL. I don’t have a DR-EVIL domain; DR-EVIL is the name of a workstation. Therefore, this is a Logon event rather than an Account Logon event.
|Looking at the domain name in the Description field is the easiest way to tell a Logon event from an Account Logon event.|
Object Access events
The Object Access event works a little bit differently from the other types of events that I’ve shown you. Object Access events refer to access to files and directories. Enabling auditing through the group policy is only half of the process required to audit object access. The other half of the process involves right-clicking on the file or folder that you want to audit and selecting the Properties command from the resulting shortcut menu.
When you do, you’ll see the file or folder’s Properties. Select the Security tab and click the Advanced button to reveal the Properties for the object’s Access Control Settings. Then select the Auditing tab. The Auditing tab allows you to audit a wide variety of events on a user-by-user or group basis. For example, you can audit events such as reading, writing, and executing files. You can even go as far as auditing the event if someone checks the object’s permissions or attributes. Like group policy auditing, you can implement a success and/or a failure audit for each listed event.
The biggest stipulation with object access auditing is that you can only audit objects that exist on NTFS partitions. If you need to audit an object that exists on a FAT or FAT-32 partition, you can convert the partition to NTFS by using the CONVERT drive_letter: /FS:NTFS command, where DRIVE_LETTER is the drive letter associated with the partition that you’re converting. Just remember that the NTFS conversion is a one-way process and there’s no way to revert back to your original file system. Therefore, if your machine uses multiple operating systems or has other special reasons for using a FAT or FAT-32 partition, don’t convert the partition.
Figure E shows a typical Object Access event as it would appear in the Security log. While the event’s category will always be Object Access, the event ID won’t always be the same. However, the most common event IDs for this type of event are 560 and 562. Like other types of auditing that we’ve looked at, you can gain the most information by looking at the Description window. You can see in the figure that this particular log entry is a success audit showing that TEST\Administrator accessed the folder C:\TEST.
|Object Access events refer to access to files and folders on NTFS partitions.|
Policy Change events
Policy Change events typically use the Policy Change category and usually have an event ID of 612. You should pay close attention to Policy Change events because they tell you when someone has been trying to modify policies within the system. For example, if you look at the Description field in Figure F, you’ll see that there was a really big change to the machine’s audit policy.
|Policy Change events alert you to someone trying to change a policy on your system.|
Privilege Use events
The Privilege Use event is triggered when someone tries to use one of the special privileges granted by an administrator. This event always has the category name Privilege Use, but it has fluctuating Event IDs. Common event IDs are 576, 577, and 578. You can see an example of a Privilege Use event in Figure G.
|A Privilege Use event occurs when a user tries to use a special privilege that was granted to them.|
Process Tracking events
Perhaps the most difficult event to really diagnose is the Process Tracking event. Process Tracking events tell you when someone launched a process. Processes make up applications but don’t necessarily have to be a part of an application. There are a couple of reasons why this type of event can be hard to follow. First, unless you install Windows 2000 Service Pack 3, the process IDs can be incorrect because of an obscure glitch in Windows.
Another reason is that processes are often spawned by the operating system or by an application rather than directly by a user. Therefore, you’ll probably see a lot of Process Tracking events that don’t contain much useful information. You can see an example of such an entry in Figure H.
|Process tracking events can be very misleading.|
System events are probably the most generic of all of the different security events. Although System event security log entries can give you some very useful information, there’s little consistency about the types of information that you’ll receive. For example, the event shown in Figure I refers to a trust relationship that’s being used. System events always use the category name System Event, but they can use a variety of event IDs, such as 514, 515, and 518.
|System events give you security-related information about the way that the operating system is working.|
Secure your network in any event
At first glance, the events recorded in the security logs are confusing. If you’ve never looked at Event Viewer’s security logs before, you may not be able to make heads or tails of the information they contain. However, once you’re familiar with the events, you can take appropriate measures to secure your network.