Detect insider threats with Linux auditing

556

Author: Shawn Hermans

Organizations of all sizes need to mitigate the risk of insider threats. Misconduct by authorized users represents a grave threat to an organization. According to the 2005 Computer Security Institute and Federal Bureau of Investigation Computer Crime and Security Survey, organizations reported that computer intrusions from inside sources accounted for nearly half of all incidents. You can secure your network perimeter with intrusion detection systems, firewalls, and virus scanners, but don’t neglect to monitor authorized users. The Linux Audit daemon can help you detect violations of your security policies.

The term auditing has multiple meanings within the information security field. A security audit is a term used to describe the process of evaluating the security posture of an organization through penetration testing, review of security policies, and system configuration. At the system level, auditing refers to the logging of the actions of users and programs of a system. The latter form of auditing is the type of auditing implemented by the Linux Audit daemon. It is a passive security measure because it only detects violations of security policy, but does not enforce it. It is similar to network-based intrusion detection systems and host-based intrusion detection systems.

At its most basic level, the audit daemon is capable of monitoring all system calls made to the kernel. System calls are how user space programs use functions of the kernel. As the kernel provides the lowest-level access to system resources, every application must make a system call, either directly or indirectly. Additionally, the audit daemon integrates with Security-Enhanced Linux (SELinux) and can log violations of SELinux policy.

Because the audit daemon is a part of the Linux kernel, it is included in most major Linux distributions by default. Being a part of the kernel also has the advantage of lower overhead and being more difficult to bypass. The fact that it lacks the additional features of similar software is a design decision. The daemon needs to be simple in order to pass stringent security evaluations.

Deciding what to audit

While there are hundreds of system calls, you shouldn’t monitor every one. The most interesting system calls (from a security perspective) are those involving opening and closing files, changes to file permissions and ownership, mounting and unmounting of filesystems, and changes to the system time. The audit daemon has built-in functions to watch access attempts to files without needing to monitor the applicable system calls.

Deciding what to audit is dependent upon the requirements of each organization. By default, the daemon logs violations of SELinux policy. The source package of the audit subsystem includes contributed audit configuration rules that provide a useful baseline. Among them are rules to watch access to system files of interest, changes in file permission, changes to locations of files, and mounting and unmounting of filesystems.

Administrators can add additional rules by amending the provided configuration files or at the runtime using the command line. The default location for the audit daemon rules is /etc/auditd/audit.rules. The daemon loads this file at run time. Each line represents a different rule. For example, the rule -w /var/log/audit/audit.log tells the audit daemon to watch access attempts to the audit.log file. The auditctl command-line tool adds rules during runtime without the need modify the rules configuration file. The manual page for this tool describes the auditing rules in more detail.

Using audit events

The audit daemon adds events to the audit log file as they occur. By default, the system stores audit logs in /var/log/audit/. Audit logs are similar to system logs in many ways. They both store their files in the /var/log directory, both can send their logs to a remote syslog server, and both can rotate their log files. The difference between them is that the audit system does not rely on userspace programs to generate logs. The audit daemon is a part of the kernel and therefore is difficult to bypass without the use of a rootkit.

Two command-line tools can parse audit log files. The ausearch tool queries the audit logs based upon supplied search criteria and returns log entries that match those criteria. The aureport tool produces reports on failed login attempts, configuration changes, watched files, and other events of interest. An administrator can combine these tools with other commands to produce powerful shell scripts.

If administrators require more advanced parsing of audit logs, they can code programs that call the Audit Event Parsing Library to parse audit events. This library has C and Python interfaces. The packages audit-libs and audit-libs-python contain the Audit Event Parsing Library, and you can download them through your distribution’s package manger.

The Audit Dispatcher is a feature of the auditing system that allows external applications, such as intrusion detection systems, to access the audit daemon in real time. Eventually, the Audit Dispatcher could allow host-based intrusion detection devices, such as OSSEC, to use the audit daemon to provide enhanced intrusion detection.

One third-party tool of interest is the System iNtrusion Analysis and Reporting Environment (Snare). It provides a graphical interface to configure auditing rules, as well as graphical reporting mechanisms. It also has products available for other operating systems and is able to log audit logs from multiple platforms to a single server.

When you implement auditing, establish an audit log retention policy. In order to use audit logs in legal proceedings, they must be part of a normal business process. Without regular processes in place, audit logs are not business records and therefore are hearsay in legal proceedings. For retaining audit records of multiple machines, consider using a centralized log server. A centralized server also facilitates analysis of audit logs from multiple machines simultaneously.

Conclusion

While auditing may not be sexy, it is an important layer of defense in the architecture of any computer network. It can detect violations of security policy and provide a useful tool for refining security measures. When combined with network-based intrusion devices, secure system configuration, and active security measures, auditing helps to secure Linux from both internal and external threats.

Categories:

  • System Administration
  • Security