Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Windows Server 2003 : Windows Security and Patch Management - Using Auditing and the Event Log

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/12/2012 3:19:58 PM
Auditing controls and properties are modified through GPOs in Windows 2000, Windows XP, and Windows Server 2003. Assuming your computer is participating in an Active Directory domain, you can find the domain auditing policy inside the Default Domain Policy, in the Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policies tree. Otherwise, you can view the Local Security Policy through the Administrative Tools applet in the Control Panel.

The settings for each GPO indicate on what type of events and on what type of result a log entry will be written. Here are the options for auditing policies:


Audit account logon events

Writes an entry when domain users authenticate against a domain controller.


Audit account management

Indicates when user accounts are added, modified, or deleted


Audit directory service access

Audits when queries and other communications with Active Directory are made


Audit logon events

Writes an entry when local users access a resource on a particular computer.


Audit object access

Indicates when certain files, folders, or other system objects are opened, closed, or otherwise "touched"


Audit policy change

Audits when local policies (such as the Local Security Policy) and their associated objects are changed


Audit privilege use

Writes an entry when users make use of privileges assigned to them (such as "Take Ownership")


Audit process tracking

Tracks program activation, when programs close, and other events that programs cause


Audit system events

Audits when a user restarts a computer or when events are written to the security log or otherwise affect system security

You can configure individual objects to be audited by editing the system access control list (SACL) for any given object, which is much like assigning permissions, except it is indicating to Windows on what type of access an event log entry should be writing. You can access the SACL for an object by clicking the Advanced button on the Security tab of the object's properties sheet. On the Auditing tab, you can click Add to include new auditing events for an object, or click View/Edit to modify an existing auditing event. Figure 1 shows the SACL for an object.

Figure 1. The SACL for an object

Only NTFS files and folders can be audited. FAT partitions do not contain the necessary permission information to support auditing events.


1. Recommended Items to Audit

You'll want to take particular note of the following items from your event logs:

  • Logon and logoff events are tracked by Audit account logon events and Audit logon events setting, which can indicate repeated logon failures and point to a particular user account that is being used for an attack.

  • Account management is tracked by the Audit account management setting, which indicates users who have tried to use or used their granted user and computer administration power.

  • Startup and shutdown events are tracked by the Audit system event setting, which shows that a user has tried to shut down a system as well as what services might not have started up properly upon reboot.

  • Policy changes are tracked by the Audit policy change setting, which can indicate users tampering with security settings.

  • Privilege use events are tracked by the Audit privilege use setting, which can show attempts to change permissions to certain objects.

You should be aware of a couple of things. First, too much auditing consumes large amounts of resources. Entries will be written every time a user moves a mouse (OK, that's an exaggeration, but not much of one). Second, too much auditing also tends to be overwhelming, and because auditing in general will do nothing for you if you don't view the audit entries, can you see a loop forming? You don't want to look at audits because there is so much to wade through, so effectively you're wasting resources and gaining no security advantage from it. Be aware.

2. Event Logs

Similar to auditing policies, the policies for configuring the event logs are found inside the Default Domain Policy, in the Computer Configuration → Windows Settings → Security Settings → Local Policies → Event Log tree. Here are the options for event log policies:


Maximum application log size

Sets the maximum size the log is allowed to reach before the oldest events in the log will be purged.


Maximum security log size

Does the same as the previous item but pertains to the security log.


Maximum system log size

Does the same as the previous two items but pertains to the system log.


Restrict guest access to application log

Disallows access to the application log from users logged onto the Guest account.


Restrict guest access to security log

Disallows access to the security log from users logged onto the Guest account.


Restrict guess access to system log

Disallows access to the system log from users logged onto the Guest account.


Retain application log

Specifies whether to overwrite events or save them when the application log file reaches the maximum size.


Retain security log

Specifies whether to overwrite events or save them when the security log file reaches the maximum size.


Retain system log

Specifies whether to overwrite events or save them when the system log file reaches the maximum size.


Retention method for application log

Specifies whether Windows should overwrite old application log events as it sees fit or only those older than n days; you also can choose to simply not overwrite files and clear the logs manually.


Retention method for security log

Specifies whether Windows should overwrite old security log events as it sees fit or only those older than n days; you also can choose to simply not overwrite files and clear the logs manually.


Retention method for system log

Specifies whether Windows should overwrite old system log events as it sees fit or only those older than n days; you also can choose to simply not overwrite files and clear the logs manually.


Shut down the computer when the security audit log is full

Shuts off the computer until an administrator can clear the security log and new events can be written.

To configure the event logs locally on a computer that does not participate in a domain, load the Event Viewer console (which is within the Control Panel and Administrative Tools) and then right-click each log in the left pane. You can set the log size options on this screen, including the maximum size and the actions Windows should take when that limit is reached.

2.1. The Event Viewer

The Event Viewer allows you to look at events in three event logs by default. Other applications can add their own logs into the Event Viewer console. Figure 2 shows a typical Event Viewer console, with the three default logs.

Figure 2. An Event Viewer console

First, the security log displays successes and failures with regard to privilege use, and classifies them into categories such as object access, account logon, policy change, privilege use, directory service access, and account management. The remaining event logs have three different classes of entries: errors, informational events, and warnings. The application log consists of information reported from programs running on the system. The system log consists of events and exceptions thrown by Windows itself. All users can see the system and application logs, but only members of the Administrators group can see the security log.

To clear all events from your Event Viewer console, choose Clear All Events from the Action menu.

Other -----------------
- Windows Server 2003 : Windows Security and Patch Management - Locking Down Windows
- Recovering from a Disaster in an Exchange Server 2007 Environment : Recovering from a Site Failure & Recovering from a Disk Failure
- Recovering from a Disaster in an Exchange Server 2007 Environment : Identifying the Extent of the Problem & Preparing for a More Easily Recoverable Environment
- Windows Server 2008 Server Core : Setting the Environment & Modifying the Hardware Setup
- Windows Server 2008 Server Core : Performing Console Configuration
- Windows Server 2008 : Using Basic ds Commands - Understanding Distinguished Names & Adding Objects with dsadd
- Windows Server 2008 : Manipulating IIS with appcmd
- Microsoft Lync Server 2010 Edge : Edge Server Administration (part 2)
- Microsoft Lync Server 2010 Edge : Edge Server Administration (part 1)
- Sharepoint 2010 : Setting Up the Crawler - Crawling Other Document Types with iFilters
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server