As I said earlier, nowadays it is worth worrying about the security of user accounts and the confidentiality of your enterprise information. In the previous articles on local security policies, you learned about methods for using local security policies and about account policies that you can use to significantly improve the security of user accounts. Now that you have correctly configured your account security policies, it will be much more difficult for attackers to gain access to user accounts. Keep in mind, though, that your job of securing your network infrastructure doesn't end there. All intrusion attempts and failed authentication of your users must be recorded in order to know if additional security measures need to be taken. Checking this information in order to determine the activity in the enterprise is called an audit.
The audit process uses three controls: audit policy, audit settings on objects, and a log. "Safety" where security events such as logon / logoff, privilege use, and resource access are logged. In this article, we will look specifically at audit policies and the subsequent analysis of events in the log. "Safety".
Audit policy
An audit policy configures an activity audit for a specific user and group on the system. In order to configure audit policies, in the Group Policy Management Editor, you must open the node Computer Configuration / Windows Configuration / Security Settings / Local Policies / Audit Policy... It should be remembered that by default the audit policy setting for workstations is set to "Undefined"... In total, you can configure nine audit policies, as shown in the following illustration:
Rice. 1. Node "Audit Policy"
As with other security policies, you need to define a policy setting to configure auditing. After double-clicking with the left mouse button on any of the options, check the box on the option "Define the following policy settings" and specify the parameters for auditing success, failure, or both.
Rice. 2. Properties of the audit policy "Audit directory service access"
Once the audit policy is configured, events will be logged to the security log. You can view these events in the security log. Let's take a closer look at each audit policy:
Login audit... The current policy determines whether the operating system of the user whose computer this audit policy applies to audits every user logon or logoff attempt. For example, when a user successfully logs on to the computer, an account logon event is generated. Logout events are generated every time the session of the logged-on user account ends. Success auditing means creating an audit record for every successful login attempt. Failure auditing means creating an audit record for every failed login attempt.
Object Access Auditing... This security policy audits user attempts to access objects that are not related to Active Directory. These objects include files, folders, printers, system registry keys, which are specified by their own lists in the system access control list (SACL). An audit is generated only for objects for which ACLs are specified, provided that the requested access type and the account making the request match the parameters in these lists.
Auditing Directory Service Access... With this security policy, you can determine whether the events specified in the System Access Control List (SACL), which you can edit in the dialog box, will be audited. "Advanced Security Options" properties of the Active Directory object. An audit is generated only for objects for which an SACL is specified, provided that the requested access type and the account making the request match the parameters in this list. This policy is somewhat similar to the policy "Audit of access to objects"... Success auditing means creating an audit record each time a user successfully accesses an Active Directory object for which a SACL table is defined. Failure auditing means creating an audit record for every unsuccessful user attempt to access an Active Directory object for which a SACL table is defined.
Policy change audit... This audit policy specifies whether the operating system will audit each attempt to change the user rights, audit, account, or trust policy. Success auditing means creating an audit record for each successful change to user rights assignment policies, audit policies, or trust policies. Failure auditing means creating an audit record for every unsuccessful attempt to change user rights assignment policies, audit policies, or trust policies.
Auditing Privilege Changes... Using this security policy, you can determine whether the use of privileges and user rights will be audited. Success auditing means creating an audit record for each successful application of a user right. Failure auditing means creating an audit record for each unsuccessful application of a user right.
Process Tracking Audit... The current audit policy determines whether the operating system will audit process-related events, such as the creation and termination of processes, as well as program activation and indirect access to objects. Success auditing means creating an audit record for each successful event associated with a monitored process. Failure auditing means creating an audit record for every failed event associated with a monitored process.
Auditing system events... This security policy is especially valuable, because it is with this policy that you can find out whether the user's computer has been overloaded, whether the size of the security log has exceeded the warning threshold, whether there was a loss of tracked events due to a failure of the auditing system, and even whether changes were made. which could affect the security of the system or the security log up to the change of the system time. Success auditing means creating an audit record for every successful system event. Failure auditing means creating an audit record for every failed system event.
Auditing logon events... With this audit policy, you can specify whether the operating system performs an audit each time this computer validates credentials. This policy generates an event for local and remote user logon. Domain members and computers outside the domain are trusted for their local accounts. When a user tries to connect to a shared folder on a server, a remote logon event is logged in the security log, but logoff events are not logged. Success auditing means creating an audit record for every successful login attempt. Failure auditing means creating an audit record for every failed login attempt.
Account Management Audit... This latter policy is also considered very important because it is through it that you can determine whether to audit every UAC event on the computer. The security log will record actions such as creating, moving, and disabling accounts, and changing passwords and groups. Success auditing means creating an audit record for every successful account management event. Failure auditing means creating an audit record for every failed account management event
As you can see, all audit policies are to some extent very similar, and if you set an audit of all policies for each user of your organization, then sooner or later you will simply get confused in them. Therefore, it is necessary to first determine what exactly is needed for the audit. For example, to make sure that one of your accounts is constantly being accessed by brute-force attacks, you can audit failed login attempts. In the next section, we'll look at the simplest example of using these policies.
An example of using audit policy
Let's say we have a domain testdomain.com that has a user with the DImaN.Vista account. in this example, we will apply the policy to this user and see what events are written to the security log when an unauthorized access attempt is made to the system. To reproduce this situation, follow these steps:
Conclusion
In this article, we continued our study of security policies, namely, we looked at the audit policy settings, with which you can investigate intrusion attempts and failed authentication of your users. All nine security policies responsible for auditing have been reviewed. Also, using an example, you learned how audit policies work using a policy "Auditing Login Events"... The situation of unauthorized entry into the user's computer was emulated, followed by an audit of the security log.
To audit access to files and folders in Windows Server 2008 R2, you must enable the auditing function, as well as specify the folders and files to which you want to record access. After configuring the audit, the server log will contain information about access and other events for the selected files and folders. It should be noted that auditing of access to files and folders can be performed only on volumes with the NTFS file system.
How to enable auditing for file system objects in Windows Server 2008 R2
Auditing of access to files and folders is enabled and disabled using group policies: domain policies for the Active Directory domain or local security policies for stand-alone servers. To enable auditing on a separate server, you must open the Local Policy Management Console Start ->AllPrograms ->AdministrativeTools ->LocalSecurityPolicy... In the local policy console, expand the local policy tree ( LocalPolicies) and select item AuditPolicy.
In the right pane, select the item AuditObjectAccess and in the window that appears, specify what types of file and folder access events need to be recorded (successful / unsuccessful access):
After selecting the desired setting, you need to click OK.
Selecting files and folders, access to which will be recorded
After the auditing of access to files and folders is activated, it is necessary to select specific objects of the file system, access to which will be audited. Just like NTFS permissions, audit settings are inherited by default on all child objects (unless configured otherwise). In the same way as when assigning permissions to files and folders, inheritance of audit settings can be enabled for all or only for selected objects.
To configure auditing for a specific folder / file, you need to right-click on it and select Properties ( Properties). In the properties window, go to the Security tab ( Security) and press the button Advanced... In the advanced security settings window ( AdvancedSecuritySettings) go to the Audit tab ( Auditing). Setting up auditing naturally requires administrator rights. At this stage, the audit window will display a list of users and groups for which audit is enabled on this resource:
To add users or groups whose access to this object will be recorded, you must click the button Add ... and specify the names of these users / groups (or specify Everyone- to audit access of all users):
Immediately after applying these settings in the Security system log (you can find it in the snap-in ComputerManagement -> Events Viewer), each time you access objects for which auditing is enabled, corresponding entries will appear.
Alternatively, events can be viewed and filtered using the PowerShell cmdlet - Get-EventLog For example, to display all events from eventid 4660, execute the command:
Get-EventLog security | ? ($ _. eventid -eq 4660)
Advice... It is possible to assign specific actions to any events in the Windows log, such as sending an email or executing a script. How it is configured is described in the article:
UPD from 06/08/2012 (Thanks to the commentator).
In Windows 2008 / Windows 7, a special utility has been added to manage audit auditpol... The complete list of object types for which auditing can be enabled can be seen using the command:
Auditpol / list / subcategory: *
As you can see, these objects are divided into 9 categories:
- System
- Logon / Logoff
- Object Access
- Privilege Use
- Detailed tracking
- Policy Change
- Account Management
- DS Access
- Account Logon
And each of them, respectively, is divided into subcategories. For example, the Object Access audit category includes the File System subcategory, and to enable auditing for file system objects on the computer, run the command:
Auditpol / set / subcategory: "File System" / failure: enable / success: enable
It turns off, respectively, with the command:
Auditpol / set / subcategory: "File System" / failure: disable / success: disable
Those. If you turn off auditing of unnecessary subcategories, you can significantly reduce the size of the log and the number of unnecessary events.
After the audit of access to files and folders is activated, you need to specify the specific objects that we will control (in the properties of files and folders). Keep in mind that by default, auditing settings are inherited across all child objects (unless otherwise noted).
Hello everyone!
We continue to publish cheat sheets on setting up auditing of various systems, last time we talked about AD habrahabr.ru/company/netwrix/blog/140569, today we will discuss file servers. I must say that most often we perform file server auditing settings - during pilot installations with customers. There is nothing difficult in this task, just three simple steps:
- Configure auditing on file shares
- Configure and apply general and detailed audit policies
- Change Event Log Settings
Configuring auditing on file shares
Setting up a general audit policy
In order to control changes on the file server, you need to set up an audit policy. Before configuring the policy, make sure that your account is a member of the Administrators group or that you have rights to manage auditing and event logs in the Group Policy snap-in.
Setting up a detailed audit policy
Configuring event logs
In order to effectively control changes, it is necessary to configure the event logs, namely, to set the maximum size of the logs. If the size is not large enough, events may be overwritten before they reach the database that your application is using to monitor changes.
Finally, we would like to offer you a script that we ourselves use when setting up auditing on file servers. The script configures auditing on all balls for each of the computers in the given OU... Thus, you do not need to manually enable settings on each file share.
Before starting the script, you need to edit line 19 - enter the required values instead of "your_ou_name" and "your_domain". The script must be run under an account that has domain administrator rights.
You can get the script from our knowledge base or save the following text to the .ps1 file:
# import-module activedirectory # $ path = $ args; # \\ fileserver \ share \ folder $ account = "Everyone" # $ args; $ flavor = "Success, Failure" # $ args; $ flags = "ReadData, WriteData, AppendData, WriteExtendedAttributes, DeleteSubdirectoriesAndFiles, WriteAttributes, Delete, ChangePermissions, TakeOwnership" $ inheritance = "ContainerInherit, ObjectInherit" $ propagation = "None" $ comps = Get-ADComputer -Filter * -Search = your_ou_name, DC = your_domain, DC = your_domain "| select -exp DNSHostName foreach ($ comp in $ comps) ($ shares = get-wmiobject -class win32_share -computername $ comp -filter "type = 0 AND name like"% [^ $] "" | select -exp name foreach ( $ share in $ shares) ($ path = "\\" + $ comp + "\" + $ share $ path $ acl = (Get-Item $ path) .GetAccessControl ("Access, Audit") $ ace = new-object System.Security.AccessControl.FileSystemAuditRule ($ account, $ flags, $ inheritance, $ propagation, $ flavor) $ acl.AddAuditRule ($ ace) set-acl -path $ path -AclObject $ acl))
The required OPs of the sales department can be very different from the OPs of the financial department.
Group Policy snap-in Allows setting security settings directly to the Active Directory store. Folder Security Settings is in the node Computer Configuration and the User Configuration node
the owner). Security settings allow Group Policy administrators to set policies that restrict users from accessing files and folders, determine the number of invalid passwords a user can enter before being denied login, control user rights such as which users can log on to. domain server.
8.5. Auditing in Microsoft Windows
8.5.1. Windows Auditing Overview
Auditing in Windows is the process of tracking user actions and Windows actions (called events). During auditing, Windows writes event information to the security log as directed. This log records attempts to log on to the system with correct and incorrect passwords, as well as events related to the creation, opening, destruction of files or other objects.
Each security log entry contains:
information about the performed action;
information about the user who performed this action;
information about the event that occurred during this, as well as whether it was successful.
8.5.1.1. Using audit policy
The audit policy determines what types of events Windows should write to the security log on each computer. This log allows you to track the events you specified.
Windows writes event information to the Security log on the computer on which the event occurred
place. For example, you can configure auditing so that every time someone unsuccessfully tries to log on to a domain with a domain account, that event is logged in the security log on the domain controller.
This event is logged on the domain controller and not on the computer that the logon attempt was made on because it was the domain controller that tried and failed to authenticate the logon.
You can configure an audit policy on a computer for:
tracking the success / failure of events such as a login attempt, a specific user trying to read a specified file, changes to a user account or group membership, and changes to your security settings;
elimination or minimization of the risk of unauthorized use of resources.
You can use the snap-in to view the events written by Windows to the security log. Event Viewer... You can also archive logs for you to
Long-term trend phenomena - for example, to determine the intensity of access to printers or files, or to control attempts by unauthorized access to resources.
8.5.2 Planning the audit policy
The administrator must decide on which computers to audit. Auditing is disabled by default.
When defining computers to audit, the administrator must also plan what to monitor on each computer. Windows records the events it checks separately on each computer.
You can audit:
access to files and folders;
logging in and out of certain user
shutdown and restart your Windows computer
changes to user and group accounts;
attempts to modify Active Directory objects.
Once you have determined which events to test, you need to decide whether to track their success and / or failure. Tracking Success Events tells you how often users of Windows or its services access certain files, printers, and other objects. This is useful when planning resource usage. Tracking unsuccessful events can alert you to potential security breaches. For example, multiple failed attempts to log in with a specific account, especially if they occur outside of normal business hours, could mean that someone without access rights is trying to hack into the system.
When determining the audit policy, it is advisable to be guided by the following principles:
decide if you want to track trends in system resource usage. In this case, schedule backing up the event logs. This will allow you to see changes in the use of system resources and increase them in advance;
review the security log frequently. Schedule and review this log regularly as setting up auditing alone will not alert you to security breaches;
make audit policy useful and easy to manage. Always check sensitive and confidential data. Check only such events to get meaningful information about the situation on the network. This minimizes the use of server resources and makes it easier to find the information you are looking for. Auditing too many events will slow down Windows;
check access to resources of non-group usersUsers, and users of the Everyone group. This ensures that you can track anyone who connects to the network, not just those for whom the account was created.
8.5.3 Implementing audit policy
It is necessary to think through the audit requirements and configure its policy. By configuring an audit policy on a computer, you can audit files, folders, printers, and Active Directory objects.
8.5.3.1. Audit setup
You can enforce audit policies based on the role of this computer in the Windows network. Auditing is configured differently for the following types of Windows computers:
For a member server in a domain, a stand-alone server, or Windows workstations, the audit policy is configured separately for each machine;
Domain controllers have one audit policy for the entire domain. To audit events on domain controllers, such as changes to Active Directory objects, you must configure Group Policy for the domain that will apply to all controllers.
Requirements for performing an audit
Configuring and administering auditing requires the following conditions to be met:
You must have permission Manage Auditing And Security Log for
the computer on which you want to configure audit policy or view the audit log. By default, Windows grants such rights to the group Administrators
files and folders to be audited must be on NTFS drives.
Audit setup
You have to configure:
an audit policy that includes an audit mode but does not audit for specific objects;
audit for specific resources, i.e. specify specific monitored events for files, folders, printers, and
Active Directory objects. Windows will monitor and log these events.
8.5.3.2. Configuring audit policy
V the first step is to select the types of events to track. Parameters are set for each event
settings that show which attempts to track: successful or unsuccessful. You can configure audit policies through the snap-in Group Policy
The types of events that can be checked in Windows are shown in Table 8.1.
Table 8.1
Types of events that can be checked in Windows
Description |
||
Login events | Domain controller received a verification request |
|
system with | correct user account |
|
noah record | ||
Control | Administrator created, changed or deleted |
|
account or group. Account |
||
user has been changed, enabled, or |
||
keyed, or the password was set or changed |
||
Service access | The user has accessed the Active object |
|
catalogs | Directory. You must specify specific |
|
Active Directory objects to track this |
||
type of event |
||
Login events | User logged in and out |
|
or connected / could not connect over the network |
||
to this computer |
||
Access to the object | User got access to file, folder |
|
or a printer. You must specify files, folders |
||
or printers to check. Check mode |
||
directory service access checks access |
||
user to a specific Active object |
||
Directory. Object access mode checks |
||
user access to files, folders, or |
||
printers |
||
The change | Changes have been made to custom |
|
security settings, user rights |
||
or audit policies |
||
Usage | The user applied the rights, for example, due to |
|
privileges | change the system time. (This does not include |
|
rights associated with logging in and |
||
exit from it) |
||
Tracking | The user performed an action. This information |
|
process | This is useful for programmers who want to track |
|
give details of program execution |
||
Systemic | The user has rebooted or turned off the com- |
|
pewter, or an event has occurred that affects |
||
Windows security or per security log |
||
nosti. (For example, the audit trail is full, and |
||
Windows was unable to write new information |
||
Even the most modern production, a small office or a large company are faced with the problem of commonplace human error. Accounting, economics, managers, any other employee - many may have access to certain files. Therefore, it is very important to use Windows Auditing to track user activity. It may happen that someone on the staff has deleted a very important file or data that is included in the public folders on the file server. As a result, the fruits of labor of an entire organization can be deleted or distorted, and the system administrator will have to fight this problem on his own. But only not if you order the Windows audit service.
It is worth noting that the OS has an Audit system, in which it is possible to track and log data on when, where and under what circumstances, and with the help of which program, certain events occurred that led to the deletion of the folder or allowed you to erase or modify an important file. But by default, Audit does not work, since it is important to use a certain system capacity. And the load can be too high, so the Audit politicians keep a selective record of those events that are really important.
Audit is built into any Windows OS, but self-configuration can be quite difficult, so it is better to order an audit of file access on a Windows server.
So, to conduct an audit, you need to enable its function and specify each file and folder to which you will have to record accessibility. Windows audits file access only on NTFS volumes.
Enabling Audit on File System Objects in Windows Server 2008 R2
You can enable or disable auditing of access to objects by using Group Policy. This can be a domain option for Active Directory or a local security option designed for individual servers.
Enabling auditing on a separate server is as follows. Open the management console for the local options Start ->… -> Local Security Policy. Then expand the Local Policies tree and then select Audit Policy. On the right side, select Audit Object Access, and then select accessibility events for each file and folders that need to be recorded.
Selecting files and folders, access to which will be recorded
After Audit is activated on the file server, select certain objects against which access will be audited. To do this, right-click and select Properties. Then go to the Security menu and then click Advanced. Advanced security settings open the Audit tab. Administrator rights are required to configure. To set up usage rights, it is important to add an entry to Add and specify the username. The exact settings are specified later, including login, create / modify, or, when deleting a file, other operations.
After that, a corresponding entry will appear in the Security log (Computer Management -> Events Viewer) with each entry. Tasks can be filtered by PowerShell - Get-Event Log. So, on operations with eventid 4660 you will have to run Get-EventLog security | ? ($ _. eventid -eq 4660.
Enabling advanced auditing of files and folders on file servers
It is best to audit Windows Server 2008 R2 on a test host. The file host access auditing requires group folder management. Verifying it involves creating a new GPO. Through Computer configuration, you need to go to Security Settings. There you will need to adjust the parameters of the Journal and configure the audit itself. Customized operations are usually done individually. Usually 200 MB is enough, the maximum storage time is up to 2 weeks, set automatic saving by day.
To set up auditing for a file serving database center, you will need to use file system auditing. If you select the option "About a file share", then the recording will be kept as detailed as possible, and any information will be recorded. To optimize the policy, it is important to apply it to the master hardware device. It is best to do this on a domain controller. Click "Add", and indicate "Computers" as objects. Then they conduct a policy check, check the results and go to the file main service center. It is important to ensure that the folder is presented with file access.
Now you can go to the security tab in the "Advanced" section. Then the SACL is added. As for the type, it can be Audit of file access, Audit of file deletion, audit of file changes - each mechanism of action depends on the tasks assigned to the user. It is important to understand that for each individual enterprise, such tasks may be different both in content and in scope.
Auditing file access on a Windows server
When deleting a file, the same events are created with ID = 4663. Moreover, a data record or deletion of the DELETE file appears in the body of BodyL. When renaming, not one ID = 4663 record appears, but two at once. In the first case, the deletion occurs, in the second, the data is written. You cannot bypass the version of message 4660, which contains the username and other service data, including the descriptor code.
When a file is deleted, such events are generated simultaneously, but their sequence is always 4663 first of all, and only then 4660. Moreover, the ordinal number differs by 1. And the ordinal number of 4660 is greater by 1 than 4663. And by this property you need to search for the required tasks ...
Accordingly, the events taking place from 4660 are taken. They have two properties: the time (Time) of creation and the sequence number. Later in the variable $ PrevEvent enter the number of the operation, which contains data about the remote file. The time frames for the search must be determined, and they must be reduced to 2 s (with an interval of + - 1 s). Most likely, this additional time (Time) will be required to create each completed task separately.
Consequently, auditing a Windows Server 2008 R2 file server does not record temporary docks that are deleted (. * Tmp). Locks (. * Lock) and temporary (. * ~ $ *) Documents are not written. Similarly, the fields for the $ BodyL variable are selected, and after the tasks are found, $ BodyL is written to the Text file log.
The log for Audit access to documents requires the following scheme: 1 file per month with the name (Name), which contains the month and year. The fact is that there are much fewer deleted items than those docks for which access audits are performed. That is why, instead of checking each log, a log file is opened in any table and data on the user or the content of the document itself is viewed.
Configuring file server auditing: detailed instructions and cheat sheet (.pdf)
Auditing a Windows Server 2008 folder is easy. You need to open Start → Run → eventvwr.msc, then the security log Security. Since it contains various events that are completely unnecessary, you will need to click View → Filter and filter the events
Event Types: Success Audit;
as well as Category: Object Access;
Event Source: Security.
There is no need to misunderstand deletions. It's just that such a function in the Windows XP Audit operation is applicable to the normal operation of programs. Including most applications at startup, they first form a temporary file, then the main one, and the temporary one is deleted when the program exits. It also happens that a file and entire folders (sometimes - databases) are deleted with malicious intent. For example, a dismissed employee decided to harm the company and delete all information. But restoring folders will not be difficult for an ordinary system administrator either. It is quite another matter when you can say when and who did something like that.
Auditing a network folder or auditing network folders (whichever is more convenient for you) begins with configuration. To do this, go to the Properties of the balls, go to the security tab and select "Advanced", then the Audit tab, where (where) you need to select the Everyone user group. Then you need to select Edit, and only after that click on the present checkboxes as in the screenshot:
In this case, the list "Apply onto" must contain the value "This folder, subfolders ...". And then, as the setting is completed, you should click OK.
Auditing Windows Server 2008 involves setting up a general policy. Before configuring, make sure that the account is in the Administrators group. Auditing a Windows Server 2008 R2 network folderStandartcomparable to earlier versions. But at the same time, the developers themselves advise using advanced features, and not folders or items (objects), although little has changed since 2003. Therefore, it is hardly worth looking for any relevant data. It just takes a little time to customize Server 2008 auditing for specific tasks and in accordance with the requirements that are presented for the specific business goals of the company
- Login or register to leave comments
