I always install fail2ban or something like it on servers I want to have SSH on. Really cuts down on the log volume, even if I have locked myself out occasionally. The thing about port scanning is that it's cheap as hell. There's less than 4 billion IP4 addresses and zmap can hit them all within an hour on a decent network connection.
Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.
It even happens if you just open port 22 on your home router. You can use things like fail2ban to put a short-term ban on offending addresses, and put your ssh server on a random (i.e. not 2222) high numbered port to reduce automated scans.
I wonder how often the reverse happens, i.e. admins sending angry emails to their own users who appear to be scanning other people's networks.
Anecdote: when I was a grad student at AS88, I once got an email asking me to stop port scanning. I was confused because I wasn't port scanning anyone. I asked for details and an admin sent me a report generated by some seemingly off-the-shelf network admin software (forgot the brand), with a bar chart of all IP addresses I was frequenting -- rather creepy, honestly. Turns out I was renting ~20 servers around the world as PoPs for a personal project at that time, and regularly deploying code to all of them at once over SSH (all configured at port 22). Apparently regularly accessing ~20 servers at once over a single port was enough to be flagged as "port scanning". I wonder if people doing actual security research over at the CS department were exempt from nonsense like this.
Port scanning can be trivially distributed over multiple IP addresses and rate limited. So blocking one IP address won't do much to block a port scan coming from another IP address.
When I tried to apply somewhat similar solutions in the past (e.g. fail2ban), I ended losing access to the server a few times (misconfiguration/bugs/daemon killed/firewall rule conflicts/etc.).
A more secure way to prevent port scanning is Single Packet Authorization, e.g. fwknop [1]
"SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance"
Port scans happen all the time, and your security shouldn't rely on hiding that information.
Port scans are a mild annoyance, as they litter the logs. I changed SSH to an uncommon port, and saw about a 100x reduction in connection attempts, which is good enough for me.
Pretty sure I'll continue to put SSH on a non-standard port. I already monitor my systems and its their logs heavily, and this cuts down on 99% of SSH-related spam. Any attack that's serious, the port will not matter.
A few useful resources:
If you don't want your SSH server being found by trivial port-scanning, apply port-knocking:
https://github.com/moxie0/knockknock
Yes, this is true - it's not going to stop someone who really wants in from finding your SSH port. But at the very least, it's useful when looking through your logs, because the ONLY failed log in attempts you will see are from people who mean business.
Port scanning is generally automated (edit: and scans all ports, not just the handful you listed), so it doesn't actually matter which port you pick as long as it's not 22. Port scanners like nmap are widely available, so the time to actually figure out which port is running SSH is quite short in practice.
Basically, there are two classes of people:
1. Those who use port scanners.
2. Those who do not.
If you are being attacked by someone in class 1, then moving your port gives you absolutely no protection. Thus moving your port is only worth anything at all if the percentage of class 2 people is significant.
However, if you also consider the probability a person in each class has of actually compromising your machine, then the security looks less convincing. Yes, it might be true that 95% of people don't bother to use a port scanner, but the most competent hackers are almost certainly going to be in the 5% that do use one.
The advantage of port knocking to me is just reducing the amount of garbage script-kiddie scans. IMHO the design of `sshd` needs to just assume it will be slammed by garbage attempts and minimize the logging. I've heard of `fail2ban`, but banning does nothing as the bots have an unlimited number of IPs.
Unless you're a service provider who supplies SSH access to generic customers, there's no reason to continue running sshd on port 22. Use some other port and your random scans will drop by ~100%.
Big ups for this -- since moving SSH to port 8022 I get zero bruteforce attacks. Even blacklisting tools like fail2ban can't get that kind of result. Of course it can't be the only defense, but I've always configured my SSH daemons to be key login only (no passwords). Moving SSH just cuts down on the CPU cycles burned at rejecting drone scans.
Every time I come across posts like this I consider maybe setting up a honeypot but I'm not sure what I'd do with the results other than look over them every few months for my own amusement. Are there any honeypots that can automatically forward information about the attacks to a central location?
What's with this "move SSH to another port" stuff? Don't even the most simplistic bots perform port scans to discover your services anyway? Seems a bit too much like security by obscurity to me.
reply