AS13335 doing SSH scanning(encryp.ch) |
AS13335 doing SSH scanning(encryp.ch) |
- Implement a firewall on your instances.
- Implement port knocking for sshd.
- Move sshd to a non standard port to avoid the nmap/bot noise.
- Only log successful logins.
- Any combination of the above.
There are pros and cons to each item so you would have to decide which combination is the most appropriate and least friction for your organization. If leaving the port exposed consider enforcing key based authentication and disabling password authentication. For high risk accounts such as monitoring accounts that use passwordless unrestricted sudo, you can even restrict what networks the keys are valid from.
I created gofwd, a cross-platform TCP port forwarder with Duo 2FA and Geographic IP integration. Its use case is to help protect services when using a VPN is not possible. While it's use cases are limited, it works great for me when I need to connect to my home network.
The overall elegance of this solution is that no additional software is needed. As long as you are within your predefined geo-ip location, have your phone, and know your hostname/ip address (and port number), then you will be able to access your system remotely.
After starting it, everything becomes much calmer. Nice thing is, fail2ban can protect much more than SSH.
Combined with only allowing key based login, password is disabled.
For those who, like me, are unfamiliar with the concept of a SSH tarpit, it's a technique consisting of inserting delays into SSH connection attempts.
Old HN discussion on Endlessh:
There are scanners like shodan that will scan every single port you have now so moving it to a non-standard port doesn't stop all the attackers.
My friend working in an ISP has cleared the mystery for me - it's Cloudflare's Warp product (a semi-VPN (in the "teleport to other countries" sense, not the original definition)), which can be used for free, and I'm not shocked that it is being abused. Cloudflare has also categorically denied that their Worker product allows SSH connections - it is simply not designed for that, apparently.
So I don't know how to respond to this specifically except that I didn't know Cloudflare offers a VPN (apparently a limited knocked-down one though) and I'm pretty sure that other people in other ASes scan the default SSH port - in fact, I see more and more scans from ASes of cloud providers than residential ASes, whereas five years ago I mainly saw Chinese and Brazilian residential ISPs. This is why I often move the SSH port - it's not that it improves my security posture, just so that the noise in the logs are minimised.
In any case I wouldn't think much of it. If you obsess over any garbage traffic you get you will go insane.
Some of my servers don't even have any IPv4 connectivity and there haven't been any failed SSH logins over IPv6.
I don't think that demanding that every ISP inspect and censor outgoing packets is ever going to work. Every network operator has their own definition of good and bad, and it's probably up to that operator to enforce it themselves. Regarding SSH, you can basically assume that 4.2 billion IPs will concurrently try every password database that exists against your server 24/7. Passwords are a failed experiment. People can't remember them, and attackers can easily guess them. The solution is: don't accept password logins, and ban particular IPs after a certain number of failed attempts. (You should do the same for any unauthenticated resource -- if someone gets 1000 pages from your website in a second, you should probably cut off access to them for a while. Some script has gone awry, and it's costing you money, not the author of the script.)
The topics that HN discusses can show you the breadth of opinions on this issue. One day it's "I hate cloud provider X for blocking my abusive service" with 3000 comments agreeing. The next day it's "I hate cloud provider Y for not blocking someone's abusive service" with a different 3000 commeters agreeing. No consensus will ever be reached, and there is no Internet police force you can bully into agreeing with you. I would just take precautions and move on, rather than appealing to a mob or administrative body for some meaningless justice.
About password authentication I totally agreeing with you, but this is a bit out of scope of this thread.
The only purpose of this article is to know the truth what is really happening. I have never seen such many connections to the SSH even from researchers.
You can also go further if you like: Put the sshd service behind WireGuard (or spiped). Then malicious actors will never find your SSH ports.
I had similar issues with them in the past spewing weird traffic. Didn't really ever reach a conclusion on it, other than just reducing logging for that error condition a scanner was triggering.
Running a quick port scan from my phone against one of my machines works, so it doesn't look like they are restricting this too heavily.
And I'm not logged into this app and haven't granted it additional permissions, so I'm not sure they have any idea who I am here.
Remedy: Don't let fail2ban send mail, or at least remove the whois part.
Pretty nifty feature.
The OP has too much time on their hands. :)
You can play this whack-a-mole game indefinitely. If you have SSH open to the Internet, expect that others will try to connect 24/7.
(Aside: I really wish English had a better way to distinguish between an earnest question and a rhetorical challenge.)
There are differences between walking by and noticing a door, knocking on a door, trying a key in a door, trying to defeat the lock. Before you can break the lock you have to notice the door. I haven't met any friendly door knockers on the internet.
Hi, I'm the tech lead of Workers, so I'll clarify.
At present, Workers can only generate HTTP traffic, because the only API we've given Workers for network communications is `fetch()`, which is HTTP-specific. This similar to how in-browser JavaScript today cannot open arbitrary TCP connections, because there's no API for it. It's likely we'll add an API for arbitrary TCP eventually, but at the moment it's not possible that this traffic comes from Workers.
(As far as where it did come from, I don't have any internal knowledge, but WARP traffic (that's our VPN-like service) seems like an obvious explanation to me.)
It's weird how the "VPN providers" have taken that acronym and turned it into what is basically another synonym for "proxy".
The main point of WARP is to circumvent ISP traffic shaping (which works quite well btw).
I'm guessing that the person you replied to is referring to the same.
For some reason, this is 6× more than a server I have on an university network.
It's for the Pi as that's the target audience but it should apply generally for OpenSSH.
There's also a sister post about improving your "first factor" for those still using passwords: https://2byt.es/post/totp2/
> When unauthorized port scanning is detected by AWS, it is stopped and blocked.
Page 13
https://web.archive.org/web/20160331233541/https://d0.awssta...
It's not clear, now.
*tarpit
A honeypot lets people "in" to see/research malware that's in the wild:
* https://en.wikipedia.org/wiki/Honeypot_(computing)
A tarpit just takes up the attacker's resources:
There may be more realistic ways to go about protecting people's SSH servers that trying to dox Cloudflare VPN users.
I used to spend time on custom iptables scripts but came to the conclusion it’s much better to just architect things in a way where the bots and scanners can’t plausibly create a problem and then ignoring them.
I think OP guessed it was probably not Cloudflare themselves scanning their ports, so I think that's what they meant by "hear who and why".
Maybe dox is too strong a word. My point is, from what I've heard, the general sentiment is that you're unlikely to get any information about customers just by sending abuse reports to Cloudflare.