19 ms·

Linux Hardening Guide

460 points by FlyMoreRockets 6y ago

BOOSTERHIDROGEN 6y ago
For average joe using ubuntu vps, what is the safest guide in this list that can be applied?
signa11 6y ago
there is no threat model described here afaics. seems pretty shallow imho
- nicholasbraker 6y ago
  Exactly this. If your threat model needs you to implement all of this then also use TEMPEST hardware to really lock things down. No use in hardening everything when an attacker can read your screen from a safe distance with some SDR-gear and a suitable antenna.
- outsomnia 6y ago
  Right... but then if the threat is remote access, the author would have to remove nonsense like systemd making your box insecure (racy init shellscripts being the pinnacle of security), and old platform support that you don't build in openssl being "abhorrent security practices".
3np 6y ago
While I did not read this properly yet, it seems like a good primer. 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: https://github.com/dev-sec/ansible-collection-hardening https://github.com/dev-sec/ansible-collection-hardening
jmnicolas 6y ago
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. I notice it is also true about HN. Yesterday I was researching about Linux security and was disappointed by an eBook on the subject. Today HN has provided :) Thanks HN, see you next year.
- deleted 6y ago
  [deleted]
px43 6y ago
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. 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] [1] https://nakedsecurity.sophos.com/2013/09/11/rudest-man-in-linuxdom-rants-about-randomness-we-actually-know-what-we-are-doing-you-dont/ https://nakedsecurity.sophos.com/2013/09/11/rudest-man-in-li...
- lathiat 6y ago
  This is a good theory and I mostly agree but if you disallow password logins, private keys on servers and agent forwarding - how do you copy things server to server without going through your slow and possibly remote local connection?
  - nerdbaggy 6y ago
    python3 -m http.server —bind 0.0.0.0 8080 is my favorite command
    - yjftsjthsd-h 6y ago
      If we're talking about security, then exposing your files to anything with network access to your server sounds like a terrible, terrible idea.
    - px43 6y ago
      I 100% endorse this method of securely moving files way way way above using things like agent forwarding and throwing keys on servers. It's shocking to me how people overlook HTTP as a tool for passing files around.
  - noodlesUK 6y ago
    Magic wormhole and friends are pretty good at doing this securely, especially between servers that can talk to each other without relays. See also croc
viraptor 6y ago
I've got mixed feeling about this page. 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. 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? 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? 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. 5. https://xkcd.com/1200/ https://xkcd.com/1200/ - 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. Overall it reminds me of CIS policies. "Here's a CIS certified docker image. It has aida and tcpwrapper on it, because security."
- Sebguer 6y ago
  I'm glad that this called out systemd in the very first section, because it told me that the rest of it probably wasn't going to actually talk about anything actually meaningful for security. Edit: Oh god I hadn't even gotten to the end of that same section where it recommends Gentoo???? This article is written for people who read Cryptonomicon and took it a little too seriously.
  - wojciii 6y ago
    Systemd is evil. What alternatives are there which were designed with security and speed in mind? I would prefer something simple instead of a lot of features.
xyzzy123 6y ago
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. It would be fine as a one-time activity but it creates an ongoing stream of work to deal with breakages, particularly during upgrades. 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. The recommended security options (given you have opted to tweak all the things) change over time as well and that creates additional work. 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.
- randmeerkat 6y ago
  Or just use FreeBSD if you really care about secure by default.
  - jmnicolas 6y ago
    According to the author: > Despite popular belief, OpenBSD's security is actually lacking in a lot of ways. https://madaidans-insecurities.github.io/openbsd.html https://madaidans-insecurities.github.io/openbsd.html It's probably not better on FreeBSD.
  - andi999 6y ago
    I did this, and 1 month later got bad emails about shutting down the server because of ntp vulnerability. Maybe it was just a new vulnerability found at that time, but then this brings me to the missing item of the text: how to keep up? What pages tell you about new found vulnerabilities, so you can mitigate.
    - randmeerkat 6y ago
      There’s a few resources listed here: https://www.freebsd.org/doc/handbook/security-advisories.html https://www.freebsd.org/doc/handbook/security-advisories.htm...
