Arch: https://wiki.archlinux.org/index.php/Security

CentOS: https://wiki.centos.org/HowTos/OS_Protection (limited)

Debian: https://www.debian.org/doc/manuals/securing-debian-howto/ind... (old)

Fedora: https://docs.fedoraproject.org/en-US/Fedora/19/html/Security... (old)

Mageia: https://wiki.mageia.org/en/Msec (limited)

Oracle Linux: https://docs.oracle.com/cd/E52668_01/E54670/html/index.html

Red Hat: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Slackware: https://docs.slackware.com/howtos:security:start (limited)

SuSE: https://www.suse.com/documentation/sles-15/singlehtml/book_h...

Ubuntu: https://help.ubuntu.com/lts/serverguide/security.html.en (limited)

And for the masochists: https://iase.disa.mil/stigs/Pages/a-z.aspx

Crikey, look at that mess:

Upgrade the version of the browser to an approved version by obtaining software from the vendor or other trusted source. Method 1: View the following registry key: HKLM\Software\Mozilla\Mozilla Firefox\CurrentVersion Method 2: Search for the firefox.exe file using the search feature of the operating system. Examine the files properties for the product version (not the file version. For Windows OS, determine the version of the file by examining navigating to Properties/Version/Product Version. Examine for all instances of firefox.exe that are present on the endpoint. Criteria: If the version number of the firefox.exe file is less than 50.1.x (or ESR 45.7.x), this is a finding.

How about clicking on "About Firefox" in the menu? "Other trusted source" - like softonic, yes?

As someone who has had to implement STIG, that is not a realistic method. This stuff is implemented via automation over hundreds of nodes at a time, and having to click through anything in automation is slow and error prone.

STIG itself is just a fancy check-list. Ideally, real world implementation is automated via something like OpenSCAP.

> How about clicking on "About Firefox" in the menu?

Perhaps they don’t trust it enough to execute it until they know it’s the latest version and was obtained from a trustworthy source.

At least the version there is baked into the (signed) .exe while the registry information can be edited independently.

Should there be any difference between RedHat and CentOS?

I would use the Red Hat guide because it is comprehensive.

> “One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though.

No, one shouldn’t. To be even more pedantic, verifying a signature under PKI is, in fact, “decrypting with the public key” something (a hash, usually) that was encrypted with the private key. When considering the complete set of PKI operations (encryption + signing), both the public and private parts of a key pair are used in both their enciphering and deciphering capacities.

"No, one shouldn’t" suggests that you don't use public key when encrypting data. "Verifying a signature […] is […] “decrypting with the public key” is the part I meant when writing that the original statement is "cryptographically inaccurate" - it's algorithmically feasible. But also mind that this specific kind of encryption has a specific name - "signing". You can't state that: "no, one shouldn't use public key for encrypting data".

Fully agree. You missed the most inaccurate one:

> Now you need to append the contents of the public key ~/.ssh/id_ed25519.pub to the ~/.ssh/authorized_keys file on the target server. You'll want to do this in a secure way since the public key gives access to your server.

Sorry for being so ignorant but can someone explain why this is so wrong?

The fact you have the private key permits access, not possession of the public key even though the public key is the one you add to the file on the server side (asymmetric cryptography). The "secure way" may also suggest that you have to keep your public key secret which is not true.

I believe the statement is most charitably interpreted as the channel must be secure against modifications so that when you are attempting to put the public key in the file that some other contents aren't inserted instead.

On the other hand, SSH gives you just that if you verify the fingerprint which is not mentioned in the guide. MITM-proof channel is needed if one gains any kind of shell access because then public key substitution can happen in various ways, even without the user him/herself explicitly editing the file. Furthermore, if one allows MITM when accessing shell, substituting the public key is just one of very serious security problems.

Certainly many other operations require a tamper-proof channel, and many more things can go wrong without one but I believe the author was trying to indicate the specific requirement here rather than making a specifically incorrect statement.

Nice. I admit, I haven't read the whole thing.

This is great feedback! Thank you so much.

I simplified things that would be too heavy to get into. The guide is not intended to teach everything about security -- that would be too much. The goal is to cover enough to give the reader a high level understanding. Once they have a basic understanding they can research more if they desire.

Can you tell me some of the "exotic details where defaults would be sane enough"? I can amend the guide.

Are you saying a public key can be used to decrypt data it encrypted? Or are you saying a public key could also be used to decrypt data that the private key encrypted?

You mention "server room". This guide is intended for a person running a simple server in their home. Hopefully SAs securing a large scale environment are not using information from GitHub. :/

I made some other updates to the guides that I hope address your other concerns?

Regarding your distribution agnostic comment, I do not see value in distribution specific guides on hardening. Sans a few edge distributions, most distributions are similar enough that the hardening steps are the same. It is okay to look for distribution specific documentation on how to install the distribution but it hurts the cause having distribution specific hardening guides.

Also, I want more folks to use Linux. Most distributions are so similar there is no value in having so many distribution specific guides -- all it does is create unnecessary confusion and steer potential prospective users away from Linux.

> The guide is not intended to teach everything about security -- that would be too much.

On the other hand, the objectives list contains: "this guide will attempt to cover as many of them as possible". Despite that, it still misses basic security rules.

"A desktop class computer [...] That I want to be able to SSH to remotely from unknown computers and unknown locations (i.e. a friend's house)."

SSH from an unknown computer? Also see my original comment about what is missing in description of a situation when connecting to your server from a new system.

> Are you saying a public key can be used to decrypt data it encrypted? Or are you saying a public key could also be used to decrypt data that the private key encrypted?

See my discussion with derefr in this thread.

> You mention "server room". This guide is intended for a person running a simple server in their home.

The "server room" here means you are sitting next to your server and can connect point-to-point. It doesn't mean you need a backup diesel generator.

And if it is really about a home server, concerns like "make sure nobody is listening" don't make sense.

> I made some other updates to the guides that I hope address your other concerns?

I've seen you accepted pull requests of some contributors that fixed the basics for you. Because they were generated right after discussion in this thread they concern things discussed here.

> Also, I want more folks to use Linux. Most distributions are so similar there is no value in having so many distribution specific guides -- all it does is create unnecessary confusion and steer potential prospective users away from Linux.

How many (which) distros have you managed as a professional sysadmin to state that with high confidence?

I'm quite sure that a beginner will just choose Ubuntu and proceed to something like https://linuxjourney.com/. If someone becomes more than a hobbyist one will hopefully go and read something from a trusted source, written by sysadmins with a good grasp of contemporary cryptography involved.

The goal is to cover as many things as possible, not everything. Security is a very deep and complex topic -- no single document can cover everything. I want to wet the readers appetite to get them interested enough to learn more.

Thanks for that link -- never seen it before.

I was an SA for a Fortune 10 company for 5+ years supporting 150k+ servers but we don't need to get into comparing resumes here. I appreciate your time and don't want to waste more of it. However, if would like to continue the discussion maybe we can do it on GitHub? I don't care for HNs commenting style. Thanks!

For umask, it actually does matter that it's a built-in. If it was an external binary instead, it would not be able to set the umask of the calling process (shell) which is what is important.

Thank you for the info. Maybe consider improving the GitHub article itself?

I see no point, there are enough guides already and I don't consider myself competent enough in that field to teach others. I think it shouldn't be about fixing every particular mistake in the guide. It's about changing attitude to "I won't write something unless I have a lot of experience". Otherwise it becomes a cat and mouse chase and managing basics for the author.

setting umask 027 is mentioned by the CIS as well