In the past two weeks I set up a new VPS, and I run a small experiment. I share the results for those who are curious.
Consider that this is a backup server only, meaning that there is no outgoing traffic unless a backup is actually to be recovered, or as we will see, because of sshd.
I initially left the standard “port 22 open to the world” for 4-5 days, I then moved sshd to a different port (still open to the whole world), and finally I closed everything and turned on tailscale. You find a visualization of the resulting egress traffic in the image. Different colors are different areas of the world. Ignore the orange spikes which were my own ssh connections to set up stuff.
Main points:
-
there were about 10 Mb of egress per day due just to sshd answering to scanners. Not to mention the cluttering of access logs.
-
moving to a non standard port is reasonably sufficient to avoid traffic and log cluttering even without IP restrictions
-
Tailscale causes a bit of traffic, negligible of course, but continuous.
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 |
| HTTP | Hypertext Transfer Protocol, the Web |
| IP | Internet Protocol |
| SSH | Secure Shell for remote terminal access |
| UDP | User Datagram Protocol, for real-time communications |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
| nginx | Popular HTTP server |
7 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #42 for this sub, first seen 14th Aug 2023, 15:55] [FAQ] [Full list] [Contact] [Source code]
Public key auth, and fail2ban on an extremely strict mode with scaling bantime works well enough for me to leave 22 open.
Fail2ban will ban people for even checking if the port is open.
Honest question, is there a good default config available somewhere or is what apt install fail2ban does good to go? All the tutorials I’ve found have left it to the reader to configure their own rules.
Honestly the default config is good enough to prevent brute force attacks on ssh. Just installing it and forgetting about it is a definite option.
I think the default block time is 10 minutes after 5 failed login attempts in 10 minutes. Not enough to ever be in your way but enough to fustrate any automated attacks. And it’s got default config for a ton of services by default. Check your /etc/fail2ban/jail.conf for an overview.
I see that a recidive filter that bans repeat offenders for a week after 10 fail2ban bans in one day is also default now. So I’d say that the results are perfect unless you have some exotic or own service you need fail2ban for.
If Fail2Ban is so important, why the h*** does it not come installed and enabled as standard?!
Security is the number-1 priority for any OS, and yet stock SSHD apparently does not have Fail2Ban-level security built in. My conclusion is that Fail2Ban cannot therefore be that vital.
You really shouldn’t have something kike SSHD open to the world, that’s just an unnecessary atrack surface. Instead, run a VPN on the server (or even one for a network if you have several servers on one subnet), connect to that then ssh to your server. The advantage is that a well setup VPN simply won’t respond to an invalid connection, and to an attacker, looks just like the firewall dropping the packet. Wireguard is good for this, and easy to configure. OpenVPN is pretty solid too.
You say this and are downvoted.
While we are coming off the tail of Def Con where there where a plethora or small talks and live examples of taking advantage and abusing just this.
I don’t understand your comment, what you are saying. Could you elaborate a bit, please? I’m interested why it’s a bad idea what previous comment suggested.
Of course I can dig into DefCon videos and probably would do if needed, but perhaps you know what exactly the issue is
I’ll take that tiny amount of traffic telling scanners there’s no password auth over having to remember port settings for ssh, scp and rsync any day.
Or, you know, just use key auth only and fail2ban. Putting sshd behind another port only buys you a little time.
Yeah but the majority of bots out there are going after easy prey. Honestly, if you use public key authentication with ssh you should be fine, even if it is on port 22. But it does of course clog up access logs.
The majority of bots out there are stopped by just using a hard to guess password. It’s not them that you should be worried about.
I’ve noticed that a lot of the scans these days almost always switch IPs after 2-3 attempts, making IP blocking a lot more difficult.
Let’s say that you could ban for an indefinitely large amount of time after a single failure to authenticate, that’d make them run out of IPs much quicker than you’d run out of CPU/BW, so I don’t really see the issue
Potentially yeah, although a single failure means I might lock myself out by accident.