rococode 6y ago
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. 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.
nerdbaggy 6y ago
I’m ehhh about the musl suggestion. I spent way to long finding problems that were related to musl
- zinekeller 6y ago
  When I found problems apparently relating to musl, it unfortunately mostly (like around 98%) ends up to be an application relying on GNUisms instead of actually being a musl bug.
  - richardwhiuk 6y ago
    That's not necessarily a bug in the application - only supporting glibc in an application is an absolutely sensible option.
    - zinekeller 6y ago
      I do get it when the software is only targeted to Linux* - but I encountered this with applications that supposed to be cross-platform! * GNU/Linux
wantguns 6y ago
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.
EE84M3i 6y ago
>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. 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.
- jwilk 6y ago
  PIE has been enabled on most popular architectures since 2016: https://sources.debian.org/src/gcc-6/6.3.0-18+deb9u1/debian/changelog/?hl=489:490#L479 https://sources.debian.org/src/gcc-6/6.3.0-18+deb9u1/debian/...
dartharva 6y ago
As a newcomer, how many of these tips would you suggest for a Fedora/Ubuntu/<whatever mainstream distro> PC meant for everyday computing?
- pjmlp 6y ago
  Lets put it this way, most of them are enabled by default on Android.
- viraptor 6y ago
  Close to none. A list for normal users: - don't delay updates - use Firefox tab containers to isolate browsing contexts so a random page can't mess with your gmail session (not sure if Chrome has something similar) - have backups and check they work - use 2fa where possible - if you use SSH, move your key to a hardware token
  - shaicoleman 6y ago
    Also: - set up full disk encryption - set a boot up (BIOS) password - for ssh: disable root ssh access, and disable ssh with a password - lock screen when away from computer, auto-lock when away
- kdtsh 6y ago
  Some of the `su` restrictions and sandboxing could be useful, but most of this list is overly pedantic and honestly for my part I would not recommend it, it would be hell to maintain and is unnecessary for a desktop user. Just operate a firewall which does not allow inbound access, and only run programs you trust (e.g. from the distribution repository, from a developer you trust, auditable code, etc.)
trinix912 6y ago
> If possible, your timezone should be set to "UTC" and your locale and keymap to "US". Is there any special reason why other values would be less secure?
- jmnicolas 6y ago
  > This guide is focused purely on security and privacy Maybe for privacy to make you stand out less?
  - sam_bristow 6y ago
    But then he does seems to go out of his way to customise everything else. Making his machine a unique, finger-printable, snowflake...
  - vbezhenar 6y ago
    IP will leak your location. Using non-default time zone for this location means less privacy.
BuzzwordBingo 6y ago
Clearly written by someone who thinks they know a lot about security, all while displaying the hyperbolic judgementalism of someone who is wildly over confident of their own expertise.
simonjgreen 6y ago
As a *nix sysadmin since before Google was a thing, I find articles like this frustrating and arguably dangerous. 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. 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. 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. Edit: There is a disclaimer at the top which mustn't be forgotten while reading. > 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. 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.
- quijoteuniv 6y ago
  Maybe Simonjgreen can help improve the article? Seems like a relevant topic to me. Glad people put work and share on hjis subject.
- pjmlp 6y ago
  Before Google was a thing, UNIX security was already something to worry about, hence why Tru64 was created, or HP-UX introduced vaults.
  - 867-5309 6y ago
    and just before that cavemen invented shift rotation to defend the entrance to their dwelling
- devwastaken 6y ago
  The problem I find is that those who know this tend to not spend the time going into detail on what you should actually do.
synack 6y ago
Chrome OS does most of these things by default, at the cost of trusting Google.
- dijit 6y ago
  Container optimised OS (used for GKE on google cloud) is built from chromeOS sources, so enjoys the same protections.
