ssh -v myserver : 2>&1 | grep continue
(A surprising number of VPSs will re-enable passwords in a .d config file. And really, even if you've checked for that, the extra 10 seconds to make sure is worth it.)
All of your VPS security is meaningless compared to your VPS provider’s security, the security imposed on the employees of the VPS provider, the security of your VPS account password, and their susceptibility to faked subpoenas and faked emergency data requests.
That said, I do think there's some value in understanding what your server is running and what it's exposing to the network, and setting up firewall rules is one of many ways to build familiarity with that.
fail2ban is just junk, and shouldn't be running on any modern system.
This is a bit like saying "When you're temping your chicken, always remember that your grocery store could be putting arsenic in it at the store". Yea, that's true. But the average consumer gets sick far more often from mistakes in the kitchen than mistakes in the grocery store.
There are modules for setting up ssh, adding users, installing packages, etc.
https://www.reddit.com/r/docker/comments/18m1k0b/holy_sht_a_...
Note that ports which are not bound to the host (i.e., -p 5432:5432 instead of -p 127.0.0.1:5432:5432) will be accessible from the outside. This also applies if you configured UFW to block this specific port, as Docker manages its own iptables rules. https://docs.docker.com/engine/network/packet-filtering-fire...
It has a real and dramatic impact on a few things - I got CPU warnings from one server a couple weeks back because I'd inadvertently broken logging and fail2ban stopped working and someone was doing a persistent brute force at high volume for 8 hours.
After I fixed fail2ban it dropped off immediately. I know some WordPress plugins will do this but I've not had much success with them compared to fail2ban so it's still my default for this purpose.
Are there better system-level approaches than fail2ban in this case? Or is your comment mostly directed towards those using it for ssh blocking?
echo "sudo ufw disable" | at now +5 minutes
sudo ufw enable
Remember to re enable the firewall or stop the at job if everything works for you.
It's no substitute for proper security, but it's a great mechanism for quickly dropping naughty traffic. Even people who practice good security have online systems that are occasionally vulnerable to zero days, or have password forms on webapps. Dropping traffic while it's still in discovery mode is a great way to frustrate automated attacks.
It won't protect you from a direct attack, and it's no substitute for good system security, but it can quickly block attackers who "scan" your system to see what's running, to see what they can attack. It won't stop a determined attacker who will be able to attack from many locations, but that doesn't make it useless.
You can also use it actively to block people who do things like hammering a password form.
Better yet, use outbound only SSH (with a tool provided by the VPS provider like AWS session manager or third party).
Fail2ban is useful for limiting failed access attempts, but closing the SSH port altogether limits attack pathways to only trusted parties in the first place — assuming SSH isn’t meant to be publicly accessible.
There are many modern technology options for enabling private access without needing to open firewall ports, many are listed at https://zerotrustnetworkaccess.info
Of these, mesh overlay networks appear to be gaining the most traction lately, especially among the HN crowd.
sshd -T | grep -i pas
passwordauthentication yes
permitemptypasswords yes
On some VPS providers you can also instantly reboot into a rescue full blown OS that runs in memory and then mount and chroot into whatever disks that need to be fixed.
For completeness sake if someone is using SELinux Enforcing mode then UsePam will likely need to be Yes to avoid breaking sshd mandatory access rules.
Begin Disclaimer: The following comment is not for security, but only to reduce log noise :: I use a high port for non public SFTP servers to avoid noise. :: End Dislclaimer. It's not like the bots are getting in but I don't want the log noise. Not security through obscurity, just noise reduction. This is just for my bastion nodes. All other nodes require specific IP addresses or Tinc VPN to reach that high port.
To avoid 99% of the bots I use IPTables MSS rules to drop anything outside of the MSS any of my clients will show up with. I also personally drop anything with a TCP SYN packet TTL greater than 64 since all my clients are Linux. Windows is 128 and cell phones / LTE devices most of the bots are greater than 128. Don't do this in a corporate environment and instead require people use a corporate VPN. The following IPTables rules can be modified to include or exclude any ports or ranges of ports.
# (raw table for public bastion, using default port 22 as an example)
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d ${WAN_IP} --syn -m tcpmss ! --mss 1460 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d ${WAN_IP} --syn -m ttl --ttl-gt 64 -j DROP
sshd can also be told to only listen on IPv4 or IPv6 whichever you prefer. e.g. addressfamily inet for IPv4 only.
But as @wink points out, these days you also need to ensure you've actually got at available - which is not guaranteed especially with cut down distros like Alpine.