Nothing about SELinux or AppArmor? While these are enabled by default on some of the big distros I think a basic guide on managing and troubleshooting would be beneficial.
How to Secure a Linux Server
11–20 of 108 posts
Re: How to Secure a Linux Server
#12I didn’t know you could add google Authenticator to your server. Thank you for this write up.
You don't have to use a closed source TOTP client such as Google's. There's RedHat's FreeOTP and there's another open source one called antOTP. You can find them on F-Droid as well.
There have been TOTP PAM modules for ages (these work on a Linux client and Linux server via e.g. SSH). You can even add YubiKey to PAM. Same for BSD Auth and macOS.
Re: How to Secure a Linux Server
#13Nothing about SELinux or AppArmor? While these are enabled by default on some of the big distros I think a basic guide on managing and troubleshooting would be beneficial.
Getting apparmor to stop flooding syslog with mysterious complaints is probably a full guide by itself.
Re: How to Secure a Linux Server
#14It would also be proper to disable non root access to /proc among other things. You can do that by simply mounting with hidepid=2 or adding it to fstab.
Re: How to Secure a Linux Server
#15Dont forget about namespaces which lets you isolate apps. and Apparmor to restrict file and network access. And also chroot and setuid to drop privileges and change the root path. And unix sockets / named pipes. Instead of letting your daemons access the whole network have them listen on a unix socket.
And scan your own network, both from the outside and inside.
Re: How to Secure a Linux Server
#16No mention of shipping off logs to another place? It's probably good to assume someone will gain access and make after-the-fact forensics a primary concern as well. Something a lot of hardening guides seem to skip!
A lot of hardening guides skip the long tail for security.
Which is to say: So you've shipped logs off, so then what? How are you going to monitor those regularly, what are you looking for, how are you going to make sure important information stands out?
Many people set up remote logging and then never check the logs until after there is an issue. An unread log isn't useful. Logs that are too spammy aren't going to be read.
Re: How to Secure a Linux Server
#17This 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 know". That's not how signing works. The crucial part of the process is to first establish an encrypted channel, then choose something random (not used previously) and finally verify the signature is correct. What exactly would be the data that "both the client and server know"?
"If you're sure there is nobody listening between the client you're on and your server, you can use ssh-copy-id to transfer and append the public key". Almost never happens unless you're in the server room, connected point-to-point. But then the remark about someone listening doesn't make sense. And not a single word about verifying server's fingerprint in the whole guide.
"Keep in mind doing this means you can't use the key for automation because you'll have no way to send the passphrase in your scripts". Unless you use an ssh-agent.
"umask is a Bash built-in which means a user can change their own umask setting". Wrong implication here. umask is a syscall. It doesn't matter what you use to call it. And what if you're using a different shell?
Suggesting painful default umask instead of just doing `chmod go-rwx $HOME` and adjusting /etc/adduser.conf is debatable.
Making this guide "distribution agnostic" is IMHO futile and there already are some distribution-specific guides like https://debian-handbook.info/.
Re: How to Secure a Linux Server
#18This 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.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)
Re: How to Secure a Linux Server
#19Nothing about SELinux or AppArmor? While these are enabled by default on some of the big distros I think a basic guide on managing and troubleshooting would be beneficial.
Yeah, the best impact would come from using SELinux, AppArmor, and GRSec. Everything else is just tweaking defaults, which for up-to-date software probably isn't going to impact your security much at all.
Re: How to Secure a Linux Server
#20I didn’t know you could add google Authenticator to your server. Thank you for this write up.
You don't have to use a closed source TOTP client such as Google's. There's RedHat's FreeOTP and there's another open source one called antOTP. You can find them on F-Droid as well. There have been TOTP PAM modules for ages (these work on a Linux client and Linux server via e.g. SSH). You can even add YubiKey to PAM. Same for BSD Auth and macOS.
> RedHat's FreeOTP
It's abandonware these days and hasn't been updated for years. The iOS app doesn't work anymore and can't use the camera for reading codes.