Linux Hardening Checklist | Hacker News Reader

Linux Hardening Checklist

github.com

42 pointspetecooper16 comments

I'm not a fan of security checklists that don't provide an explanation or references on why something is or isn't a high priority item.

100% agree, but the first item is status: work in progress, and the second item is the todo list with 'add rationales' and links as the top issue.

The repo is five years old and hasn't been updated since its creation.

It's a bad list.

So many things here that might be good but without saying what you’re protecting against and what the tradeoffs are it’s meaningless.

Plenty of places will offer you such lists, many of which will cause more harm than good in specific circumstances

Agree but easy enough to look each up or have something like perplexity direct you to articles to verify

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.

[0] https://privsec.dev/posts/linux/desktop-linux-hardening/

Agreed. A more recent one which is quite extensive, yet a bit old, is https://madaidans-insecurities.github.io/guides/linux-harden...

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.

It's also terrible for other reasons, e.g.:

  > net.ipv6.conf.all.accept_ra=0
  > net.ipv6.conf.default.accept_ra=0

> 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.

From the link, suggestion to set hostname to `localhost`

That is probably fine, but it makes me feel uneasy. Something has to break if you do that, right?

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.

The advice in this checklist is horrendously bad and nobody should follow it. Details:

> 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:

  > echo "readonly TMOUT=900" >> /etc/profile.d/idle-users.sh
  > echo "readonly HISTFILE" >> /etc/profile.d/idle-users.sh
  > chmod +x /etc/profile.d/idle-users.sh

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.

Mounting /usr ro would make it hard to apply updates.

Missing "install Crowdstrike"

I see the rationales are on the todo. But this feels useless without it.

It would be nice if it would also mention the reason for each measure.

Reply on news.ycombinator.com