I doubt a 5 year old hardening is any relevant today. I would stick to a well researched article like Privsec[0] where they explain the reasoning for each step.
What I want is an accompanying example Ansible playbook for at least one distribution so I can understand the reasoning behind each step and still do it all with a single command.
That one is no good because it tries to normalize DRM and tivoization by pretending they're for "security". E.g., it says to set kernel.kexec_load_disabled=1, debugfs=off, module.sig_enforce=1, and lockdown=confidentiality, all of which only restrict the root user.
> Malicious IPv6 router advertisements can result in a man-in-the-middle attack, so they should be disabled.
But that's the main way to configure IPv6. The IPv4 equivalent of that advice would be to disable your DHCP client, since malicious DHCP servers can result in a man-in-the-middle attack.
And it also has the same horrendous advice for PAM to require the kinds of passwords that we now know reduce security.
I thought about developing a community based open (CC0 licensed) hardening standard and tool which allows giving more details about the system to be hardened to cover even more hardening options. I'm working as an Information Security Auditor and most companies I have audited are using CIS standards for this. While they are free, they are proprietary and you are not allowed to build products on top of these standards. Additionally these standards are relatively generic and I don't know anybody who knows the decision process on their standards. Also, the Windows standards doesn't even recommend using Windows application allowlisting functionalities such as AppLocker or WDAC.
Mounting /usr read-only will break system updates, and it's worthless from a security perspective, since nothing in /usr is writable by anyone but root, and root is capable of remounting it read-write. Ditto for the same advice about /boot. Also, nodev is only useful on things unprivileged users can mount, like external media, since on internal partitions like /usr, once again, only root can do mknod, and root can remove the nodev mount option too.
Setting hidepid=2 is a really, really breaking change. I'd never even consider doing that on a production system without extensively testing every piece of it with that on first. And since it's only security-through-obscurity and not real security, it's approximately never worth doing so.
> Polyinstantiated directories
A really common use case of /tmp and /var/tmp is to transfer files between local user accounts, when your home directory is something like a Kerberized NFS mount where you can't give each other direct access. Polyinstantiating those directories breaks that.
> Protect Single User Mode with root password. Example: # Edit /etc/sysconfig/init. SINGLE=/sbin/sulogin
This is actively harmful for security, because now you need to give the root account a password and leave it unlocked, instead of having it locked out and only allowing root access via sudo. And the protection it does offer is trivially bypassable by, e.g., a LiveUSB boot.
ExecShield tries to emulate the NX bit on x86 CPUs that don't have it. All such CPUs are now so old that unless you're doing something like https://yeokhengmeng.com/2018/01/make-the-486-great-again/, any system where it makes sense to use this is so old that the software you'll be running on it will be full of unpatched critical security holes.
This is exactly the kind of password advice that NIST has now has been admitting is harmful for years. You shouldn't require special characters, and you shouldn't require 60-day password changes.
This fundamentally misunderstands what logout means. If you're logged in to a graphical session and have a bunch of terminal windows open, you don't want each one closing after 15 minutes of idle in itself. And it doesn't even work; if you're idle in a text editor or something, that won't do anything. And it has nothing to do with HISTFILE, so I'm not sure why that's included at all.
> unlock_time=never
This neglects the availability component of the CIA triad. Now it's trivial for an attacker to DoS your system by locking out all of your accounts at once.
> Disable uncommon filesystems.
All EFI hosts need an EFI System Partition that uses vfat, so it's definitely not uncommon. This error is so obvious that it makes me doubt the rest of this list.
18 comments
[ 3.0 ms ] story [ 58.7 ms ] threadIt's a bad list.
Plenty of places will offer you such lists, many of which will cause more harm than good in specific circumstances
[0] https://privsec.dev/posts/linux/desktop-linux-hardening/
It's also terrible for other reasons, e.g.:
> Malicious IPv6 router advertisements can result in a man-in-the-middle attack, so they should be disabled.But that's the main way to configure IPv6. The IPv4 equivalent of that advice would be to disable your DHCP client, since malicious DHCP servers can result in a man-in-the-middle attack.
And it also has the same horrendous advice for PAM to require the kinds of passwords that we now know reduce security.
That is probably fine, but it makes me feel uneasy. Something has to break if you do that, right?
> Restrict /usr partition mount options. Example: UUID=<...> /usr ext4 defaults,nodev,ro 0 2
Mounting /usr read-only will break system updates, and it's worthless from a security perspective, since nothing in /usr is writable by anyone but root, and root is capable of remounting it read-write. Ditto for the same advice about /boot. Also, nodev is only useful on things unprivileged users can mount, like external media, since on internal partitions like /usr, once again, only root can do mknod, and root can remove the nodev mount option too.
> Restrict /proc partition mount options. Example: proc /proc proc defaults,hidepid=2 0 0
Setting hidepid=2 is a really, really breaking change. I'd never even consider doing that on a production system without extensively testing every piece of it with that on first. And since it's only security-through-obscurity and not real security, it's approximately never worth doing so.
> Polyinstantiated directories
A really common use case of /tmp and /var/tmp is to transfer files between local user accounts, when your home directory is something like a Kerberized NFS mount where you can't give each other direct access. Polyinstantiating those directories breaks that.
> Protect Single User Mode with root password. Example: # Edit /etc/sysconfig/init. SINGLE=/sbin/sulogin
This is actively harmful for security, because now you need to give the root account a password and leave it unlocked, instead of having it locked out and only allowing root access via sudo. And the protection it does offer is trivially bypassable by, e.g., a LiveUSB boot.
> chmod og-rwx /etc/grub.conf chmod -R og-rwx /etc/grub.d
Seems like security through obscurity. Nothing sensitive belongs in either of those places.
> ExecShield protection. Example: echo "kernel.exec-shield = 2" > /etc/sysctl.d/50-exec-shield.conf
ExecShield tries to emulate the NX bit on x86 CPUs that don't have it. All such CPUs are now so old that unless you're doing something like https://yeokhengmeng.com/2018/01/make-the-486-great-again/, any system where it makes sense to use this is so old that the software you'll be running on it will be full of unpatched critical security holes.
> Update password policy (PAM). Secure /etc/login.defs password policy.
This is exactly the kind of password advice that NIST has now has been admitting is harmful for years. You shouldn't require special characters, and you shouldn't require 60-day password changes.
> Set auto logout inactive users. Example:
This fundamentally misunderstands what logout means. If you're logged in to a graphical session and have a bunch of terminal windows open, you don't want each one closing after 15 minutes of idle in itself. And it doesn't even work; if you're idle in a text editor or something, that won't do anything. And it has nothing to do with HISTFILE, so I'm not sure why that's included at all.> unlock_time=never
This neglects the availability component of the CIA triad. Now it's trivial for an attacker to DoS your system by locking out all of your accounts at once.
> Disable uncommon filesystems.
All EFI hosts need an EFI System Partition that uses vfat, so it's definitely not uncommon. This error is so obvious that it makes me doubt the rest of this list.