This guide ignores many sane defaults in favor of a patchwork of cargo cult scripts and outdated packages, added over time by random people with no thought for threat modeling, that may even result in an increased attack surface.
>I am not as knowledgeable about hardening/securing a Linux kernel as I'd like. As much as I hate to admit it, I do not know what all of these settings do.
Practical & real Example: "Some Robber invade a home, and steal the server (containing IMPORTANT business backups, and ownlife memories and blablabla). Not exist any disk/boot encryption. Robber have start the server on their 'safe zone' and start an bruteforce attack. He have cracked the local password by SSH with from sudoer user 'admin' success, yeah a dummy password, not THE Strong one/primary. He starts SSH session/or physical session with that cracked dummy/panic password with 'admin' sudoer. He starts feeling the server seems too much busy in less than 2 minutes until to freeze.. 'wtf!?! lets reboot and continue steal info..'.. sorry friend. all data and system was destroyed.". Conclusion, the robber cracked the dummy/panic/secondary password, and with this password its associated a script will do delete all files, config, system, boot and after than start charge the RAM and CPU to force robber reboot system.
That's...not a scenario I've focused on for my personal assets, and I'd be more worried about the duress password getting triggered by a random over- the-network brute force and losing my data, but to each his/her own.
No disk encryption, server stolen. The end. They have your data, everything else is too late. Who would ssh into a box they stole and have physical unencrypted access, no one.
Another security article recommending fail2ban again... Please don't do this.
Run SSH behind some layer. Some people use Wireguard, and that's okay, I prefer spiped [1] because I can run it as an unprivileged user in a fully hardened systemd unit [2], and I can use ProxyCommand in my ssh_config, which makes it transparent: no need to be constantly on a VPN or to turn it on, I just ssh.
This guide recommends two-factor authentication, which IMHO is overkill and lowers your server reliability by using some random pam authentication modules. Also your spiped key (or your wireguard key) can be considered a second factor authentication.
And a second independent layer lowers the probability of being vulnerable to a 0-day vulnerability on SSH [3] or to Jia Tan [4]
fail2ban means you have a daemon running as root parsing random logs and modify your firewall rules... Yikes... [5] If you're concerned about bruteforce bots, they'll go away as soon as SSH behind something. Also with that layer, you don't need to make you firewall dynamic.
[5] Yes I know, you can use as a user, and modify the firewall rules with custom script with an SUID. But nobody does this, actually this guide doesn't do this at all, just everything as root!
These types of guides are hard because they don't really have a good target group. Those who best need them are the least likely to use them. There are many like it, and they all go into lots of technical details. Some of it is really specialized.
For example, a large part of this document is IDS-related. There are long parts on AIDE, fail2ban etc. But all these tools do is provide a lot of data. You still need to make useful use of that data. That requires you to actually understand this stuff. That's not a five minute job. Whereas changing to the Mozilla recommended cryptos is trivial. As a beginner who might want to read these tutorials, you won't know the difference.
Some recommendations are a bit exclusive, too. If you run the other run, you likely won't need fail2ban. Just as most people use chrony instead of ntpd these days. And there's nothing on mandatory access control, such as SELinux, rbac or AppArmor or the various eBPF based things that has dominated Linux for the past decade.
Perhaps more useful would be a paragraph or two about how access control works on Linux and the tools to use them, just so you know what you're aiming for. The old school way of deploying server applications on unix is to give every application a unique uid and if possible run them in a chroot. That's trivial and will go a long way, systemd will already have configuration options for it.
It allows you to generate ansible or bash scripts for execution.
If you install OpenScap it comes with built-in policies, but it's always out of sync with the current version of Ubuntu, which is frustrating first time around.
For every version of Ubuntu, the default policies do not work, for e.g. in case of Ubuntu 24.04, I need to download
git clone https://github.com/complianceascode/content.git
cd content/ and ./build_product ubuntu2404 and cd ..
#Run either of the following commands:
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server --results arf1.xml --report report1.html content/build/ssg-ubuntu2404-ds.xml
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level2_server --results arf2.xml --report report2.html content/build/ssg-ubuntu2404-ds.xml
> the best modern laptops I have found are the Dell Latitude/Precision laptops with an Intel vPro Enterprise CPU. The second best group of laptops I have found are modern Lenovo Thinkpads with Intel vPro Enterprise or AMD Ryzen Pro CPUs. These are relatively easy to acquire and share these common security properties.. [firmware protection, custom CA, memory encryption, SMM mitigation, DRTM, microcode updates]
Which is more secure, carrying around your ssh private key on a USB or something so that you can connect to your server when you need to, or a long password, say a >15 character alphanumeric? and what happens if you lose your usb?
My yubikeys aren't biometric ones, so it's possible I'm wrong about what they support, but I'm pretty sure it's possible to have your SSH key on them and require both fingerprint and password to use it.
Use a passphrase. Or use a yubikey, like a sibling mentioned. I wouldn’t decrypt my secret partition on untrusted devices, conversley, if I already have a trusted machine, why bother with encrypting the secrets if they can just be sniped when I mount my partition? Regular file storage for secrets is really a bad solution - use a yubikey or a secure enclave.
If there are adversaries on the machine right now that can exploit this order, then touch+chmod is not enough. If somebody opens the file between those two operations, they can still read the file contents written to it later. It only makes a bit harder by shortening that time.
Use e.g. a current version of `install` to create files atomically with the correct permissions.
It's not the nation state actors that you need to worry about, it's the for-profit botnets. The nation-state actors have to at least pretend to have plausible deniability and so on; The botnets are so persistent and omnipresent that we can only declare them to be "internet background noise" and try to ignore them rather than admit they cannot be stopped or controlled without destroying the internet itself. They are backed by billions of dollars and millions of endpoints, and eventually they will get lucky and what was your stuff is now theirs. They are entropy, and entropy always wins.
> Application Intrusion Detection And Prevention With Fail2Ban
Please stop recommending fail2ban for securing/hardening servers and applications.
It is mentioned even it’s readme that:
> Though Fail2Ban is able to reduce the rate of incorrect authentication attempts, it cannot eliminate the risk presented by weak authentication.
It provides a false sense of security.
fail2ban only makes sense where sane defaults cannot be applied (password auth, no MFA, etc.) in some very special (and justifiable) cases, but regular self-hosters really shouldn’t host these applications. If you are targeted by a serious attacker, fail2ban’s “protection” can be easily bypassed with a large enough botnet, or simply moving on with exploiting another vulnerability/attack vector.
It has the benefit of banning bots that hammer you SSH trying to log in. Even if password auth is disabled. I've had friends that setup a small VPS and they've been hammered by bots, which can use a lot of resource on a £5/£10 VPS. Told them to install fail2ban, and the issue was solved in a few minutes.
Good security is about having multiple layers of defense. Fail2Ban protection is one of those layers.
> It has the benefit of banning bots that hammer you SSH trying to log in. Even if password auth is disabled.
You can use the built-in firewall for that (`ufw limit ssh`).
> I've had friends that setup a small VPS and they've been hammered by bots, which can use a lot of resource on a £5/£10 VPS.
`ufw limit ssh` solves this as well, performant, efficient, nothing else needed than the built-in firewall. If you are targeted by a botnet, fail2ban will solve nothing.
> Good security is about having multiple layers of defense. Fail2Ban protection is one of those layers.
Let me quote again the readme of fail2ban: "Set up services to use only two factor, or public/private authentication mechanisms if you really want to protect services."
True defense in depth means choosing effective layers, not putting arbitrary layers on top of each other. Defense in depth doesn't mean every possible layer is good.
You want layers that meaningfully improve your security posture without adding unnecessary complexity or false confidence.
It's missing the basics: encrypt your disks and store the key on the TPM, so that you don't even know it and it can be used to automatically the decrypt the disk on boot.
I am against the key in tpm. If they steal the whole box, your data is theirs. Disk encryption with key in tpm is like locking your door but intentionally leaving the keys in the door
Stolen or lost disks, obviously. More practically when the disk dies or replaced for other reason, you don't have to worry about the contents, because it's all random.
This guide ignores many sane defaults in favor of a patchwork of cargo cult scripts and outdated packages, added over time by random people with no thought for threat modeling, that may even result in an increased attack surface.
See this comment from 2019: https://news.ycombinator.com/item?id=19178938
I will leave you with this line from README.md:
>I am not as knowledgeable about hardening/securing a Linux kernel as I'd like. As much as I hate to admit it, I do not know what all of these settings do.
Are there any alternative resources you would recommend?
"Linux Kernel Defence Map - Security Hardening Concepts", https://news.ycombinator.com/item?id=43597264
"Linux Kernel Hardening Checker" (2023), https://news.ycombinator.com/item?id=37709349
They did a little threat modeling:
That's...not a scenario I've focused on for my personal assets, and I'd be more worried about the duress password getting triggered by a random over- the-network brute force and losing my data, but to each his/her own.No disk encryption, server stolen. The end. They have your data, everything else is too late. Who would ssh into a box they stole and have physical unencrypted access, no one.
Just quickly skimming it, it contains several outdated blocks of advice and omits other topics.
The most glaring one is the recommendation to use `rng-tools`, which is not needed anymore for the past couple of years.
It was written 6 years ago, and at that point it probably was not great either?
Another security article recommending fail2ban again... Please don't do this.
Run SSH behind some layer. Some people use Wireguard, and that's okay, I prefer spiped [1] because I can run it as an unprivileged user in a fully hardened systemd unit [2], and I can use ProxyCommand in my ssh_config, which makes it transparent: no need to be constantly on a VPN or to turn it on, I just ssh.
This guide recommends two-factor authentication, which IMHO is overkill and lowers your server reliability by using some random pam authentication modules. Also your spiped key (or your wireguard key) can be considered a second factor authentication.
And a second independent layer lowers the probability of being vulnerable to a 0-day vulnerability on SSH [3] or to Jia Tan [4]
fail2ban means you have a daemon running as root parsing random logs and modify your firewall rules... Yikes... [5] If you're concerned about bruteforce bots, they'll go away as soon as SSH behind something. Also with that layer, you don't need to make you firewall dynamic.
[1] https://www.tarsnap.com/spiped.html
[2] https://ruderich.org/simon/notes/systemd-service-hardening
[3] https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion....
[4] https://en.wikipedia.org/wiki/XZ_Utils_backdoor
[5] Yes I know, you can use as a user, and modify the firewall rules with custom script with an SUID. But nobody does this, actually this guide doesn't do this at all, just everything as root!
Jia Tan already has her code running on your machine, no second layer of auth will help that.
Spipe/vpn makes it so you cannot just connect via any machine, which sometimes is not helpful.
These types of guides are hard because they don't really have a good target group. Those who best need them are the least likely to use them. There are many like it, and they all go into lots of technical details. Some of it is really specialized.
For example, a large part of this document is IDS-related. There are long parts on AIDE, fail2ban etc. But all these tools do is provide a lot of data. You still need to make useful use of that data. That requires you to actually understand this stuff. That's not a five minute job. Whereas changing to the Mozilla recommended cryptos is trivial. As a beginner who might want to read these tutorials, you won't know the difference.
Some recommendations are a bit exclusive, too. If you run the other run, you likely won't need fail2ban. Just as most people use chrony instead of ntpd these days. And there's nothing on mandatory access control, such as SELinux, rbac or AppArmor or the various eBPF based things that has dominated Linux for the past decade.
Perhaps more useful would be a paragraph or two about how access control works on Linux and the tools to use them, just so you know what you're aiming for. The old school way of deploying server applications on unix is to give every application a unique uid and if possible run them in a chroot. That's trivial and will go a long way, systemd will already have configuration options for it.
There is OpenScap based ComplianceAsCode. See https://github.com/ComplianceAsCode/content It has implementations for CIS Level 1 & 2 benchmark. Supports NIST, ...
It allows you to generate ansible or bash scripts for execution.
If you install OpenScap it comes with built-in policies, but it's always out of sync with the current version of Ubuntu, which is frustrating first time around.
For every version of Ubuntu, the default policies do not work, for e.g. in case of Ubuntu 24.04, I need to download
Debian's guide was great when it was written [0], but it's so stale now. I wish someone had the time/need to update it at times.
[0] https://www.debian.org/doc/manuals/securing-debian-manual/in...
They're trying to resurrect that project. See this thread https://lists.debian.org/debian-security/2025/06/msg00001.ht...
Secure every endpoint that is authorized to administer the server/cloud, https://4fa2b80c.privsec-dev-2oz.pages.dev/posts/knowledge/l...
> the best modern laptops I have found are the Dell Latitude/Precision laptops with an Intel vPro Enterprise CPU. The second best group of laptops I have found are modern Lenovo Thinkpads with Intel vPro Enterprise or AMD Ryzen Pro CPUs. These are relatively easy to acquire and share these common security properties.. [firmware protection, custom CA, memory encryption, SMM mitigation, DRTM, microcode updates]
Which is more secure, carrying around your ssh private key on a USB or something so that you can connect to your server when you need to, or a long password, say a >15 character alphanumeric? and what happens if you lose your usb?
Buy a Yubikey/Nitrokey. Get a second one and store it in a safe place in case you lose the first one.
Use gpg-agent with an yubikey (a hassle to configure), or the ssh-agent from openssh with passkey on yubikey (easy to configure).
Require a touch to sign, put a password on the key if your paranoid, if you really paranoid disconnect the yubikey when not in use.
Passphrase for the SSH key.
Something you are, something you have, something you know
I don't know if I can put biometric security in my ssh session
My yubikeys aren't biometric ones, so it's possible I'm wrong about what they support, but I'm pretty sure it's possible to have your SSH key on them and require both fingerprint and password to use it.
https://www.yubico.com/products/yubikey-bio-series/
(And I'm sure they're not the only company who makes such devices, they're just the one I'm familiar with myself.)
Some iOS/Mac SSH clients allow SSH keys to be protected by TouchID or FaceID, https://news.ycombinator.com/item?id=15853345
Might be possible on other systems with a fingerprint reader and TPM, https://news.ycombinator.com/item?id=36920105
You absolutely can.
https://linux.die.net/man/8/pam_thinkfinger
You can do that on Macs with Touch ID
Backup the private keys, use encrypted USB keys with strong passwords and store the private keys there.
but what if someone cracks the password on my usb stick?! I'll have to store complex encryption keys for one usb on another usb
Use a passphrase. Or use a yubikey, like a sibling mentioned. I wouldn’t decrypt my secret partition on untrusted devices, conversley, if I already have a trusted machine, why bother with encrypting the secrets if they can just be sniped when I mount my partition? Regular file storage for secrets is really a bad solution - use a yubikey or a secure enclave.
I think it's more secure to store the password on USB.
Brave soul to be writing something like that.
One universal truth I’ve learned on security is that regardless of what you do someone will always very loudly tell you how wrong you are
Should touch and chmod files (.msmtprc and /etc/exim4/passwd.client) BEFORE adding sensitive content to them.
There might be other instances in the how-to, I didn't read it all.
If there are adversaries on the machine right now that can exploit this order, then touch+chmod is not enough. If somebody opens the file between those two operations, they can still read the file contents written to it later. It only makes a bit harder by shortening that time.
Use e.g. a current version of `install` to create files atomically with the correct permissions.
Security is like football. If you repeatedly practice the boring basics (blocking, tackling, running, etc.) you will win.
Patch, backup, use keys for remote access (rather than passwords) and you will win the security game.
It's pretty simple, but everyone hates the basics and would rather obsess over advanced nation state actors and other similar bullshit.
That's like worrying about being bitten by a Black Mamba and not wearing a seat belt while driving a car.
It's not the nation state actors that you need to worry about, it's the for-profit botnets. The nation-state actors have to at least pretend to have plausible deniability and so on; The botnets are so persistent and omnipresent that we can only declare them to be "internet background noise" and try to ignore them rather than admit they cannot be stopped or controlled without destroying the internet itself. They are backed by billions of dollars and millions of endpoints, and eventually they will get lucky and what was your stuff is now theirs. They are entropy, and entropy always wins.
[dead]
Way too informative. You don't need to explain every simple step.
> Application Intrusion Detection And Prevention With Fail2Ban
Please stop recommending fail2ban for securing/hardening servers and applications.
It is mentioned even it’s readme that:
> Though Fail2Ban is able to reduce the rate of incorrect authentication attempts, it cannot eliminate the risk presented by weak authentication.
It provides a false sense of security.
fail2ban only makes sense where sane defaults cannot be applied (password auth, no MFA, etc.) in some very special (and justifiable) cases, but regular self-hosters really shouldn’t host these applications. If you are targeted by a serious attacker, fail2ban’s “protection” can be easily bypassed with a large enough botnet, or simply moving on with exploiting another vulnerability/attack vector.
It has the benefit of banning bots that hammer you SSH trying to log in. Even if password auth is disabled. I've had friends that setup a small VPS and they've been hammered by bots, which can use a lot of resource on a £5/£10 VPS. Told them to install fail2ban, and the issue was solved in a few minutes.
Good security is about having multiple layers of defense. Fail2Ban protection is one of those layers.
> It has the benefit of banning bots that hammer you SSH trying to log in. Even if password auth is disabled.
You can use the built-in firewall for that (`ufw limit ssh`).
> I've had friends that setup a small VPS and they've been hammered by bots, which can use a lot of resource on a £5/£10 VPS.
`ufw limit ssh` solves this as well, performant, efficient, nothing else needed than the built-in firewall. If you are targeted by a botnet, fail2ban will solve nothing.
> Good security is about having multiple layers of defense. Fail2Ban protection is one of those layers.
Let me quote again the readme of fail2ban: "Set up services to use only two factor, or public/private authentication mechanisms if you really want to protect services."
True defense in depth means choosing effective layers, not putting arbitrary layers on top of each other. Defense in depth doesn't mean every possible layer is good.
You want layers that meaningfully improve your security posture without adding unnecessary complexity or false confidence.
It's missing the basics: encrypt your disks and store the key on the TPM, so that you don't even know it and it can be used to automatically the decrypt the disk on boot.
I am against the key in tpm. If they steal the whole box, your data is theirs. Disk encryption with key in tpm is like locking your door but intentionally leaving the keys in the door
What threat does this protect against?
Stolen or lost disks, obviously. More practically when the disk dies or replaced for other reason, you don't have to worry about the contents, because it's all random.
Accessing all of your data without any authentication by anyone who gets physical access to your machine/server/computer.
It protects against people imagining your disks and reading them / asking you for the encryption key / brute forcing the encryption key.
Interesting guide on how to protect Linux server!