grapeli23 6y ago
I missed? Such an important was not mentioned NoNewPrivileges=yes "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."
hendry 6y ago
Reminds me of CIS benchmarks and their hardened images https://youtu.be/71ek_fm3TNs https://youtu.be/71ek_fm3TNs
ch0I9daAiO 6y ago
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.
mhoad 6y ago
Throwing this into the mix as another source on basically the same topic https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/ubuntu-18-04-lts https://www.ncsc.gov.uk/collection/end-user-device-security/...
based2 6y ago
https://static.open-scap.org/ssg-guides/ssg-fedora-guide-index.html https://static.open-scap.org/ssg-guides/ssg-fedora-guide-ind... https://wiki.debian.org/Hardening https://wiki.debian.org/Hardening https://wiki.gentoo.org/wiki/Hardened_Gentoo https://wiki.gentoo.org/wiki/Hardened_Gentoo https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/pdf/security_hardening/Red_Hat_Enterprise_Linux-8-Security_hardening-en-US.pdf https://access.redhat.com/documentation/en-us/red_hat_enterp... https://documentation.suse.com/sles/12-SP4/single-html/SLES-hardening/ https://documentation.suse.com/sles/12-SP4/single-html/SLES-...
perlgeek 6y ago
This is a nice collection of options that you have, but you should evaluate each of them very carefully before actually implementing them. 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.
wyuenho 6y ago
Does anyone know how "hardened" various AWS/Azure/GCP linux distros are? Also, what about those popular base docker images? How "hardened" are they?
lrossi 6y ago
> fixes for most security vulnerabilities are not able to be backported to LTS kernels This is nonsense.
tutfbhuf 6y ago
> Configure a cron job or init script to update your system daily. 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.
- protoman3000 6y ago
  > I very much prefer regular manual updates, as it allows me to read release notes, bug reports and manual user intervention instructions before update. Do you have the time for this though? > 198 packages need to be updated
  - wainstead 6y ago
    But, not having the time to review 198 updates shouldn’t justify automatically permitting the updates. I agree there isn’t time to review them, unless you have plenty of staff and time (no one does)... but the recent Solarwinds debacle was a supply chain attack, and automatic updates allowed an exploit to be propagated to many companies and agencies. I would ask myself if I need that many packages. And raise the red flag with management that maintaining proper security is a challenge under such circumstances.
    - chris_wot 6y ago
      How would reading release notes help in the case of the Solarwinds attack?
  - tutfbhuf 6y ago
    Sure, for most (including myself) it's impossible to review every little update. But the bug tracker of your distro is a good indicator if some of the most recent updates created a bunch of new tickets, especially those that are considered to be critical. In case of Arch Linux it is strongly recommended to read the latest update news on archlinux.org, before update. In addition to that you get some experience over time which of your package updates caused most trouble in the past and you can take additional care. For example, I know that on my desktop the combo of displaylink and xorg does break from time to time with updates, therefore I carefully lookout for issues regarding xorg updates for displaylink users, before I do the xorg update.
protoman3000 6y ago
If these things are true, author is talking about true, why are they not set to hardened by default? 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? 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
- lmz 6y ago
  > Why is ptrace enabled by default, rather than disabled? because it's useful to be able to attach to a running process with gdb
  - protoman3000 6y ago
    If you want to use it you can unlock it. Why is it unlocked by default?
    - viraptor 6y ago
      Because unlocking it requires root and users who want to submit a crash report may not have root privileges on the system.
ikurei 6y ago
> Linux is not a secure operating system. [Click link for an explanation by the same author] > 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. 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. 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?
- vbezhenar 6y ago
  IMO UWP sandboxing is not useful. I don’t have a single UWP application and I use my PC for a lot of tasks.
  - pjmlp 6y ago
    Which is why Win32 sandboxing is part of Windows 10 X feature set.
- voltagex_ 6y ago
  Device Guard and some other Defender features I'm forgetting the name of are pretty cool, I think they're even in 10 Home now. I don't think all Store apps are sandboxed now, either. I don't think it's fair to compare Linux without AppArmor or SELinux, really. Someone more versed in both may be able to provide more info. If I was as worried as the author and had a risk model to back it up I'd probably run QUBES or OpenBSD or both.
- danieldk 6y ago
  It's great that UWP apps are sandboxed, but they're a minority of the apps people use. It's not just sandboxing of UWP apps and Windows Sandbox. Recent Windows 10 version have a feature called 'Controlled folder access' where you can designate certain folders as being protected (besides the Windows system folders). If any non-whitelisted application attempts to access these folders, you get a notification and their access is blocked by default. You can then whitelist the application if you want to grant it access. It's more course-grained than fully sandboxes application, but it's a nice extra layer of defense for application that do not use sandboxing by default with a portal-based mechanism to request access to certain files/folders. There is more information here: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/controlled-folders https://docs.microsoft.com/en-us/windows/security/threat-pro... (This should be fairly easy to implement in Linux with a MAC framework like AppArmor/SELinux or perhaps eBPF. But it's not useful for most people until someone actually implements this in a user-friendly manner.)
