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 18.104.22.168 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
collectedDescription: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.
The team behind dev-sec.io “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, dev-sec.io created playbooks for Ansible, cookbooks 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.
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!