Don’t turn it on is the ultimate technique
That’s why “availability” is a core tenet of security (according to some cybersecurity course I took). It is easy to prevent unauthorized access to data if you have no requirements on authorized access.
barring that, unplug the ethernet.
Setup Fail2ban
Login only with SSH keys. MFA on SSH login. Use SSH proto 2.
Disable passwords, x11 forwarding, root logins
Reduce Idle timeout interval
Limit users’ SSH access
That should be more than enough for the average use case.
You can have 2FA on ssh?
Yep. Use SSH keys, not just protocol.
On connection, it’ll ask for your SSH password (this is different from the users password).
After that with something like authelia in place, you’ll be asked for a 2fa code.
So, no. SSH can’t do 2FA? I would need to set up Authelia and connect through that? I already use ssh keys instead of passwords to connect to my server
Yes it can. I literally have it set up right now.
When I connect to my vps I am promoted for the password for my SSH key. Only works on a machine that has the ssh key.
Then I need to use 2fa.
Ah, so it the asks for the TOTP provided by Authelia? I misunderstood, sorry. That’s pretty cool. Do you maybe still have the guide you used to set that up?
Regular updates are definitely necessary too. Also, if you do limit SSH users to a chroot make sure you limit TCP (port) forwarding too.
Do a search for you server OS + STIG
Then, for each service you’re hosting on that server, do a search for:
Service/Program name + STIG/Benchmark
There’s tons of work already done by the vendors in conjunction with the DoD (and CIS) to create lists of potential vulnerable settings that can be corrected before deploying the server.
Along with this, you can usually find scripts and/or Ansible playbooks that will do most of the hardening for you. Though it’s a good Idea to understand what you do and do not need done.
Air gapping
/s
Stumbled uppon this guide
https://github.com/imthenachoman/How-To-Secure-A-Linux-Server
I think its a good place to start
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System IP Internet Protocol SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption TCP Transmission Control Protocol, most often over IP VNC Virtual Network Computing for remote desktop access VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
[Thread #693 for this sub, first seen 20th Apr 2024, 15:55] [FAQ] [Full list] [Contact] [Source code]
Use a hardened-by-default OS like OpenBSD, HardenedBSD, or something similar in Linux.
fail2ban
… is an intrusion prevention software framework. Written in the Python programming language, it is designed to prevent brute-force attacks. It is able to run on POSIX systems that have an interface to a packet-control system or firewall installed locally, such as iptables or TCP Wrapper.
Don’t expose anything to the Internet that you don’t absolutely have to. If you can, put everything behind a VPN gateway.
Make backups. Follow the 3-2-1 rule.
Will a wireguard docker image work for getting ssh access to my server?
I wouldn’t recommend putting ssh behind any vpn connection unles you have a secondary access to the machine (for example virtual tty/terminal from your provider or local network ssh). At best, ssh should be the only publicly accessible service (unless hosting other services that need to be public accessible).
I usually move the ssh port to some higher number just to get rid of the basic scanners/skiddies.
Also disable password login (only keys) and no root login.
And for extra hardening, explicitly allow ssh for only users that need it (in sshd config).
Ssh behind a wire guard VPN server is technically more secure if you don’t have a key-only login, but a pain if the container goes down or if you need to access the server without access to wireguards VPN client on your device.
Highly recommend getting a router that can accept wireguard connections. If the router goes down you’re not accessing anything anyways.
Then always put ssh behind the wireguard connections.
For a homelab, there is rarely a need to expose ssh directly so best practice will always be to have multi layered security when possible.
- fail2ban / brute forcing prevention
- quick, frequent updates(!)
- containerization / virtualization
- secure passwords, better keys
- firewall
- a hardened operating system (distribution)
- SELinux / Apparmor / … / OpenBSD
- not installing unnecessary stuff
- An admin who is an expert and knows what they do.
Me, two+ decades into tinkering and still a dumbass: “look at me, I’m the expert admin now”
I like to require access to 22 via IP whitelist and all services on SSL behind a reverse proxy. Doesn’t leave much surface to attack.
Also, move ssh to a different, higher port. Since ssh isn’t exactly for noobs, changing the port is easy enough to work with and that alone already reduces port scans and what not
I recently setup Guacamole (Web based VNC/RDP/SSH) with totp and was able to close external SSH access. Now everything I run can sit behind a single reverse proxy, no extra ports.
Ubuntu has a set of scripts you can run to harden a new server (not advisable on a server that has already been configured for something). You need an Ubuntu Pro subscription to access them but you can get a free trial and then cancel it after you’ve finished.
More info at https://ubuntu.com/security/cis.
I did this process for a customer recently and it was pretty straightforward and much much more thorough (over 100 configuration changes) than just tweaking SSH and fail2ban.
I expect other commercially-oriented distros offer something similar.
Fwiw you don’t need to cancel or trial anything. Everyone can get free Ubuntu pro licensesbfor up to 5 machines
