this post was submitted on 30 Jul 2023
63 points (100.0% liked)

homelab

6602 readers
1 users here now

founded 4 years ago
MODERATORS
 

It scratches the surface of the most obvious stuff. I'd only add running apps in isolation (docker or adduser) and maybe fail2ban.

top 11 comments
sorted by: hot top controversial new old
[–] argv_minus_one@beehaw.org 5 points 1 year ago (2 children)

Here's my advice:

Disable password authentication and allow only key/certificate/token/etc wherever feasible. Don't even ask for a password if some other authentication mechanism can be used instead. Human-memorized passwords are weak and generated passwords are a poor substitute for proper cryptographic key exchange.

su, sudo, and Polkit are privilege escalations waiting to happen. Remove them if possible; deprivilege them (remove the setuid bit) if not. Do not allow any means for an unprivileged user to get a root shell, regardless of authentication, because unprivileged accounts may be backdoored and letting them elevate will grant root privileges to the attacker as well.

On your local machine, always log in as root on a separate virtual console using a separate password. On remote machines, always log in as root using an ssh key only accessible to the root account on your local machine.

I'm iffy about hiding SSH behind a VPN. Doing this creates a serious risk of being locked out of your own server, and if your SSH server is configured correctly (as described above), then the security benefits aren't that big. If you do find the risks acceptable, feel free to do this, but you shouldn't feel obligated.

Docker is unnecessary complexity and overhead. Use systemd to isolate things; it can do things like filtering system calls and hiding portions of the file system. SELinux might be good too, if you can figure out how to use it (I never could).

Fail2ban is unnecessary if nothing accepts passwords for authentication. There are no fails to ban.

[–] poVoq@slrpnk.net 8 points 1 year ago (1 children)

Sorry to say, but this is mostly bad advise.

[–] argv_minus_one@beehaw.org 10 points 1 year ago (2 children)

Are you going to elaborate, or…?

[–] Bipta@kbin.social 2 points 1 year ago

I think it's mostly good advice. Certainly not comprehensive but this is securing servers we're talking about.

[–] Technoguyfication@lemmy.ml 1 points 1 year ago (3 children)

No, because pretty much all of it is bad. Elaborating would be meaningless.

[–] NateSwift@beehaw.org 8 points 1 year ago

Explaining why something is bad advice is as important as saying it is. Otherwise it’s just a pissing match between two random people on the internet. Why also keeps people from making similar problems.

[–] f5xs_bhw0a@beehaw.org 3 points 1 year ago

I also want to know, being a beginner sysadmin myself. If you think that his advice is bad and you're not elaborating, I'll be taking his advice because his sounds sane so far.

[–] michael@lemmy.perthchat.org 1 points 1 year ago* (last edited 1 year ago)

That wouldn't make explaining how even one part of it is incorrect "meaningless".

You just cbf! :)

[–] Cyber@feddit.uk 2 points 1 year ago (1 children)

This is definitely good advice - and an interesting point on removing ''sudo''

I would add a clarification: moving SSH to cert only prevents password guessing, but also - if possible - only allow specific IPs to access it. This could be down to the country level if roaming a lot. Also use >1 IP so that you don't lock yourself out!

[–] Johnny5@lemm.ee 1 points 1 year ago

Yes! Geo ip filtering got rid of so much brute forcing for me.

[–] Krtek@feddit.de 2 points 1 year ago

While in no means a security measure, just disabling IPv4 for SSH on my VPS has completely eliminated bots/scripts attempting to login to my VPS directly