Auditing Linux environments using LIDS and ‘auditd’

This post was originally published here by satish dange.

If you use LIDS at all, your life is about to get easier: Recently we released nine new templates for the CloudPassage Halo log-based intrusion detection system, (LIDS) which consists of different rules/policies for ‘auditd’.

The CloudPassage Halo log-based intrusion detection system (LIDS) is a Halo security module that allows you to monitor server log files for events of interest and to receive alerts when such events occur. The module is available to Halo users on both Linux and Windows platforms. LIDS monitors system logs for any policy violation for rules specified in the Halo application. Any rule or policy violation gets a triggered display in the Halo portal based on the criticality associated to it. The event detection in this feature is policy-driven – the events that are considered to be intrusions of detections are specified by a regular expression or text pattern, which are then  assigned to the server or group for possible detection.

‘auditd’ is the Linux audit daemon for auditing Linux-based systems. It provides a way to easily track the security-related information on your Linux system. Based on the pre-configured rules (in audit.rules), auditd generates log entries to record as much as information about events that are happening in the system. These events are critical because they allow you to find suspicious  activity. auditd does not provide additional security to your system, but it can be used to discover security policy violations in your Linux system. These violations can be further prevented with additional security measures and internal organization policies.

This release consists of nine policy templates for ‘auditd’:

  1. auditd- Abnormal Activity Policy

Audit event types prepended with ANOM are classified into abnormal activity policies and are intended to be processed by intrusion detection system. These events gets triggered by abnormal end of running process by the system.

  1. auditd – Access Policy

All policies under this classification are based on access to the system for the intended user or resource to the system. Access usually defines the user accessing the system and activity performed by them.

  1. auditd – Configuration Policy

Linux system configuration is very important even though it comes with built-in security modules. An additional hardening of the system makes it more secure. The rules in this template are based on the auditd configuration and get triggered with any changes in Linux system level configuration.

  1. auditd – Cryptographic Policies

Events from various parts of a kernel that deal with cryptography are classified under this policy. Here auditd matches the system operations to user calls to the system. The rules in this template are triggered when type is CRYPTO in auditd logs.

  1. auditd – Daemon Policy

Daemon is a long-running background process that answers requests to various services. Operating systems often use daemon in multiple forms. Rules in this template are triggered when there is a change in the daemon configuration.

  1. auditd – Integrity Policy

Policies or rules that are active under this classification get triggered when there is modification in the hashes or in the kernel. This can help to improve visibility into Linux process execution and help users find suspicious activity.

  1. auditd – Malicious Activity Found

All audit event types prepended with RESP are classified in this category and are usually considered malicious by intrusion detection system.

  1. auditd – Storage Policy

Policies under this category get triggered whenever a storage device is allocated or de-allocated in the system.

  1. auditd – System Policy


System based policies are intended for system purpose. Any changes to the Linux system or anything that deals with system level events are recorded as per audit.rules packages and therefore the rules in this template get triggered on them.

Users need to configure audit.rules files and audit system configurations in order for the logs to be generated. More information on how to do that can be found here. Once that’s done, the daemon needs to be restarted in order for events to start logging into the audit.log file. Each event in the log file starts with a particular type of event text which resembles the activity being performed. Each template consists of multiple rules and the classification is based on the type of event it triggers and the action it performs. The event type specifies details about the rules that can be seen in the rule description. Apart from this more information can be gathered from the event line triggered in the  audit.log file. All rules are marked ‘active’ in the template and we recommend customers to configure the ‘Critical’ and ‘Alert’ settings as per your organization needs.

‘auditd’ is a great auditing tool that is available on the Linux system. And thanks to these recently released LIDS templates – you can now improve visibility, detect misuse, and see unauthorized activity more clearly in your Linux environments!



No posts to display