Features: Auditing - Page 6 - Results from #5

Advisories

Feature Articles

Need an in-depth introduction to a new security topic? Our features articles will bring up up-to-date on everything from buffer overflows to SE Linux policy development.

Discover LinuxSecurity Features

Verifying Linux Server Security: What Every Admin Needs to Know - Auditing

 

Auditing

Conducting frequent audits is an essential part of establishing the security of your Linux servers. System auditing enables administrators to discover security bugs, breaches or policy violations on their systems. In this section, we’ll take a look at the Linux Auditing System (AuditD) and the insight that this valuable feature can provide administrators into the security, stability and functionality of their systems. 

What is the Linux Auditing System?

The Linux Auditing System (AuditD) is a native feature to the Linux kernel that collects information on system activity to facilitate the investigation of potential security incidents. AduditD works on the kernel level - where it can oversee all system processes and activities - and uses the AuditD daemon to log what it finds. In most Linux distributions, AuditD is installed by default and runs automatically with the system. It logs information according to its auditing rules as well as any rules that have been added. AuditD monitors three categories of events: system calls, file access and select, pre-configured auditable events within the kernel. It enables administrators to audit activity using these categories of events including authentications, failed cryptographic operations, abnormal terminations, SELinux modification and program execution. When any of the audit rules in place is triggered, AuditD outputs a comprehensive record that can be used to investigate the incident.

When implementing the Linux Auditing System, you will likely need to create some of your own rules. There are two types of rules that administrators can write: file system and system call rules. Other system activities including specific scripts executed, userland events and internal kernel behaviors that can be triggered independently of syscalls are out of the scope of AuditD. When writing rules, it is critical to remember that audit rules work on a “first match wins” basis. In other words, once audited activity matches a rule, no further rules will be evaluated. Thus, the order in which rules are written is of utmost importance.

To view the audit records generated by a triggered rule, administrators can use the native ausearch and aureport utilities. Ausearch lets you search your audit log files for specific criteria, while aureport creates summary reports from the audit log files. 

It is crucial for administrators to ensure that AuditD is properly configured and hardened to provide genuine, reliable information. Begin by checking that AuditD’s configuration is immutable using the control option “-e 2”. Then, confirm that logs are stored in a centralized, secure location - ideally a server dedicated to accepting remote syslog events.

AuditD is a very useful - and free - feature for facilitating investigations, especially historical investigations in response to an incident. That being said, AuditD does have some serious weaknesses that should be taken into consideration - namely, bugginess, excessive overhead, lack of granularity, missing container support and onerous output.

Learn how to install and configure AuditD, create rules, and view the AuditD log file in this TechRepublic tutorial.

Comments (0)

There are no comments posted here yet
Please enable / Bitte aktiviere JavaScript!
Veuillez activer / Por favor activa el Javascript![ ? ]

We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.