We scanned the Internet for port 22
blog.erratasec.com
blog.erratasec.com
Sure and while we are at it I'll fetch the lube.
I don't complain about port 22 connections because none of my machines run anything on port 22 (I move SSH to a random port mostly to deter whatever is coming out of China this week).
Even if you do find the port you still have to get around the ssh key's (so unless you are the NSA (j/k)), you could try an exploit against ssh but as it doesn't report its version good look with that and do try to avoid triggering fail2ban.
I'm not a systems administrator (I guess I'd be DevOps) but I know enough to know I don't know enough to disregard best practice.
If someone is trying to break into my server(s) via SSH, then I sure as hell don't want them to have access to any other services regardless of how secure they might be.
You're falling into the common trap of security through obscurity. But in fact it's very easy to find which port SSH listening on even when you're using a non-standard on. However if you harden SSH properly then it doesnt matter what port it's listening on. So your method is more work for zero gain
They aren't doing anything funny, nor are they asking you for permission to do anything funny.
They scan your ports. To the unobservant, that can look like they are trying to crack your systems. What is wrong with recognizing their IP (adding it to your "whitelist"), and knowing that it probably isn't something worth investigating.
I'm not white-listing anyone I don't know.
> so you can search your logs for it to make sure they aren't being evil.
This argument doesn't apply if the probe and the attack come from different IPs
Also, did their webpage get hacked and that ip changed?
Will someone with access to their machines network succumb to maliciously using or selling access to this widely whitelisted ip?
Seven years from now will that ip still be theirs?
And we're not talking about a literal software-implemented whitelist, just a "it probably isn't worth investigating or sending complaints" whitelist. That makes the seven-years point less important.
What's up with this belief that anybody you haven't heard of is a member of some shadowy organization? I'm a well known security researcher, I give several presentations a year at cybersec conferences, and my blog gets regularly link to from news.ycombinator.com.
Also, the post above excludes the first part of that: "We are happy to add your IP addresses to our blacklist so we won't ever scan you again".
I understand frustration that you can't convince everyone that you are a good guy. All good guys these days have that problem. Even the good folks at the NSA ( you aren't one of them, are you? )
Works for a lot of other ports too, but ssh is the obvious one.
It's a client/server thing, so you have to have the server running on the PC you intend to connect to (like when using ssh).
Never used it in any other way than with the CLI and not with every server I admin or use as there's other best practices also mentioned in the thread that are typically good enough without throwing in port knocking like:
https://news.ycombinator.com/item?id=6384313 (and the child reply)
https://news.ycombinator.com/item?id=6384418
https://news.ycombinator.com/item?id=6384457
Most things you can just use knocking and connect with ssh forwarding/proxy and tunnel everything through it like DB clients, IDE connections instead of having a bunch of ports open to internet. Assuming you don't kill the connection, then you can keep reusing it as a tunnel for anything else until rebooting or losing internet connection.
I'm much more in favour of adding increasing delays for password abuse in ssh.
* Disable root logins (require su/sudo)
* Disable password logins (require public keys)
* Run Denyhosts, to block IP addresses that have too many repeated failed login attempts.
* Use Jumphosts (AKA Bastions). One (or a few) servers that listen to ssh from the open Internet and have no private keys stored on them (use key forwarding). All other servers only listen to ssh from an internal network interface the Jumphosts are also on, or from the Jumphosts IP address directly.
With jumphosts, though, you can run denyhosts, redirect to tarpits, or other clever things, and not effect performance on your other servers.
I think the motivation to use jumphosts is to minimize the surface area of your other servers as much as possible. Each daemon on each server listening for incoming connections is a liability. If an sshd exploit is found (unlikely as that is), bots that mass scan and find my ssh ports and connect won't be able to delete any production files (right away, at least) if all they gain access to is my jumphost and not one of the prod db servers.
But having a script like denyhosts or fail2ban that analyzes auth logs for IPs to block requires memory for the interpreter running the script, as well as however much of the log gets read into memory.
Blocking external ssh connections can avoid that performance hit, however large or small it ends up being.
The substantive difference, though, is that port knocking can be used to hide the service entirely, rendering you safe (mostly) from 0day attacks, DoS against a specific service, etc. It can also be use to make things that shouldn't be on the Internet (say, an RDP route to the CEO's computer) a little safer. Still, though, it's not like VPNs are very difficult to use...
The worrying thing in this report though is how many hosts seems to be running ancient (now unsupported) versions such as the stock variant from Debian 4. I bet most of those hosts have no key-based auth and easily guessed passwords too...
From the description:
This program is called by /etc/hosts.deny whenever someone connects to port 22. Unless they type in a plaintext password or type the wrong password, they get an ssh-compatible error message, and a syslog message is generated. If they type in the right password, they are added to /etc/hosts.allow, and their next connection will reach the real sshd.
And they're owned by the Hell's Angles or Red China, I bet.
The bottom half of http://spenserj.com/blog/2013/07/15/securing-a-linux-server/ shows how few things you need to do to set up Fail2ban and Blocklist.de
> … result of 1,730,887 systems on the Internet … (Note: this is actually only 60% of the Internet
So there are only 2,884,811-ish machines on the internet?
(Most of my "important" servers have port 22 firewalled off an only open to a small set of external ip addresses. Some of them aren't running ssh at all.)
After I picked up a Cisco ASA, went back to standard port 22 but only allow access for connected VPN users.
Of course if the ASA goes down, so does the entire network, yelp. SmartNET contract/warranty comes in handy, and the data center having backup ASAs on site for quick swap is pretty useful as well.
The reason I'm asking is because, most people who claim to "scan the Internet" assume that the network is reliable. And they don't follow up on potential false negatives. If you scan the IPv4 address-space sequentially while only limiting bandwidth or time, rest assured that packets will be dropped.
cd /etc/ssh
for pub in `ls -1 *.pub`; do ssh-keygen -l -f $pub; done
Rough best practice is, 1) Use SSH keys to login 2) Enforce SSH to login (no password) 3) Disable Root Logins (login then elevate permissions not logging in as root) 4) Move from port 22 to something else (if you do 1-3 this shouldn't matter I do it mostly to keep the crap out my logs) 5) install something like fail2ban to automatically blacklist IP addresses.
LoginGraceTime 30
MaxAuthTries 3
I can't think of a scenario where a really short login grace time would protect you from an attacker, either. What's the motivation?
The only benefit moving SSH has is to reduce the reporting (as you also mentioned).
I just wanted to make that clear in case someone mistook your post to assume that switching SSHs default port made them more secure
What it will do however is prevent automated script-kiddy scanning tools from seeing port 22 open, scraping the banner, and adding your IP to a list of target to brute force/exploit. That's a good thing, and is absolutely, by any definition, a security benefit.
Setting a non-standard port to ssh is akin to adding a wood plank to the door of a safe with state of the art locks and 20" steel walls. A very annoying wood plank, by the way.
Real security doesn't rely on obscurity.
Last time I talked about the subject, I didn't think it was worthwhile to point that. Now it clearly is.
Also, I don't see much advantage in #4.
Initially I thought this worked because the overwhelmingly huge address space, but even when I published come-get-me DNS records ( ssh.example.com ) there was not a single IPv6 attempt versus hundreds of IPv4 attempts every day on the same host.
Edit: there is plenty ( ~ 8% ) of inbound IPv6 web traffic to my hosts, so it's not a case of IPv6 being obscure. It just seems that none of the bad guys are interested.
for pub in *.pub; do ....
"We'll be scanning SSH again in October"
> We are going to be extending this to more ports, such as FTP and SMTP. Soon, we should have weekly scans going for about 10 ports. I'm moving slowly forward to resolve abuse complaints, like this one generated for port 22. We plan on publishing the results, such as the anonymous counts above, in a nice weekly report for the public.
So, weekly, not daily.