SSH Password Gropers Are Now Trying High Ports

badger.foo writes "You thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port? It seems security by obscurity has lost the game once more. We're now seeing ssh bruteforce attempts hitting other ports too, Peter Hansteen writes in his latest column." For others keeping track, have you seen many such attempts?

Comments

No I haven't, and here is why:

[Anonymous Coward]

I've blackhole'd all ports I'm not actually using, so the machines don't respond at all. I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

I've never even seen anything that wasn't me attempting to log in in my sshd and system logs. Root login disabled, and pubkey authentication is the only enabled method... so even if they did figure out my port knocking sequence they could literally spend infinity time trying to figure out my non-root non-existent password.

Also, wtf password groper? This used to be a news for nerds site, not a news for computer molesters site...

Use random IPv6 from a /64 range

[Anonymous Coward]

Typically server hosting with ipv6 will assign a /64 range to each box. Assign your ssh port to a randomly generated address somewhere i the range (2**64 addresses) and port scanning will never find it.

Re:No

[SuricouRaven]

It's not for security.

It's to stop the script kiddies of the internet wasting your bandwidth and cluttering your logs with thousands upon thousands of rejection messages in their futile attempts to gain access. They can't get in, but their efforts are annoying.

Dumbass parroting.

[Anonymous Coward]

It seems security by obscurity has lost the game once more.

How, exactly?

By ensuring the vast majority of brute force attacks - which hit port 22 - fail?

Security isn't fucking binary, and obscurity is a perfectly valid layer of the onion.

Re:Dumbass parroting.

[astralagos]

Security through obscurity is one of the most spectacularly misunderstood concepts in information security, partly because it's gotten confused with open source politics. The core concept behind it (Kerckhoffs' principle) is best stated as "assume that the enemy knows your system as well as you do". In cryptosystems this means that the secret is a controlled and limited entity - the key. The key must -still- be hidden and controlled, but Kerckhoff's principle ensures that you have only one thing to have to control. Various federal agencies used to, for example, assume that the first version of any cryptosystem they sold would be bought by Moscow and rapidly analyzed.

Well and good, but all any security implementation buys you is *time*. The real problem with StO is that the time it buys you is unpredictable, and in Kerckhoffs' era of large and slow system upgrades, it might take years to update a cryptosystem once it was broken. Malware authors have happily used StO for years -- for example, evading detection mechanisms by using a number of off the shelf packers in sequence. The approach works because they replace their malware faster than anyone figures out the packing sequence. The windtalkers during WWII were a security through obscurity approach, and it worked fine for the duration of the war, but would have gone horribly in the next one.

Now, what we're dealing with here is network defense, which isn't crypto. In network defense, creative lying is enormously helpful because you can use it to differentiate between your ignorant attackers and knowledgeable members of the community. The majority of attackers scan horizontally (all hosts on a fixed number of ports) rather than vertically (all ports on a number of hosts) because vertical scanning is a waste of time. Most attackers normally hit 9-10 ports and then move onto the next potential target -- they don't see the network in terms of what the hosts *are*, just what they can *exploit*. Moving SSH to a random port means that the attacker now has to spend 6000x the effort to figure out of there's anything on the host he cares about, and he's probably not going to bother when there are nice sysadmins out there happy to put everything on port 22 (as always, I don't have to outrun the bear. I just have to outrun you.) Copy it with some aggressive port blocking (like port 22) or a threshold random walk scan detector and you've got a perfectly fine way to ignore idiots. It's also worth noting that the mentioned port is 2222, which tends to be "stupid port manipulation rule #2" among folks (the other one being to add 1 in front of the port numbers, I can't tell you how fascinating it was to watch port 16888 the first time we blocked bittorrent).

Re:Low Hanging Fruit

[bcmm]

And the bots are REALLY stupid. I have more than one internet-connected machine with a key-only sshd open to the internet, and, infuriatingly, they try to brute-force it anyway. That is, even though they don't even get a chance to offer a password, they still make multiple attempts to connect...

Very few

[PktLoss]

We're running a network of 80+ servers around the world (https://wonderproxy.com).

We've moved in stages getting things off standard ports.

Whole network standard - several hundred attempts per day
a few standard, rest on non-standard ports - tens of attacks per day
all non-standard ports - 0-5 attacks per day.

It's been worth doing just for the reduced reporting volume in our status systems.

VPN

[sgt scrub]

I thought all the cool kids put machines behind firewalls then SSH after connecting to the VPN.

Re:No

[jamesh]

I don't look at the logs so I'm not annoyed. Problem solved.

The other problem is when you have a device like an old wrt54gl which has to perform unnecessary work (and therefore gets hotter than it needs to) when trying to deal with several password attempts a second.

Changing the port to something like and rate limiting it from unknown addresses makes a huge difference.

I agree with not looking at the logs though, or at least in the default configuration. How is knowing that someone failed to log in a useful thing to know? That's just the security system doing it's job and is just noise. What you want to log is the successful logins from remote IP addresses that haven't been seen before, or have previously been seen trying many incorrect combinations of username and password. That's a significant event.