Live data from Hacker News

How to Secure a Linux Server

github.com

31–40 of 108 posts

Re: How to Secure a Linux Server

#31
post #22

Is using gmail to send mails from your server a good idea?

It's better than running your own smtp servers. But the article proposes using your own gmail account, to which the server has an app password. So a server compromise leads to your own email being compromised. It should be a separate gmail account.

Re: How to Secure a Linux Server

#32
post #29
post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

> “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…

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

Re: How to Secure a Linux Server

#33
post #18
post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

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

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

Re: How to Secure a Linux Server

#34
post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

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.

Re: How to Secure a Linux Server

#35
post #34
post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

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.

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

Re: How to Secure a Linux Server

#37
post #18

Earlier quoted context omitted.

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

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?

Re: How to Secure a Linux Server

#38
post #17

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough. "One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though. "Identity is verified by encrypting and decrypting data that both the client and server kno…

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

Re: How to Secure a Linux Server

#39
post #10

Earlier quoted context omitted.

Yes! This guide is good for securing maybe a personal server, but any business systems should use a server hardening standard that has industry mindshare (CIS, STIG, etc.) I can speak from personal experience that QSAs give you a very skeptical look when you say "our security standard is homebrewed."

Meh, QSAs check boxes. In my experience they are not very technically capable. Some are, of course. Most are not.

Sure but the point still stands. Why should anyone trust that you, or your company, is any good at security compared to say CIS?

If you have homegrown security and can show your QSA your detailed policy document and that it's a superset of CIS, STIG, NIST, etc. with documented exceptions then it'll be no problem.

I avoid homegrown whenever possible because it's a rabbit hole that never ends. If you instead say CIS level 2 then you can clearly define when you've done enough.

Re: How to Secure a Linux Server

#40
post #37

Earlier quoted context omitted.

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 Wind…

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

Post reply on HN