Investigating container security with auditd

Container Check

Thanks to the unremitting, ever-present threat of a multitude of attacks to which a Linux system can be subjected, it's critical to capture important changes and events made by users and processes on your running systems.

Highlighting such changes could potentially point toward something as innocuous as a simple misconfiguration but, equally, might proactively help stop an impending attack dead in its tracks. Additionally, having trustworthy, detailed logging data is exceptionally useful for post-event forensic analysis, especially when you are trying to discern how an attacker originally managed to compromise your system and get a foothold.

One such package I have been using recently on a large AWS server estate is called auditd . Its man page states: "auditd is the userspace component to the Linux Auditing System."

One of the pages on the Linux Audit Documentation project GitHub site describes its (very old) original design as being based around the following aims:

 

The main goals were to provide system call auditing 1) with as low overhead as possible and 2) without duplicating functionality that is already provided by SELinux (and/or other security infrastructures).

 

For the uninitiated, "system calls," which are more commonly referred to as "syscalls," occur when processes ask the kernel for a hand with something. The syscalls man page reports, "The system call is the fundamental interface between an application and the Linux kernel."

Simply think of every task, such as opening a socket for network communications, mounting a disk volume, or even creating a directory, as needing some form of assistance and therefore validation from a host's kernel. In many cases, a handling program like the all-pervasive glibc (GNU C Library) will invoke the syscall directly and not the underlying application that is asking for

... comments powered by Disqus