Critical File Monitoring Using Native Auditing on Windows and Linux
- Pavan Raja
- Apr 8, 2025
- 9 min read
Summary:
The provided context does not explicitly mention how to delete a file using `auditctl`, but it does provide information on how to monitor and manage file accesses, including read, write, and modify events. To delete a file in Linux using auditing with `auditctl`, you can follow similar command format as used for monitoring other actions like reading or writing:
```bash auditctl -w /path/to/file_or_directory -p remove -k keyword_for_this_action ```
In this command: - `/path/to/file_or_directory` is the path to the file you want to monitor for deletion. - `-p remove` specifies that you are interested in monitoring removal (delete) events. - `-k keyword_for_this_action` is a custom keyword or tag used to identify this specific audit rule, which can be useful for later analysis.
For example, if you want to monitor the deletion of `/home/arcsight/filemon_test/do_not_delete.txt`, you would use:
```bash auditctl -w /home/arcsight/filemon_test/do_not_delete.txt -p remove -k do_not_delete_deletion ```
This command will start monitoring events where the specified file is deleted, and it will be associated with a keyword `do_not_delete_deletion` for easy identification in audit logs.
Remember that while this setup will capture delete actions, it won't automatically prevent deletions; it merely records them for later review and analysis. For actual prevention of unauthorized deletions, additional security measures such as file system permissions or use of a dedicated access control mechanism might be necessary.
Details:
The ArcSight Technical Note discusses critical file monitoring using native OS auditing, specifically targeting Windows and Linux systems due to their prevalence in such use cases. The document aims to provide guidance on configuring effective critical file monitoring by detailing how to set up detailed audits for specific files, considering the potential high volume of audit events generated from system processes. It emphasizes the importance of carefully selecting which files require auditing based on users or groups and suggests a balanced approach between extensive auditing (which could lead to excessive event generation) and minimal configuration.
This document outlines how to set up Windows File Monitoring for auditing purposes. It begins by explaining that both Windows Object Access Auditing (default on Windows systems) and Linux auditd auditing are enabled by default due to their low-resource usage and ability to create highly granular policies.
For Windows, the process involves:
1. Ensuring Event Logging is configured properly for security events.
2. Configuring Audit Policies to include file monitoring.
3. Setting up individual File/Directory objects with specific audit properties through Local Policy or Group Policy, which can be accessed via Administrative Tools.
4. Enabling both Success and Failure audits for Object Access in the Local Security Settings.
5. Adjusting permissions and access settings within the Event Log to facilitate file auditing events' capture.
The configuration process is outlined step-by-step:
1. Open the Policy Editor, navigate to Local Policies -> Audit Policy.
2. Enable audit for Object Access on both Success and Failure.
3. Close the editor after adjustments are made.
4. To configure specific file or directory objects, right-click them, select properties, go to the Security tab, click Advanced, then select the Auditing tab to add individual policies.
This method ensures that all necessary configurations for auditing access to files and directories are in place, thus helping in generating Critical File Access alerts through correlation of certain events.
This text provides instructions and examples on how to set up auditing for user activities such as accessing files or modifying them using ArcSight software. To start, users are prompted to enter the name of an object (e.g., a file or directory) they want to audit. They can select specific users or groups like "Everyone," "Users," "Administrators," or a custom group like "ora_dba." The system offers autocomplete for easy selection and provides advanced options for viewing all local users and groups if needed.
After selecting the object and users, the user is asked to choose which types of accesses should be audited. A list includes various actions such as opening files, copying files, saving edits in a text editor, or appending data in a command line interface. It's important to note that this setup can produce significant noise due to many possible triggers for audit events.
The technical note provides examples of specific scenarios where auditing was effective, including opening Notepad with a file and basic operations like saving edits or appending text from the Command Prompt (CMD). However, it also highlights potential issues such as generating alerts for simple actions like accessing permission settings or using tools that preview or scan files. Furthermore, it points out that copied files will not retain auditing permissions, making them easier to copy off the system undetected.
In summary, this document outlines how to set up file access and modification auditing in ArcSight by specifying users and activities. It provides examples of effective audits for specific actions but also acknowledges potential limitations and noise generated from simple user interactions or system processes accessing files.
The technical note discusses the auditing of file changes and deletions on Windows systems using ArcSight software. It explains that files should be monitored for both modifications and deletions. For a deleted file, various events are used to track its occurrence, such as "File is read/copied," "File is changed," and "File is deleted."
The note further elaborates on the Windows File Auditing mechanism: it involves multiple events that occur instantaneously for each object access, linked by a File Handle ID. For Windows Server 2003, this information is spread across multiple events in the audit log; therefore, a correlation rule is employed to integrate these events into one correlated event. In contrast, Windows Server 2008 and later versions include more detailed content within individual events, simplifying the auditing process.
Correlation rules are set up for critical file monitoring using specific Windows Event IDs, which can be adjusted based on the requirements of an "Active List" or watchlist. This helps in reducing noise by ensuring that only files listed in the watchlist trigger alerts. The resulting dashboard provides a comprehensive overview of file access activities, with optional filters and field sets to better analyze the data.
The note also briefly mentions that similar processes apply to Linux systems, although specific details about auditing on Linux are not provided.
Linux File Monitoring is enabled by enabling and configuring the auditd module along with its associated Connector. The auditd module is native to the Linux kernel version 2.6 onwards, including RedHat 4.x and 5.x, and it allows auditing of specific files. By default, audit events are written to binary files in the /var/log structure, which can be read by a local file connector that uses audispd to convert them into readable ASCII format. Optionally, they can also be sent to syslog for further processing.
ArcSight SmartConnectors are available for both file and syslog inputs. Configuring auditd involves following the guidance provided in the Connector guides, installing the connector as needed, and ensuring that the auditd service is running before configuring specific file auditing. If the auditd service is stopped, all events will be sent to syslog by default, which may result in unparsed messages or reset file lists. Therefore, it's crucial to configure auditd according to the Connector guides and check if the auditd process is running to avoid such issues.
The auditctl tool, part of the auditd suite, is used for defining which files are audited and how extensively. For instance, adding a watch on a file or directory involves using specific commands provided in the auditctl documentation.
The text provided outlines the use of the `auditctl` command in Linux for monitoring specific files and their accesses. Here's a summarized version of what it covers:
1. **Command Overview**: For a particular file, you can issue the command `auditctl -w -p -k ` to monitor its accesses. Parameters include:
``: Specifies the full path and filename from the root directory (`/`).
``: Defines what types of access (read, write, execute) should be monitored.
``: A unique identifier for this rule.
2. **Command Reference**: The command `auditctl –l` lists all rules; replacing `-w` with `-W` in the same command removes a specific rule. It is crucial to specify all parameters when removing or changing rules, including `` and ``.
3. **Notes**:
Removing rules requires specifying all details set during creation.
Overlapping watches for different keywords are possible.
All rules can be deleted with `auditctl –D`.
Audits can be limited by UID, GID, or system calls. This is useful for defining files accessible only to specific user processes.
Changes in audit settings create a `CONFIG_CHANGE` event but do not detail the file or rule being modified.
4. **File Access Scenarios**: The command examples provided test different access scenarios:
Copying/reading a file is tested with `auditctl -w /home/arcsight/filemon_test/do_not_copy.txt -p wrx -k do_not_copy`. Tested operations include using `cat` and `cp`.
Modifying a file (`auditctl -w /home/arcsight/filemon_test/do_not_change.txt -p w -k do_not_change`) is tested with editing via `vi` and appending text to the file.
Deleting a file is not explicitly mentioned in the provided context but would follow a similar command format with `-W`.
This summary provides a concise overview of how to use `auditctl` for monitoring and managing file accesses, including commands and scenarios tested.
The command `tctl -w /home/arcsight/filemon_test/do_not_delete.txt -p rw -k do_not_delete.txt` was tested and confirmed to work with the `rm` command for Linux file monitoring in ArcSight (now known as HPE Arcsight). This command is used to monitor events related to file access, changes, and deletions on a Linux system.
On Windows, there are around 3-4 events that capture file access: one for the current working directory, one for the file handle itself, and another for the actual file action (read/write/delete). In Linux, these events include generation of logs when files are accessed, changed, or deleted. The syscall code is a numeric representation used to identify read, write, or delete actions. However, it's challenging to distinguish between copy and modify operations since their syscalls might be the same; this can be addressed by setting up specific policies (like 'r' for read) or adding files to watchlists for monitored changes.
Despite these challenges, file monitoring in Linux systems usually involves either read-only or read-write monitoring. The command `tctl` allows users to specify a path and permissions (`rw`) with an associated keyword (`do_not_delete.txt`), which helps track specific files that are not supposed to be deleted.
Key points:
1. Unix watchlists require filenames only, as paths and filenames are derived from separate events.
2. If a file is deleted, it triggers the event "File was modified" or "File was copied," depending on its status in the watchlist.
3. Attributes of files should be carefully considered when setting up monitoring, especially since actions like `ls` (listing directory contents) can generate many events due to attribute retrieval.
The technical note discusses enabling native file auditing on both Windows and Linux servers, which allows alerts to be focused and concise by integrating into Enterprise Security Manager (ESM). For Linux systems, the process involves setting up a CONFIG_CHANGE event when a file is replaced, with an audit cessation for the deleted file and start on the new one. Correlation rules are used for critical file monitoring similar to Windows events. The resultant dashboard displays overall status information using AUID/GIDs instead of usernames.
Additionally, the document covers verifying the integrity of modified files by comparing a 'gold' master set of original files with operational ones using the diff tool. This involves creating an Active List with full paths to both operational and 'gold' files, followed by setting up a correlation rule that passes filenames from the list to a diff script upon critical file changes.
Finally, the document summarizes how these native file audits can be enabled on servers and integrated into ESM for focused alerts. It also suggests further work including testing auditd with syslog delivery method and other unmentioned tests.
This document outlines a method for configuring auditing on Windows systems using Group Policy Objects (GPOs) and modifying audit rules in the auditd system to monitor specific files. The steps include verifying GPO settings related to file monitoring, adjusting auditd rules to track both access and modification events, converting audit event information into user-friendly formats, refining event categorization for better correlation with other monitored activities, adding a differential script to an ArcSight Enterprise Security Manager (ESM) content repository, and ensuring the overall configuration is functioning correctly.
The method involves several key steps:
1. Verifying GPO settings related to file monitoring by checking configurations that dictate which files should be tracked.
2. Modifying auditd rules to record both a combined path+filename for each monitored event and compare these entries with items in the Watch Active Lists (WAL).
3. Distinguishing between different types of events based on whether they are related to file access or modification, using tools like aureport which convert A/UIDs and syscall codes into usernames and descriptions.
4. Optimizing auditing by ensuring that simple actions such as an ls command does not generate a large number of individual events for each watched file, improving performance and relevance of the audit logs.
5. Adjusting event field settings to ensure correlated events are correctly categorized so they can trigger related monitoring activities within the system.
6. Implementing a differential script in the ArcSight Enterprise Security Manager (ESM) repository to enhance the critical file monitoring capabilities as outlined in the provided ARB document, which is specific to ArcSight ESM version 4.5 SP1.
Comments