More hardening possibilities

[thibaultserti]

I have found this guide https://madaidans-insecurities.github.io/guides/linux-hardening.html made by a core developer of Whonix .

It comes back on many points already implemented but also describes many others. It could be interesting to look at this and to implement some of the recommendations as bonus checks.

[jeremydenoun]

Do you think this can be a good idea to imagine a 6th (maybe more) hardening level with additional restrictive check not cover by CIS (but keep CIS+bonus check by default) ?

[thibaultserti]

I don't really understand what you mean.
Doing a category of bonus check not run by default ?
It's what we meant to do with 99.x checks, they are bonus check mentioned by CIS (but absent in the numbering), OVHcloud custom checks and checks that were present in previous CIS recommendations but that disappear in newer one.

[jeremydenoun]

Doing a category of bonus check not run by default ?

Exactly

If I understand actual logic :

• 99.x checks override existing or add new tests.
• additional tests can be selected or not (like others)
• if hardening level is defined in 99.x checks this will be respect by --set-hardening-level

My point is more organizational, the actual behavior is completly adapt to CIS, but limited to add another category of checks, this can be usefull to imagine :

• custom checks (by example in different directory) that can be embed on demand
• with a tree like

- bin/
       hardening/xxx or hardening/99.xxx (cis referential)
       custom/ovh_cloud/xxx (other referential)
       custom/xxx (other referential)

• and this can be include with --custom_checks ovh_cloud,xxx by example

This can permit to maintain different referential and add easily a role aspect.
This way can permit to generate easily some different report without play with configuration each time.

It's an idea but maybe should be study before go outside CIS checks

[jeremydenoun]

to complete point, if multiple directory tree can be complex to maintain maybe the behavior can fit with an optional CATEGORY into the configuration, this can permit to include specific category a little like HARDENING_EXCEPTION for removing

[thibaultserti]

Yeah I think that maintaining a tree like that is a bit overkill. Replacing the comment that show which category the check belongs to by a true variable will be a better choice.

[jeremydenoun]

nice thanks, so now we can come back to subject "hardening additional guides" and select which additional checks should be implemented (in standard)

It's seems this guide focus on :

• sysctl kernel/network tuning => can be relevant
• boot parameter => can be relevant
• kernel modules => partial coverage
• best practice (kernel hardening project or self compilation or hardened malloc) => complex in debian environment
• sandboxing (SELinux, apparmor) => existing CIS
• configuration + perms => some are relevant
• physical security => hard to implement

I think all tuning are not applicable to debian because seems related to newest kernel (maybe for debian 11)

[thibaultserti]

Yes I globally agree with you on the point that seems relevant.

Sandboxing is very poor in the CIS because it's hard to automatically configure or test (even more so with SELinux which has been abandoned in debian CIS 10)

On the kernel version, it seems that Debian 9 ships 4.9 by default, Debian 10 ships 4.19 by default.
With Debian11, it's likely that we get at least a 5.4 LTS kernel and maybe a 5.10 LTS.
In both case, there is indeed new kernel security features specific to this versions.

Physical security seems a bit overkill indeed.