I'm curious how running services on non-standard ports has an impact on anything like this.
This specific threat appears to be a hoax, but even if it wasn't, an attacker just portscans you and then targets your SSH service. Moving the port doesn't even buy you a few minutes.
It doesn't. If anything change the line SSH emits and how it identifies itself. You want the automated tools to send the wrong exploits. If you can make your OpenBSD machine look like a Windows server running a commercial SSH server you're going to deflect a lot of attacks / attract the wrong kind of attacks.
The proper way to do something like this is generally three fold:
1) Trusted host (OpenBSD?) that runs only SSHD, and only allows users to run ssh from the shell. Log the fuck out of this server, and likely port mirror and record raw packet logs. Since no one should be talking to this machine except for SSH simply drop everything from those IPs when you recieve something other than SSH.
2) Ensure all other servers only accept SSH connections from the trusted host.
3) Restrict unconditional access to the trusted host to a list of trusted IPs, turn off all unused SSH options, you probably don't need that many if all it is doing is proxying connections to other hosts. Now that you have a list of trusted IPs you can be very aggressive in firewalling malicious connections from non-trusted IPs. (It's nice to have some way to getting back into your infrastructure when you're on vacation, etc)
Generally the best thing for security is a default deny rule. Chances are your database server doesn't really need to connect to the internet. Chances are your webservers only require inbound connections on ports 80 and 443, and only make outbound connections to your database & log server.
Fuckery with port numbers is generally a waste of time. The best thing for an attacker to do is extensive slow scanning in advance, then when an exploit comes out it's a quick lookup in a DB for likely vulnerable systems.
It helps against a masscan on the standard port. If the attacker is specifically targeting you or has the resources to masscan every port, then I agree that it's useless.
It isn't clear whether that is on a specific port or every port. The documentation[1] makes it look like it's on a specific port since it requires a target port to run. If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed. Thanks for sharing, I had not heard about ZMap before.
EDIT: The research paper says that it's on a particular port, from page 3: "The architecture allows sending and receiving components to run asynchronously and enables a single source machine to comprehensively scan every host in the public IPv4 address space for a particular open TCP port in under 45 mins using a 1 Gbps Ethernet link."
> If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed.
You're not? I am. Or would be if this wasn't known info yet.
Think about it for a bit - you can narrow down your search area quite a bit by excluding huge swaths of the Internet such as consumer ISPs. Focus on the target-rich environments like EC2 space, hosting providers, enterprises, etc. You also can not scan any unassigned v4 space (admittedly getting smaller), multicast addresses, RFC1918, etc. The usable pool of v4 is actually quite a bit smaller than 32 bits, and the interesting parts are even less. I would be surprised if you couldn't come up with a list of interesting space to scan that you couldn't do within 15 minutes per port. You aren't using this tool to pwn Joe nerd who runs a Linux NAT box off his cable modem.
From there, you just need a few hundred compromised servers (not difficult this day in age) and you can probably scan the entirety of "rich" space on all ports rather quickly via a distributed manner.
The only downside is such scans tend to generate complaints, so you'll need to balance your loss of compromised hosts with the expected payoff.
Indeed, but if you consider that plenty of cheap servers with larger links exist, and attackers aren't limited to using one...
Essentially, you'd run this across a botnet so that rather than focusing all the traffic at one target, you retrieve the massive amount of data much faster than your single system could.
This specific threat appears to be a hoax, but even if it wasn't, an attacker just portscans you and then targets your SSH service. Moving the port doesn't even buy you a few minutes.