erikbye 6y ago
If you want a battle tested hardening profile, use DISA’s STIG.
peter_retief 6y ago
How do FreeBSD, OpenBSD, and NetBSD compare to Linux (Gentoo) for security?
INTPenis 6y ago
I like this, very good reference material. 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. 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. 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. (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) 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.
egberts1 6y ago
This guide should be titled as “Compendium of Linux Hardening”. It is not for the average system admin nor targeting a specific system usage model such as desktop workstation, embedded, or router/gateway/switch. Given that, this guide is a very useful summary, which of course is only for the seasoned security developers and admin can use. The rest of you can tread lightly.
nottrobin 6y ago
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. 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.
whalesalad 6y ago
These are my absolute favorite resources. Succinct and to the point with lots of links to follow if you want to dive in for more.
0dayz 6y ago
This sounds like an advert for alpine Linux. That said, the take away I think for most users is: software side good (selinux, firewall, sandbox). Kernel stuff tread with care.
chris_wot 6y ago
This guide is concerning for the following reasons: * 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. * 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. * 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 * 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): https://www.kernel.org/category/releases.html https://www.kernel.org/category/releases.html 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!
cuillevel3 6y ago
Awww, does anyone remember the Linux Administrator's Security Guide (https://seifried.org/lasg/ https://seifried.org/lasg/)? It was such a valuable resource in 2001.
captn3m0 6y ago
There’s still no usable userspace firewall on Linux. There’s OpenSnitch but it’s so far from being any good.
anonunivgrad 6y ago
This is meme security advice. Anti-systemd, anti-glibc, anti-openssl. This is security by internet fad. 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.
Layke1123 6y ago
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.
slumdev 6y ago
Something that might help this article is to group the recommendations into a set of conceptual guidelines for hardening any system: 1. What ports are open? 1a. Can any of them be closed? 2. What services are running? 2a. Can any of them be stopped? 3. What permissions do those services have? 3a. Can any of them be reduced? ... and so on
mrtweetyhack 6y ago
I'm glad someone is thinking about this and sharing their knowledge
4oo4 6y ago
I think everyone with valid criticisms of this should file an Github issue, I'm definitely planning to, because of these things: - Lots of discussion on X11 security issues without any mention of wayland - 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? - No discussion of threat models - 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) - 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++ 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... https://github.com/madaidans-insecurities/madaidans-insecurities.github.io/issues https://github.com/madaidans-insecurities/madaidans-insecuri...

BOOSTERHIDROGEN 6y ago

For average joe using ubuntu vps, what is the safest guide in this list that can be applied?

signa11 6y ago

there is no threat model described here afaics. seems pretty shallow imho

nicholasbraker 6y ago
Exactly this. If your threat model needs you to implement all of this then also use TEMPEST hardware to really lock things down. No use in hardening everything when an attacker can read your screen from a safe distance with some SDR-gear and a suitable antenna.
outsomnia 6y ago
Right... but then if the threat is remote access, the author would have to remove nonsense like systemd making your box insecure (racy init shellscripts being the pinnacle of security), and old platform support that you don't build in openssl being "abhorrent security practices".

3np 6y ago

While I did not read this properly yet, it seems like a good primer. 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: https://github.com/dev-sec/ansible-collection-hardening https://github.com/dev-sec/ansible-collection-hardening

jmnicolas 6y ago

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. I notice it is also true about HN. Yesterday I was researching about Linux security and was disappointed by an eBook on the subject. Today HN has provided :) Thanks HN, see you next year.

deleted 6y ago
[deleted]

px43 6y ago

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. 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] [1] https://nakedsecurity.sophos.com/2013/09/11/rudest-man-in-linuxdom-rants-about-randomness-we-actually-know-what-we-are-doing-you-dont/ https://nakedsecurity.sophos.com/2013/09/11/rudest-man-in-li...

lathiat 6y ago
This is a good theory and I mostly agree but if you disallow password logins, private keys on servers and agent forwarding - how do you copy things server to server without going through your slow and possibly remote local connection?
- nerdbaggy 6y ago
  python3 -m http.server —bind 0.0.0.0 8080 is my favorite command
  - yjftsjthsd-h 6y ago
    If we're talking about security, then exposing your files to anything with network access to your server sounds like a terrible, terrible idea.
  - px43 6y ago
    I 100% endorse this method of securely moving files way way way above using things like agent forwarding and throwing keys on servers. It's shocking to me how people overlook HTTP as a tool for passing files around.
