DevOps Linux Audit(d)

June 26, 2018
Contact Us
Weekly Shorts are topics we discuss in our weekly remote meeting related to recent work we have done with our customers
DevOps Linux Audit(d)

One of the most popular tools to improve security is the CIS (Center for Internet Security) Benchmarks, particularly the CIS Distribution Independent Linux Benchmark. The CIS Linux Benchmark details important security measures that should be applied to a Linux server to make it more secure.

Section 4 of the CIS Linux benchmark talks about logging and auditing Linux systems, and mentions the do-es and don’ts with regards to logging data. For example, section specifies “Ensure audit logs are not automatically deleted” and provides sample configuration for auditd.conf.

Actually, auditd is super useful, it is a Linux daemon that logs events related to files and system calls. Any file that is changed or modified as well as any Linux system call that might be important is logged into a special log file.

CIS Sections 4.1.4 onwards detail which events a Linux system should log to ensure better security, including the rationale behind each type of event.

One example from the benchmark:

4.1.5 Ensure events that modify user/group information are

Description:Record events affecting the group, passwd (user IDs), shadow and gshadow(passwords) or /etc/security/opasswd (old passwords, based on remember parameter in the PAM configuration) files. The parameters in this section will watch the files to see if they have been opened for write or have had attribute changes (e.g. permissions) and tag them with the identifier identity in the audit log file.

Rationale:Unexpected changes to these files could be an indication that the system has been compromised and that an unauthorized user is attempting to hide their activities or compromise additional accounts.

Then the text goes and details exactly how to configure such event collection using the auditd daemon. So useful!

Normally going through such a list and ensuring each point is applied and configured on each of the company’s servers is a lot of work. Fear not!
Lucky for us, the work has already been done, so in practice, very little effort is required to comply with the benchmark.

Automatic Server Hardening Framework Chef cookbook results Chef cookbook results

The team behind “Hardening Framework” programmed most of the benchmark into InSpec rules that make it easy to “test” compliance, ensuring that the rules have been applied on a server. Moreover, created playbooks for Ansiblecookbooks for Chef, and modules for Puppet that you can use RightNow(TM) with your existing configuration management system.

The playbooks/cookbooks/modules cover the Linux base security as well as SSH, MySQL, PostgreSQL, Apache and Nginx best practices in terms of security.

Lynis from CISOFY


Another notable (free) tool to audit servers and check that they are up to par is Lynis from CISOFY. This is a command line utility that checks the server it is executed on and reports as output the basic security improvements required.

No more excuse to not have “better” security on your Linux servers.

Are you taking security into account in your DevOps activities? #DevSecOps much?

Tell us about it in the comments!

DevOps Linux Audit(d)
Evgeny Zislis
Co-Founder & CTO
Evgeny is our technology ‘capitan’, who brings simple solutions to complex problems to life for our clients. He has been helping developers become more productive and handling software packaging and deployment as well as production systems operations since 2004. He is passionate about doing things that have an impact on the bottom line, based on TOC methodology and applying DevOps to patterns and practices into any environment. He keeps himself busy organizing and speaking at meetups as well as presenting at various conferences as well as managing the Operations Israel online community on Facebook.