I personally use nft blackhole [1], which I can recommend for its ease of use.
1) Many attackers "hide" behind cloud services. So whatcha gonna do when your primary attack vector is AWS EC2 instances ? Block AWS CIDR ranges ?
2) With IPv4 exhaustion increasing numbers of people will be using IPv4 allocations across geographic boundaries.Sure, IP address block fragmentation will remove some value, but you'd still kill a lot of juicy compromisable home IP addresses in those countries.
Regarding cloud providers - well, I hope they have some automated systems to clamp down, since it's against their own interest to serve as vectors.
If you use certificate authentication and disable password authentication then you've killed off 100% of unauthorised attempts right off the bat. There really isn't much need to do more than that, its the world's easiest security fix.
Leaving password auth on is simply negligent.
That said, blocking all countries that you don't expect to talk to is the world's second easiest security fix, and protects other processes you might have running, and other unknown vectors that might be worse, such as heartbleed.
All fun and games until you find yourself on travelling in Asia and you need to connect back home and forgot you blocked half the world.
As for "other processes", we're talking about SSH on this thread. If you've got other processes then that falls into on-host/upstream filtering via firewall area of security. Regarding "unknown vectors", as I said, patching, no amount of IP blocking will help you with that.
If you really want to talk about "world's second easiest security fix" for SSH, that would be running a super-hardened bastion host and using SSH ProxyJump.
Leave a cheap droplet running somewhere, whitelist its IP, and SSH through it. I'm in Asia and I do exactly that with my U.S.-based servers. Actually, I've blocked all of the rest of the world as well, except the proxy droplet. It's like a global bastion host. There's no legitimate reason for anyone else on this planet to try and SSH into those boxes.
I know this is an oft-repeated trope, but I disagree. If you are whitelisting users for ssh and use secure passwords, you're really quite safe. Whereas if you lose access to your device with ssh keys, you're locked out with no hope of getting back in.
In what sense is it "negligent"? I feel like this is just an example of people constantly repeating popular advice without really considering it, like happened with bad password expiration policies. Like, I get that an ssh key probably has more entropy, but there is such a thing as good enough. My ssh password for my server is mixed case with numbers, and 20+ characters. Good luck cracking it.
Are you 100% sure that every machine you log into remotely with your very strong password isn’t logging that password?
That’s one advantage of keys.
And if the device on which you're running your ssh client is already compromised, it doesn't matter whether you use a key or password, its the same thing.
Can you explain the threat a bit more?
Whoa there sunshine.
Put your SSH keys on a USB HSM (Yubikey or Nitrokey) and nobody is ever going to be able to extract the private key.
Added bonus, put it on a USB HSM with touch auth (e.g. Yubikey) and nobody will ever be able to use the key without you knowing it (because you have to physically touch it).
Except you. To run through a compromised machine... Perhaps I don't quite understand how it works, but I don't see how this setup negates that issue. Once you plug it into the compromised machine and allow access to it with whatever touch-authentication or w/e, I can't imagine you could keep it secret from the attacker on the compromised machine. But maybe it's encrypting the key on the device?
That’s good. I think you’re probably in the minority though.
There are other ways unique passwords can be compromised. I see passwords accidentally entered into IRC windows about once a month. And even if you have perfect discipline at using unique passwords, that’s not something you can enforce on anyone else logging into your machine.
Maybe someone will chime in with strategies to run ssh from a wrapper that loads a unique password from a password manager with no risk of reuse or entry into the wrong window, or something. But at that point, your complaint about being locked out without the necessary files would apply—might as well use a key, which is simpler and provides strong security with no rigamarole.
Fortunately, most VPS and dedicated server hosts have a side channel that allows you to regain access when needed. It might be an automated dashboard feature to reset the root password, or you could open a support ticket. With colo, you can actually drive to the DC and reboot into single-user mode. In any case, you won't be locked out permanently. :)
Attackers, of course, can also social-engineer those side channels to gain access if they really tried. Much easier than cracking long passwords or 2048+ bit private keys.
Fortunately, but of course it means you now need to consider this side channel as well. Maybe you have strong ssh keys all across, but your cloud service has a web admin UI that can bypass them and someone has a 8 character password on it.
And if you lose access to your password manager, you're equally locked out. If you're not using a password manager, you're either 1. Dealing with a tiny number of servers (possible and legitimate), 2. Reusing passwords, or 3. Using insecure passwords. ... Okay, fine, 4. Or a world class memory/mnemonic device expert. Just back up your keys.
> I know this is an oft-repeated trope, but I disagree.
Agreed. Sometimes in these discussions it is forgotten that password and keys are both instances of a shared secret N bits long.
Now, yes, passwords tend to be shorter and have less entropy per byte if a human generated them and keys don't have these limitations. So in general it is nearly always wise to remove access via passwords. Certainly wherever general users might be creating those password since it is guaranteed some will be weak.
But any threat modeling exercise needs to consider availability as well. Using the STRIDE model, the D is for Denial of service. One case of that is not being able to access something important.
For my infrastructure there is (only) one ssh entry point which can be accessed via password. Limited only to very few select userids and the passwords have >=128 bits of entropy. Nobody will be brute-forcing those in the lifetime of the universe. It's a bit of a pain to memorize them, but it is possible. It has saved me a few times when I'm traveling and have access to nothing other than myself and my memory and need to get in.
On the downside, definitely need to be careful about operational security. If you are traveling, where are you entering this password? Can it be captured? Be wise. But there is a use case.
I'd rather do backups than risking password bruteforcing on servers.
If drive-by SSH attempts - even a large number of them - are enough to have a noticeable impact on heat/power/wear, then you should probably consider, you know, not putting hardware from 1997 on the Internet. Really doesn't take that much energy on hardware built during the current century to reject an authentication attempt and log it.
Measurably?
SELinux can do it, probably other LSMs, too.
Having all the log spam from failed attempts on 22 might the make the admin negligent on carefully following their logs at all. Having it pretty silent on a higher port usually will make you notice occasional scanning. At least I have noticed it and made me tighten the firewall a bit.
There is no perfect security.
And they still can’t show the host certificate, so your client would tell you the certificate changed.
Unless, of course, they have a local root exploit — but then port 22 is just as unsafe.
I fail to see how changing a port makes anything less safe.
This is why companies pay for https://www.greynoise.io/ so they don't need to worry about meaningless stuff.
This is the wrong number to look at. The relevant number is the login attempts that would have otherwise been successful. And if you’ve disabled passwords, that will be 0.
With exactly the same targeting, on port 22, you will see a rise from 100,000 to 101,000 which will likely not notice, despite it being as dangerous.
Changing the port does not make a targeted attack any more or less likely, or any more or less successful. But it does make it much more visible - and that’s useful for security as well.
A fault in your reasoning assumes that you know exactly what the attacker does - a credential attack; indeed this is the most common. However, maybe they are trying to exploit a zero day timing attack, requiring multiple attempts? Or some reconnaissance that lets them figure out valid usernames?
The different port won’t stop these of course, but will make the attempts stand out - which may allow you to stop them if noticed in time, or at least understand them in retrospect.
Since I don't log in from there, yes sure? And if I'm hosting on AWS I can proxy through an AWS resident host. Same with any other cloud provider.
I’ve yet to determine where the tipping point is.
My logs and firewall greatly disagree. Please avoid comments on HN like this where it boxes solutions into a "my way or the highway" result, when it has been demonstrated to you here it's not "Absolutely pointless". Security is the layering of multiple solutions and defenses to protect your assets, there is no magic bullet or single solution.
IP address spoofing is a thing. Blocking CIDR ranges might protect you from low-effort, drive-by botnets that constantly scan the entire internet (which all should be completely mitigated by using certificate based auth anyway), but blocking based on IP address is absolutely not an effective control against a determined hacker.
You must consider your threat model. For your personal instance that you host hobby things on, you probably won't be targeted via IP spoofing. For any type of company, you should not be relying on CIDR blocking as part of your security layers. CIDR blocking is only effective at reducing the clutter of your logs, which is a convenience, not a security control. The real security control is using proper auth methods, which are so easy to do at this point that it's ridiculous for even a hobbyist to not do them.
If an attacker can do it, you must assume they will do it. Because they will. That should be the starting point for any threat model.
"the attacker probably won't read my password through the wall from the radiation off my keyboard"
if your starting point is APT-level adversary then you might as well give up
Lets face it, for most businesses and pretty much all home users* the best they can hope to achieve is not to get owned by various automated attacks.
If some determined attacker is trying to get in, he will get in.
* Sure there are exceptions
(Note: This works only if 1. Your IP blocks are very coarse, and 2. You disallow password authentication)
For the same reason, assuming you must expose SSHD to the world, it makes sense not to expose it on port 22.
If you set up a machine on AWS EC2 and give it a public IP address, you can watch in near-realtime as the "admin/admin" login attempts come in (last time I tried this on a whim it took less than a minute).
By your own logic, if the problematic traffic shares the same geographic origin and you only happen to spot failed attempts, blocking all traffic from the same geographic origin would also block potentially successful attempts.
And I agree with the OP: there's an awful lot of malicious traffic sharing a common geographical origin. If you ever felt curious, just launch a cheap VM and setup a web server to listen to traffic and log any connection attempt. You don't even need to host a site. In no time you'll start to see your VM being hit by all sorts of web scrapers and security vulnerability scanners.
I do, actually. There is zero reason for anyone to use EC2 instances to contact my personal public machines.
> With IPv4 exhaustion increasing numbers of people will be using IPv4 allocations across geographic boundaries.
And there will continue to be tracking of who is using which blocks, so there should be no reason for error rates to creep up too much.
You need to think about the specifics of your situation, not just blindly follow "best practices". For my personal public machines, I do know, with a high degree of specificity, who should be doing what, and from where. I exploit that to place limits on who can talk to them, and it provides a lot of benefit.
If you're running a large public service, you're in starting from a very different stance. For my $dayjob, there are good reasons why customers might contact us from a country where we don't yet offer service, so we can't wall them off. But we do occasionally use geoblocking more selectively when we're under attack.