- noodlesUK 6y ago
  Magic wormhole and friends are pretty good at doing this securely, especially between servers that can talk to each other without relays. See also croc

viraptor 6y ago

I've got mixed feeling about this page. 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. 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? 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? 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. 5. https://xkcd.com/1200/ https://xkcd.com/1200/ - 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. Overall it reminds me of CIS policies. "Here's a CIS certified docker image. It has aida and tcpwrapper on it, because security."

Sebguer 6y ago
I'm glad that this called out systemd in the very first section, because it told me that the rest of it probably wasn't going to actually talk about anything actually meaningful for security. Edit: Oh god I hadn't even gotten to the end of that same section where it recommends Gentoo???? This article is written for people who read Cryptonomicon and took it a little too seriously.
- wojciii 6y ago
  Systemd is evil. What alternatives are there which were designed with security and speed in mind? I would prefer something simple instead of a lot of features.

xyzzy123 6y ago

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. It would be fine as a one-time activity but it creates an ongoing stream of work to deal with breakages, particularly during upgrades. 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. The recommended security options (given you have opted to tweak all the things) change over time as well and that creates additional work. 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.

randmeerkat 6y ago
Or just use FreeBSD if you really care about secure by default.
- jmnicolas 6y ago
  According to the author: > Despite popular belief, OpenBSD's security is actually lacking in a lot of ways. https://madaidans-insecurities.github.io/openbsd.html https://madaidans-insecurities.github.io/openbsd.html It's probably not better on FreeBSD.
- andi999 6y ago
  I did this, and 1 month later got bad emails about shutting down the server because of ntp vulnerability. Maybe it was just a new vulnerability found at that time, but then this brings me to the missing item of the text: how to keep up? What pages tell you about new found vulnerabilities, so you can mitigate.
  - randmeerkat 6y ago
    There’s a few resources listed here: https://www.freebsd.org/doc/handbook/security-advisories.html https://www.freebsd.org/doc/handbook/security-advisories.htm...

rococode 6y ago

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

nerdbaggy 6y ago

I’m ehhh about the musl suggestion. I spent way to long finding problems that were related to musl

zinekeller 6y ago
When I found problems apparently relating to musl, it unfortunately mostly (like around 98%) ends up to be an application relying on GNUisms instead of actually being a musl bug.
- richardwhiuk 6y ago
  That's not necessarily a bug in the application - only supporting glibc in an application is an absolutely sensible option.
  - zinekeller 6y ago
    I do get it when the software is only targeted to Linux* - but I encountered this with applications that supposed to be cross-platform! * GNU/Linux

wantguns 6y ago

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.

EE84M3i 6y ago

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

jwilk 6y ago
PIE has been enabled on most popular architectures since 2016: https://sources.debian.org/src/gcc-6/6.3.0-18+deb9u1/debian/changelog/?hl=489:490#L479 https://sources.debian.org/src/gcc-6/6.3.0-18+deb9u1/debian/...

dartharva 6y ago

As a newcomer, how many of these tips would you suggest for a Fedora/Ubuntu/<whatever mainstream distro> PC meant for everyday computing?

pjmlp 6y ago
Lets put it this way, most of them are enabled by default on Android.
viraptor 6y ago
Close to none. A list for normal users: - don't delay updates - use Firefox tab containers to isolate browsing contexts so a random page can't mess with your gmail session (not sure if Chrome has something similar) - have backups and check they work - use 2fa where possible - if you use SSH, move your key to a hardware token
- shaicoleman 6y ago
  Also: - set up full disk encryption - set a boot up (BIOS) password - for ssh: disable root ssh access, and disable ssh with a password - lock screen when away from computer, auto-lock when away
kdtsh 6y ago
Some of the `su` restrictions and sandboxing could be useful, but most of this list is overly pedantic and honestly for my part I would not recommend it, it would be hell to maintain and is unnecessary for a desktop user. Just operate a firewall which does not allow inbound access, and only run programs you trust (e.g. from the distribution repository, from a developer you trust, auditable code, etc.)

trinix912 6y ago

> If possible, your timezone should be set to "UTC" and your locale and keymap to "US". Is there any special reason why other values would be less secure?

jmnicolas 6y ago
> This guide is focused purely on security and privacy Maybe for privacy to make you stand out less?
- sam_bristow 6y ago
  But then he does seems to go out of his way to customise everything else. Making his machine a unique, finger-printable, snowflake...
