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.
Regular updates are definitely necessary too. Also, if you do limit SSH users to a chroot make sure you limit TCP (port) forwarding too.
Containers can help lock services down if you do it right.
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.
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.
- crowdsec
- SSH - change port, disable root login, disable password login, setup SSH keys using SK(YubiKey in my case)
- nftables - I use https://github.com/etkaar/nftm to keep things quick and simple. I like the fact if will convert DNS entries to IPs. I then just use dynamic DNS update clients on all my endpoints
- WireGuard for access to services other than SSH(in some cases port 443 will be open if its a web server or proxy)
- rsyslog to forward auth logs to my central syslog server
disable root login
That does not do much in practice. When a user is compromised a simple alias put in the .bashrc can compromise the sudo password.
Explicitly limit the user accounts that can login so that accidentally no test or service account with temporary credentials can login via ssh is the better recommendation.
I think the point is that root is a universal user found on all linux systems where as users have all kinds of names. It narrows down the variables to brute-force, so simply removing the ability to use it means they have to guess a username and a password.
guess a username and a password.
Security by obscurity is no security. Use something like fail2ban to prevent brute force. When you use a secure password and or key this also does not matter much.
Something something don’t let ‘good’ be the enemy of ‘perfect’
Check out online resources such as the Nist cyber stuff.
Basic things include disabling unnecessary services, disabling password authentication, setting up and verifying the firewall, configuring selinux and so on.
Ask yourself a few questions first before following the massive amount of suggestions and then locking yourself out and so on.
- What are you worried about ?
- How important is your stuff ?
- Make backups and check them
Still worried ? Then there’s the easy way out : Hire some security auditor to help you find holes you left.
Minimize installation and keep it streamlined. Update promptly. Choose applications that are still supported or have an active community.
Firewall and deciding on an entry point for system administration is a big consideration.
Generating a strong unique password helps immensely. A password manager can help with this.
If this is hosting services reducing open ports with something like Nginx Proxy Manager or equivalent. Tailscale and equivalent(wire guard, wireguard-easy, headscale, net bird, and net maker) are also options.
Getting https right. It’s not such a big deal if all the services are internal. However, it’s not hard to create an internal certificate authority and create certs for services.
If you have server on a VPS. Firewall is again your primary defense. However, if you expose something like ssh fail2ban can help ban ips that make repeated attempts to login to your system. This isn’t some drop in replacement for proper ssh configuration. You should be using key login and secure your ssh configuration away from password logins.
It also helps if you are using something like a proxy for services to setup a filter list. NPM for example allows you to outright deny connection attempts from specific IP ranges. Or just deny everything and allow specific public IPs.
Also, if you are using something like proxmox. Remember to configure your services for least privileges. Basically the idea being just giving a service what it needs to operate and no more. This can encompass service user/group names for file access ect.
All these steps add up to pretty good security if you constantly assess.
Even basic steps in here like turning on the firewall and only opening ports your services need help immensely.
The biggest thing is to change the defaults and to limit access. Unless your are the target of a nation state the attacks against your network will be automated.
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.
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)
8 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.
[Thread #693 for this sub, first seen 20th Apr 2024, 15:55] [FAQ] [Full list] [Contact] [Source code]
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
- 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.
Run SCAP tool with a STIG baseline.
Kicksecure Debian CLI: https://www.kicksecure.com/wiki/Debian
Move services away from known ports and don’t use ports that end with well known port numbers (22,80,443).
Moving ssh from 22 to 2222 or 443 to 10443 does nothing. You have ~65000 ports. Pick something random like 6744 or 2458
Changing ports does nothing except reduced log chatter.
Security through obscurity is not securityMoving ports does help. It is not a sure thing but when used in conjunction with other security mechanism can help get rid the of the low hanging fruit of scriptkiddies and automated scans.
But scriptkiddies and automated scans are not a security threat. If they were a legitimate threat to your server, you have bigger problems.
All it does is reduce log chatter.Anyone actually wanting in would port scan, then try and connect to each port, and quickly identify an SSH port
Automated attacks are a huge threat. Changing defaults shouldn’t be your only security practice but it can significantly help defend a network.
Security by obscurity is no security.
It is if you are defending against automation.
It defends against the lowest level of automation. And if that is a legit threat in your model, you are going to have a bad time.
It’s just going to trip you up at some pointI’m not saying it should be your only defense. I’m saying that changing defaults is a good idea for secure systems.
For instance, you should change the default WiFi password on your router.
Yes, because a password is security
It breaks automation. Same thing for changing any default. Change default names, directories and anything else that’s to predictable
Still does nothing when scanning the entire ipv4 address space achievable so quickly. You can also use services like shodan to find vulnerable services on any ports.
Use SSH keys, stay upgraded. Make management services (SSH, RDP, admin services) accessible only via VPN (WireGuard). Only expose 80 and 443 to the internet, if necessary.
Just don’t port forward ssh. There is 0 reason to in 99.99% of home cases
