These playbooks apply the CIS benchmarks, very very useful for compliance. I use them at $dayjob to build our base AMIs.
As for whether they actually harden your servers, that's up
for you to decide if you think that CIS actually helps. It certainly does reduce attack surface.
The Linux hardening list lists quite some modifications but what hardening is made to SSH compared to a stock config? For Linux they summarize the list of hardened changes but for SSH I couldn't find it.
For SSH it's basically a list of default values with a comment saying "change this if you must". Some summary as to what is hardened compared to a stock SSH install would be nice.
About ansible: I really like the idea and popularity of ansible but find it so painful to use. YAML sucks, and testing is not straightforward (I use molecule in docker containers with geerlingguy’s spécial images)
What’s your workflow for writing tested playbooks?
I have a playbook for my dotfiles/rebuilding a personal machine from scratch. So I test that the files end up where they're supposed to be, the permissions, the packages, that whatever software I installed from source are indeed setup correctly and running, etc.
Same for roles that need to provably configure a piece of software.
8 comments
[ 0.20 ms ] story [ 19.9 ms ] threadAs for whether they actually harden your servers, that's up for you to decide if you think that CIS actually helps. It certainly does reduce attack surface.
For SSH it's basically a list of default values with a comment saying "change this if you must". Some summary as to what is hardened compared to a stock SSH install would be nice.
What’s your workflow for writing tested playbooks?
We keep our roles very simple and they will not do anything complicated. Ansible is for configuring a machine, that’s it.
If we need to do anything more complicated, we’ll write it in a testable program (usually in Go).
I have a playbook for my dotfiles/rebuilding a personal machine from scratch. So I test that the files end up where they're supposed to be, the permissions, the packages, that whatever software I installed from source are indeed setup correctly and running, etc.
Same for roles that need to provably configure a piece of software.
```
[customizations.openscap]
datastream = "/usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml"
profile_id = "xccdf_org.ssgproject.content_profile_cis"
custom_remediate_script_path = "/your/custom/script.sh"
```