- vbezhenar 6y ago
  IP will leak your location. Using non-default time zone for this location means less privacy.

BuzzwordBingo 6y ago

Clearly written by someone who thinks they know a lot about security, all while displaying the hyperbolic judgementalism of someone who is wildly over confident of their own expertise.

simonjgreen 6y ago

As a *nix sysadmin since before Google was a thing, I find articles like this frustrating and arguably dangerous. 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. 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. 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. Edit: There is a disclaimer at the top which mustn't be forgotten while reading. > 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. 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.

quijoteuniv 6y ago
Maybe Simonjgreen can help improve the article? Seems like a relevant topic to me. Glad people put work and share on hjis subject.
pjmlp 6y ago
Before Google was a thing, UNIX security was already something to worry about, hence why Tru64 was created, or HP-UX introduced vaults.
- 867-5309 6y ago
  and just before that cavemen invented shift rotation to defend the entrance to their dwelling
devwastaken 6y ago
The problem I find is that those who know this tend to not spend the time going into detail on what you should actually do.

synack 6y ago

Chrome OS does most of these things by default, at the cost of trusting Google.

dijit 6y ago
Container optimised OS (used for GKE on google cloud) is built from chromeOS sources, so enjoys the same protections.

grapeli23 6y ago

I missed? Such an important was not mentioned NoNewPrivileges=yes "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."

hendry 6y ago

Reminds me of CIS benchmarks and their hardened images https://youtu.be/71ek_fm3TNs https://youtu.be/71ek_fm3TNs

ch0I9daAiO 6y ago

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.

mhoad 6y ago

Throwing this into the mix as another source on basically the same topic https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/ubuntu-18-04-lts https://www.ncsc.gov.uk/collection/end-user-device-security/...

based2 6y ago

https://static.open-scap.org/ssg-guides/ssg-fedora-guide-index.html https://static.open-scap.org/ssg-guides/ssg-fedora-guide-ind... https://wiki.debian.org/Hardening https://wiki.debian.org/Hardening https://wiki.gentoo.org/wiki/Hardened_Gentoo https://wiki.gentoo.org/wiki/Hardened_Gentoo https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/pdf/security_hardening/Red_Hat_Enterprise_Linux-8-Security_hardening-en-US.pdf https://access.redhat.com/documentation/en-us/red_hat_enterp... https://documentation.suse.com/sles/12-SP4/single-html/SLES-hardening/ https://documentation.suse.com/sles/12-SP4/single-html/SLES-...

perlgeek 6y ago

This is a nice collection of options that you have, but you should evaluate each of them very carefully before actually implementing them. 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.

wyuenho 6y ago

Does anyone know how "hardened" various AWS/Azure/GCP linux distros are? Also, what about those popular base docker images? How "hardened" are they?

lrossi 6y ago

> fixes for most security vulnerabilities are not able to be backported to LTS kernels This is nonsense.

tutfbhuf 6y ago

> Configure a cron job or init script to update your system daily. 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.

protoman3000 6y ago
> I very much prefer regular manual updates, as it allows me to read release notes, bug reports and manual user intervention instructions before update. Do you have the time for this though? > 198 packages need to be updated
- wainstead 6y ago
  But, not having the time to review 198 updates shouldn’t justify automatically permitting the updates. I agree there isn’t time to review them, unless you have plenty of staff and time (no one does)... but the recent Solarwinds debacle was a supply chain attack, and automatic updates allowed an exploit to be propagated to many companies and agencies. I would ask myself if I need that many packages. And raise the red flag with management that maintaining proper security is a challenge under such circumstances.
  - chris_wot 6y ago
    How would reading release notes help in the case of the Solarwinds attack?
- tutfbhuf 6y ago
  Sure, for most (including myself) it's impossible to review every little update. But the bug tracker of your distro is a good indicator if some of the most recent updates created a bunch of new tickets, especially those that are considered to be critical. In case of Arch Linux it is strongly recommended to read the latest update news on archlinux.org, before update. In addition to that you get some experience over time which of your package updates caused most trouble in the past and you can take additional care. For example, I know that on my desktop the combo of displaylink and xorg does break from time to time with updates, therefore I carefully lookout for issues regarding xorg updates for displaylink users, before I do the xorg update.

protoman3000 6y ago

If these things are true, author is talking about true, why are they not set to hardened by default? 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? 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

