CIS Hardening of a Debian Linux Server Part 11: Conclusion

This is the last entry in the series documenting the Debian 13 server CIS hardening project.

Benchmark Coverage #

Coverage spans all Level 1 and Level 2 recommendations, with the exception of a small set explicitly skipped by design. The approach taken was to apply every applicable recommendation first, and revisit any that could interfere with a future function of the server afterward.

The following recommendations were not applied, by design:

  • 1.7.2 to 1.7.11: GDM is not installed on the system. The benchmark states this section can be skipped when GDM is absent.
  • 2.3.3: systemd-timesyncd is the time synchronization method in use. The benchmark states that when systemd-timesyncd is used, chrony should be removed and this section skipped.
  • 6.1.1.1.4 and 6.1.1.2: rsyslog is the chosen method for client-side logging, not journald. The benchmark states these recommendations apply only when journald is the chosen method, and should not be applied when rsyslog is used instead.

Benchmark Discrepancies #

The items below are not necessarily framed as errors on the benchmark’s part. They are documented here as things to watch for in future implementations or automation endeavors, encountered over the course of this project.

  • 1.1.1.11: the remediation script’s logic does not account for modules located in nested subdirectories beneath kernel/fs/.
  • 1.5.10: duplicates 1.5.3.
  • 1.5.11: the regex in the example remediation command does not account for the value infinity.
  • 1.5.12: the audit script hangs when the file /etc/systemd/coredump.conf does not exist.
  • 5.1 and 6.1.2.5: the text contains RHEL-specific references not applicable to a standard Debian 13 installation.
  • 6.1.2.6: the regex in the second audit check expects action( and target= to appear on the same line, which is not always the case.
  • 6.1.3.1: a typo exists in both the audit and remediation scripts. In the second branch of the case statement, the function called should be f_file_test_chk, not file_test_chk.
  • 6.2.2.4: the halt option for space_left_action is deprecated according to the man page, but is still treated as a passing state by the benchmark.
  • 6.2.3.8: /etc/netplan does not necessarily exist.
  • 6.2.3.9: /etc/NetworkManager does not necessarily exist.
  • 6.2.3.22: /var/run/utmp is not present by default on Debian 13.
  • 6.2.3.34: the query_module and create_module system calls are both deprecated according to their man pages.
  • 6.2.3.36: the example remediation printf command leaves no trailing newline, which can lead to an error.

Lynis Runs #

Only the benchmark’s own recommendations were applied throughout this project. Lynis’s warnings and suggestions were not factored into any remediation decision. Running Lynis at the end of each section was a side experiment, not a validation or evaluation metric; the verification method throughout remains the benchmark’s own audits.

All runs, with their resulting hardening index:

  • Baseline Run: 65
  • Level 1 Initial Setup: 68
  • Level 1 Services: 68
  • Level 1 Network: 69
  • Level 1 Host Based Firewall: 69
  • Level 1 Access Control: 72
  • Level 1 Logging and Auditing (System Logging): 72
  • Level 1 Logging and Auditing (Integrity Checking): 74
  • Level 1 System Maintenance: 74
  • Level 2 Initial Setup: 78
  • Level 2 Services to Access Control: 78
  • Level 2 Logging and Auditing: 79

The Need for Automation #

Manual implementation of the recommendations takes significant time and effort. Redoing the same work across multiple machines is impractical at best. The natural course of action is therefore to incorporate automation solutions such as Ansible.

This should not be approached blindly, however. As evidenced by the discrepancies listed above, an automated implementation applied without review would silently inherit the same quirks and limitations. Effective automation must account for these, in addition to the configuration, software, and operational requirements of the systems to which the recommendations are being applied.

CIS Hardening as a Baseline #

As the benchmark itself notes, compliance with its guidance is a starting point, not a complete end state. Continuous monitoring and maintenance remain necessary to maintain and improve upon the security posture established here.