![]() ![]() # The rules are simply the parameters that would be passed # to auditctl # First rule - delete all -D # Increase the buffers to survive stress events. The listing below shows an example of the les file after it has been updated by osquery: # This file contains the auditctl rules that are loaded # whenever the audit daemon is started via the initscripts. This post is only concerned with control and system call (syscall) rules. System call rules: allow logging of system calls that any specified program makes.File system rules: also known as file watches, allow the auditing of access to a particular file or a directory.Control rules: allow the audit system’s behavior and some of its configuration to be modified.There are 3 different types of audit rules: Auditing is configured and managed through a set of rules that are stored on the filesystem (usually in a subdirectory of /etc/audit). The auditing functionality that exists in the Linux kernel today was introduced around version 2.6 of the Linux kernel, with the primary goal of allowing better introspection into security relevant operating system events such as file modifications and system calls. Before we begin talking about osquery, we’ll explain how the audit subsystem functions. Both daemons process incoming audit events generated by the audit subsystem and generate output that is intended to be logged or processed in some way. With regards to auditing, both osquery and auditd serve a nearly identical role. Auditd: The userland daemon responsible for collecting audit events and logging them (usually to the filesystem).Audit Consumer: A userland application that processes audit events emitted from the kernel such as auditd or osquery.Auditing: The process of using the audit subsystem to generate audit events for auditing purposes.Audit Framework/Subsystem: The audit component within the Linux kernel that generates audit messages based on a configurable rule set. ![]() To summarize the terminology that we’ll use throughout these posts: When we talk about “auditing,” we are referring to a program that processes (and usually logs) audit events that originate from the audit subsystem within the kernel. To begin, we’ll clearly define the terminology that we use throughout this post. This post will describe how auditing works under the hood and provide pragmatic guidance on how to implement and fine tune auditing configurations. Additionally, improperly configured auditing can result in incomplete data, which can make detection and alerting programs less effective. Without a deeper understanding of how osquery’s auditing functionality operates, users may encounter performance issues, resource conflicts, and troubleshooting woes. However, we’ve observed that many people attempt to enable these features without fully understanding the underlying mechanisms and performance implications. In osquery terminology, these features are commonly referred to as process and socket auditing. One of osquery’s most powerful features is its ability to record process executions and network connections. Part two focusses on concrete osquery configuration and implementation steps. This post lays the foundation by expanding on the basic concepts of the Linux Audit Framework. This blog post is the first in a two-part series where we will cover osquery’s auditing features in depth. In osquery Across the Enterprise, we report a high-level overview of deploying osquery in a large environment, but touched only briefly on implementation details. ![]()
0 Comments
Leave a Reply. |