lmz 6y ago
> Why is ptrace enabled by default, rather than disabled? because it's useful to be able to attach to a running process with gdb
- protoman3000 6y ago
  If you want to use it you can unlock it. Why is it unlocked by default?
  - viraptor 6y ago
    Because unlocking it requires root and users who want to submit a crash report may not have root privileges on the system.

ikurei 6y ago

> Linux is not a secure operating system. [Click link for an explanation by the same author] > 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. 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. 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?

vbezhenar 6y ago
IMO UWP sandboxing is not useful. I don’t have a single UWP application and I use my PC for a lot of tasks.
- pjmlp 6y ago
  Which is why Win32 sandboxing is part of Windows 10 X feature set.
voltagex_ 6y ago
Device Guard and some other Defender features I'm forgetting the name of are pretty cool, I think they're even in 10 Home now. I don't think all Store apps are sandboxed now, either. I don't think it's fair to compare Linux without AppArmor or SELinux, really. Someone more versed in both may be able to provide more info. If I was as worried as the author and had a risk model to back it up I'd probably run QUBES or OpenBSD or both.
danieldk 6y ago
It's great that UWP apps are sandboxed, but they're a minority of the apps people use. It's not just sandboxing of UWP apps and Windows Sandbox. Recent Windows 10 version have a feature called 'Controlled folder access' where you can designate certain folders as being protected (besides the Windows system folders). If any non-whitelisted application attempts to access these folders, you get a notification and their access is blocked by default. You can then whitelist the application if you want to grant it access. It's more course-grained than fully sandboxes application, but it's a nice extra layer of defense for application that do not use sandboxing by default with a portal-based mechanism to request access to certain files/folders. There is more information here: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/controlled-folders https://docs.microsoft.com/en-us/windows/security/threat-pro... (This should be fairly easy to implement in Linux with a MAC framework like AppArmor/SELinux or perhaps eBPF. But it's not useful for most people until someone actually implements this in a user-friendly manner.)

erikbye 6y ago

If you want a battle tested hardening profile, use DISA’s STIG.

peter_retief 6y ago

How do FreeBSD, OpenBSD, and NetBSD compare to Linux (Gentoo) for security?

INTPenis 6y ago

I like this, very good reference material. 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. 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. 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. (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) 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.

egberts1 6y ago

This guide should be titled as “Compendium of Linux Hardening”. It is not for the average system admin nor targeting a specific system usage model such as desktop workstation, embedded, or router/gateway/switch. Given that, this guide is a very useful summary, which of course is only for the seasoned security developers and admin can use. The rest of you can tread lightly.

nottrobin 6y ago

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

whalesalad 6y ago

These are my absolute favorite resources. Succinct and to the point with lots of links to follow if you want to dive in for more.

0dayz 6y ago

This sounds like an advert for alpine Linux. That said, the take away I think for most users is: software side good (selinux, firewall, sandbox). Kernel stuff tread with care.

chris_wot 6y ago

This guide is concerning for the following reasons: * 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. * 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. * 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 * 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): https://www.kernel.org/category/releases.html https://www.kernel.org/category/releases.html 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!

cuillevel3 6y ago

Awww, does anyone remember the Linux Administrator's Security Guide (https://seifried.org/lasg/ https://seifried.org/lasg/)? It was such a valuable resource in 2001.

captn3m0 6y ago

There’s still no usable userspace firewall on Linux. There’s OpenSnitch but it’s so far from being any good.

anonunivgrad 6y ago

This is meme security advice. Anti-systemd, anti-glibc, anti-openssl. This is security by internet fad. 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.

Layke1123 6y ago

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.

slumdev 6y ago

Something that might help this article is to group the recommendations into a set of conceptual guidelines for hardening any system: 1. What ports are open? 1a. Can any of them be closed? 2. What services are running? 2a. Can any of them be stopped? 3. What permissions do those services have? 3a. Can any of them be reduced? ... and so on

mrtweetyhack 6y ago

I'm glad someone is thinking about this and sharing their knowledge

4oo4 6y ago

I think everyone with valid criticisms of this should file an Github issue, I'm definitely planning to, because of these things: - Lots of discussion on X11 security issues without any mention of wayland - 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? - No discussion of threat models - 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) - 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++ 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... https://github.com/madaidans-insecurities/madaidans-insecurities.github.io/issues https://github.com/madaidans-insecurities/madaidans-insecuri...