As a *nix sysadmin since before Google was a thing, I find articles like this frustrating and arguably dangerous.<p>They lay out a set of "rules" the author has collated as a dogmatic doctrine that only a fool would not follow. But they provide no "why", take absolutely no context in to account, and talk only about their perceived upsides.<p>Anyone reading this should take each point as "here's a possible thing you should go and research yourself", because there are consequences to most of these rules.<p>I'm not saying anything they've written is wrong (though there is a lot of unsubstantiated opinion there), just that you should learn what any of these changes truly do before implementing them AND that your particular context is really important.<p>Edit:<p>There is a disclaimer at the top which mustn't be forgotten while reading.<p>> DISCLAIMER: Do not attempt to apply anything in this article if you do not know exactly what you are doing. This guide is focused purely on security and privacy, not performance, usability, or anything else.<p>I do appreciate people putting work into producing this sort of content, but I think the article could be improved by phrasing the various steps as suggestions and perhaps linking out to more detailed documentation on the "why" elsewhere.
Some omissions IMO: never let people SSH in with a password, and for the love of god, stop leaving private SSH keys on servers. Privat SSH keys should never leave your physical proximity. They should be on your laptop, or desktop, or your yubikey, but never on servers. Also SSH agent forwarding is the devil. Don't do it.<p>Lots of really braindead advice in there too, like disabling RDRAND because there might be a backdoor.. come on.. even Linus knows that's obvious bullshit.[1]<p>[1] <a href="https://nakedsecurity.sophos.com/2013/09/11/rudest-man-in-linuxdom-rants-about-randomness-we-actually-know-what-we-are-doing-you-dont/" rel="nofollow">https://nakedsecurity.sophos.com/2013/09/11/rudest-man-in-li...</a>
This list is cool, but I think it would be more useful with some quick notes on side effects. I think all but the most hardcore Linux lovers won't have enough breadth and depth to understand the full ramifications of many of these config changes.<p>I'm no Linux expert but even having used it for a fair number of years, I only have a shallow understanding of most of the things that are tweaked here, if I've even heard of them at all. For example, it says "kernel.kexec_load_disabled=1", and points out the threat which I can understand, but I don't know what that's used for in the first place. Perhaps it isn't really ever used for anything, but it'd be nice to be told that, because my initial line of thinking is that these defaults must be defaults for a reason and that makes me hesitant to actually make any of the changes.
Most of the ideas are good but I think you need a pretty big team to sustain your systems if you're flipping all the security switches to non-default values.<p>It would be fine as a one-time activity but it creates an ongoing stream of work to deal with breakages, particularly during upgrades.<p>Your OS ends up in a configuration that no upstream devs have tested compatibility for and you end up shouldering that for each component of your workload.<p>The recommended security options (given you have opted to tweak all the things) change over time as well and that creates additional work.<p>I think for many (most?) teams choosing a minimalist OS where an upstream does this kind of maintenance (say COOS or BottleRocket in container world) will produce better real-world results.
This guide is concerning for the following reasons:<p>* blithely states that systemd is not secure, uses lines of code in an unit system as a security measure and makes claims not substantiated about it.<p>* recommends musl and misleadingly states number of CVEs as some sort of security metric. Completely overlooking that glibc was created in 1987 and opposed to musl which was released in 2011.<p>* ignores the fact that a lot of effort had gone into hardening openssl, and seems to think supporting OS/2 and VMS equates to bad code security<p>* seems to misunderstand the purpose of long-term support kernels, which rather ironically contradicts there first point about frozen updates... author should do some basic reading here, which directly contradicts the states there ate only two releases of kernels stable and LTS (there are actually four categories of releases, and don’t necessarily happen for security reasons): <a href="https://www.kernel.org/category/releases.html" rel="nofollow">https://www.kernel.org/category/releases.html</a><p>I am still reading through it, there are interesting points made but I’m definitely taking it with a grain of salt given the above!
> Linux is not a secure operating system. [Click link for an explanation by the same author]<p>> There is no strong sandboxing in the standard Linux desktop. [...] This is in contrast to other desktop operating systems such as macOS or Windows 10 [...]. Windows automatically sandboxes UWP applications and provides the Windows Sandbox utility for non-UWP applications.<p>Is this actually fair? Windows Sandbox is not that different from using docker, or even better a VM, is it? It's great that UWP apps are sandboxed, but they're a minority of the apps people use.<p>I don't get how Windows gets a point over Linux here. Running all or most apps in a sandbox without the user even noticing improves security, but neither OS really do that effectively. Windows Sandbox is cool, and Linux doesn't have something like that out of the box, but a VM is easy to install and create no?
While I did not read this properly yet, it seems like a good primer.<p>There is also a great set of ansible playbooks and roles that should cover this and more that is a good base for Linux servers: <a href="https://github.com/dev-sec/ansible-collection-hardening" rel="nofollow">https://github.com/dev-sec/ansible-collection-hardening</a>
> If possible, your timezone should be set to "UTC" and your locale and keymap to "US".<p>Is there any special reason why other values would be less secure?
I've got mixed feeling about this page.<p>1. It does list some completely valid options which are good to know. All of them are interesting both from the perspective of learning about more Linux internals and actually locking down access where needed.<p>2. It mixes security and privacy. Some privacy things may be interesting, but going as far as removing your machine-id? What's the scenario here exactly?<p>3. It tells you what you can do, but often doesn't say why. What's the threat model? It bounces between things that could be useful for the desktop and for the server. If you're protecting yourself at home, what exactly does blocking ICMP provide you, given it's likely both a flat network and you're registered in both upnp and mdns?<p>4. Some points I find really questionable: It says to avoid distros with systemd, however systemd was the first one to really bring service sandboxing to the masses. So many issues could be avoided if we used PrivateTmp years ago. Some points are really bad: Avoiding distros that freeze packages (I guess vs rolling distros) is not a trivial change and is not obviously more secure.<p>5. <a href="https://xkcd.com/1200/" rel="nofollow">https://xkcd.com/1200/</a> - Sure you can put all of those extra options in kernel boot, the extra layers of service separation, spend time hiding identifiers and network options. Unless you're specifically targeted, nobody will ever try that. You'll be owned by some XSS which pulls your login cookie - and the list doesn't even mention Firefox tab containers which can separate that content. Or if someone's targeting developers, your SSH key will get extracted - and the post doesn't even mention hardware SSH keys.<p>Overall it reminds me of CIS policies. "Here's a CIS certified docker image. It has aida and tcpwrapper on it, because security."
There's a saying when you walk the Camino De Santiago that you shouldn't worry about your next meal or bed because the Camino will provide.<p>I notice it is also true about HN.<p>Yesterday I was researching about Linux security and was disappointed by an eBook on the subject. Today HN has provided :)<p>Thanks HN, see you next year.
I missed? Such an important was not mentioned<p>NoNewPrivileges=yes<p>"A new system.conf setting NoNewPrivileges= is now available which may be used to turn off acquisition of new privileges system-wide (i.e. set Linux' PR_SET_NO_NEW_PRIVS for PID 1 itself, and thus also for all its children). Note that turning this option on means setuid binaries and file system capabilities lose their special powers. While turning on this option is a big step towards a more secure system, doing so is likely to break numerous pre-existing UNIX tools, in particular su and sudo."
I think everyone with valid criticisms of this should file an Github issue, I'm definitely planning to, because of these things:<p>- Lots of discussion on X11 security issues without any mention of wayland<p>- Not on the Linux page, but they recommend iOS as a secure OS, which is total bullshit given how many failures we've seen with serious bugs/vulns put into production. I can't even remember how many times I've read about bugs in Safari, Whatsapp or some other app that can be chained to get kernel-level privileges. Remember the Jeff Bezos hack?<p>- No discussion of threat models<p>- Focusing on academic/technical arguments and not looking at real-world malware ecosystems/exploits (or: why there is orders of magnitude more malware for Windows than Linux)<p>- Memory safe languages - Linux is totally exploring a way to use rust for parts of the kernel, and Windows is still probably 99% C/C++<p>I'm all the more confused by this guy since he's a whonix developer, this almost sounds like a Microsoft employee based on how little scrutiny he applies to Windows...<p><a href="https://github.com/madaidans-insecurities/madaidans-insecurities.github.io/issues" rel="nofollow">https://github.com/madaidans-insecurities/madaidans-insecuri...</a>
> Configure a cron job or init script to update your system daily.<p>He recommends daily automated updates. This is quite dangerous from my personal experience in various distributions. An update might break your system or might put it into a vulnerable state. I very much prefer regular manual updates, as it allows me to read release notes, bug reports and manual user intervention instructions before update.
The blog mentions the ill usage of OpenSSL in favour of LibreSSL. At the same time, right now the devs at Gentoo are having a heated discussion to discontinue LibreSSL support.
Question is, why not run Lynis for example and research the output it gives you? It follows along the same lines of no password login for ssh, no x11 fowarding, etc.
I like this, very good reference material.<p>But as the disclaimer notes, this should not be followed blindly. It's sort of aimed at a niche audience because imho you should know what everything in that guide does, or at least know how to look it up, before applying it.<p>Also I feel that the overhead added by not using systemd creates a lot of attack surface too. So that's a difficult trade off to consider.<p>This is a rabbit hole of a debate but I'm interested in comparing the security trade offs of using for example RHEL with systemd where you get properly packaged SElinux policy for all your packages, and using Gentoo without systemd where you get no SElinux policy packaged at all and you have to write and maintain a bunch of init scripts.<p>(And before anyone chimes in, I know RHEL has had to make compromises in their SElinux packaging but at least it's there and you have the option to build upon it)<p>I personally prefer having the systemd+selinux option over any alternative. Because ease of administration is also a factor that influences security in the long run.
This is a nice collection of options that you have, but you should evaluate each of them very carefully before actually implementing them.<p>Switch to libc to musl? You need to talk to the application developers first to see if their applications work on musl. This step alone requires some extensive testing; I'm sure some of the other steps do as well.
Awww, does anyone remember the Linux Administrator's Security Guide (<a href="https://seifried.org/lasg/" rel="nofollow">https://seifried.org/lasg/</a>)?<p>It was such a valuable resource in 2001.
There's no mention of snaps in the sandboxing section. This is a shame, I'd like to hear the author's analysis of its sandboxing.<p>As far as I'm aware, it is stricter on providing permissions to snaps than flatpak, in that classic confinement and special plugs require store approval. It has the same issue that most snaps provide access to the "home" plug for trivial access to much user data, but dotfiles are excluded so there is no trivial exploit through .bashrc, or reading of .config data, for example.
If these things are true, author is talking about true, why are they not set to hardened by default?<p>Why is ptrace enabled by default, rather than disabled? Why is /proc visible to any other process? Why aren’t the ASLR bits already set to 32?<p>This of course leads to the question, why is there even a way to change this and why don’t we live in a opt-out world? This reminds me about that whole Apple vs. Facebook discussion again
>You have likely heard of regular protections such as Position Independent Executables, Stack Smashing Protector, immediate binding, read-only relocations and FORTIFY_SOURCE but this section will not go over those as they have already been widely adopted.<p>Is Debian PIE by default now? last time I checked, this was not included in their hardening patch to GCC, yet this was well over a year ago at this point.
This is meme security advice. Anti-systemd, anti-glibc, anti-openssl. This is security by internet fad.<p>As for the rest of the advice, it doesn't explain any of the tradeoffs, making it worthless. The kernel devs and distribution maintainers are not idiots. If you can't explain why it's on, then you don't understand it enough to turn it off.
This guide should be titled as “Compendium of Linux Hardening”.<p>It is not for the average system admin nor targeting a specific system usage model such as desktop workstation, embedded, or router/gateway/switch.<p>Given that, this guide is a very useful summary, which of course is only for the seasoned security developers and admin can use.<p>The rest of you can tread lightly.
Throwing this into the mix as another source on basically the same topic <a href="https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/ubuntu-18-04-lts" rel="nofollow">https://www.ncsc.gov.uk/collection/end-user-device-security/...</a>
Something that might help this article is to group the recommendations into a set of conceptual guidelines for hardening any system:<p>1. What ports are open?<p>1a. Can any of them be closed?<p>2. What services are running?<p>2a. Can any of them be stopped?<p>3. What permissions do those services have?<p>3a. Can any of them be reduced?<p>... and so on
Does anyone know how "hardened" various AWS/Azure/GCP linux distros are? Also, what about those popular base docker images? How "hardened" are they?
Reminds me of CIS benchmarks and their hardened images <a href="https://youtu.be/71ek_fm3TNs" rel="nofollow">https://youtu.be/71ek_fm3TNs</a>
As a newcomer, how many of these tips would you suggest for a Fedora/Ubuntu/<whatever mainstream distro> PC meant for everyday computing?
This sounds like an advert for alpine Linux.<p>That said, the take away I think for most users is: software side good (selinux, firewall, sandbox).<p>Kernel stuff tread with care.
Is this really where we are on Hacker News? The brightest minds on the internet can't even agree on systemd or other systems without coming to a sound conclusion? Now wonder tech is so fragmented.