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

Low Hanging Fruit

[Nerdfest]

It's still just going after low-hanging fruit. Anyone weth any real awareness of security does now allow password-only SSH connections anyway. Key based auth and fail2ban is pretty much required these days. You can always add some port knocking to obscure it a bit if you don't like reading about failed access attempts.

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...

Re:Low Hanging Fruit

[DaveAtFraud]

I've been using key based authentication for ssh for years. I just moved the service to a high port to get rid of all the script kiddy password guessing attempts that were clogging my log file. I also added a "throttle" in iptables:

# Block brute force attacks
# Drop repeated ssh connection attempts within 20 seconds interval
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j DROP --rcheck --seconds 20 --name THROTTLE --rsource

# Accept ssh connection if not attempted within past 20 sec.
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j ACCEPT --set --name THROTTLE --rsource

It just cuts down on the noise. I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).

Cheers,
Dave

Re:Low Hanging Fruit

[cstdenis]

You can brute force a key to....it just takes much, much, much, much longer....

Re:Low Hanging Fruit

[larry bagina]

Just think -- if it was open source, you could submit patches to make it more effective. They're basically fucking themselves over by keeping it closed source.

Re:Low Hanging Fruit

[kiddygrinder]

while it's theoretically possible it's not really worth considering, especially when you're only giving them 4 attempts an hour.

Re:Low Hanging Fruit

[budgenator]

I'd use TARPIT instead.

Re:Low Hanging Fruit

[Pseudonym]

I'm saying that just because an obscurity measure is no substitute for a security measure doesn't mean it's not worth doing.

A sysadmin's time is valuable. A simple measure which eliminates 90% of the noise in a log is almost always worth doing, especially if it doesn't significantly inconvenience legitimate users.

Re:Low Hanging Fruit

[hedwards]

It's not security by obscurity, I really wish this meme would die, seeing as so many people are misapplying it. This is one thing that you can do to make it more expensive to try and crack your systems. It's not the only thing that you should be doing and calling one technique security by obscurity when you can easily figure out which port it is, really just conveys ignorance about what you're talking about.

Anything you can do that makes it inconvenient to try and crack your system is going to help a bit.

Don't rely on security-though-obscurity

[Gaygirlie]

You're being naive and just waiting for a disaster to happen if all you rely on is changing the default port. I, myself, use this application called Denyhosts that bans the IP-addresses that try brute-forcing passwords, and I've set it up to just ban access to any services, not only SSH, after 5 failed attempts. These days I've got thousands of IP-addresses on my hosts.deny - file and it just keeps on growing. That said, use Denyhosts or something similar if you need password authentication or just disable password auth altogether.

Re:Don't rely on security-though-obscurity

[AmiMoJo]

You might as well expire those banned IP addresses after a day because 99.97% of them are compromised machines on dynamic connections. Having a file that size just wastes computing resources (having to check every single one) and slightly increases the chance you won't be able to log in from some random place one day.

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).

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.

Re:Just lock em out...

[msauve]

If you lock out the account, and not the incoming host, then you simply provide a DoS mechanism to lock out legitimate users.

Re:Security by obscurity ...

[Anonymous Coward]

We are talking about banning ranges of IP addresses. Only the last leg of the journey matters. Saying the attackers aren't in China is a difference without distinction.

When an attacker controls 10,000 IPs

[tepples]

An attacker can only try logging in a few times a minute.

How does your system determine which IP addresses belong to a particular attacker's botnet?

I do security by antiquity

[Anonymous Coward]

You see, I don't use SSH, I use plain old telnet. That's right! These kiddies never heard of it!

And if they actually get in, I have a few gigabytes of stories growing up that they have to read. Like the time I was growing up in Idaho. We wore onions on our belts because that was the style back then, Benny Goodman was all the rage and I'd take my best girl - Betsy - to the church dance ... we were all Presbeterian in that town and with one church, new people would just go there - even the Jews because there wasn't a Synagogue - but that's another story and I won't bore you with that because I can be a bit long winded at my age - so anyway my best girl got her new dress and we over to the next town to Jo's soda shop - he had the BEST malts in the entire area - and the whipped cream was made fresh from a local dairy farm - farmer brown's was his name - he served in WWI as an infrantry man in France and boy the stories he told about those French girls - like the one he met, Jaquoline I think or it was Juliette - she had dark hair and hazle eyes and her father was a banker for a German who had a home in France before the war - of course when the war started the Germen businessman had to run home and he ended fighting himself, even though his father pulled some mighty strings to get him out of the German army ...ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

iptables

[markdavis]

If you want to end almost any possibility of brute force, load this with iptables:

/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "sshd_brute_force_block "
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Those three lines will slow the amount of connections by the same ipaddress to sshd. When the attacker reaches 4 hit counts it will be blocked for 60 seconds before resetting. If the attacker keeps attacking before the 60 seconds are up it will reset the the time limit to another 60 seconds. Have been using it for years and it is extremely effective. Even a botnet attack (which is unlikely) would be futile because there just aren't enough attempts.

Seriously, this type of thing should be built directly into ssh. If not this sophisticated, then at least it should include attempt and restart delays which would not be as effective but beat the hell out of the default behavior.

Re:Just lock em out...

[AmiMoJo]

Back at university someone would always use this one lecturer's five login attempts up at some random time once a week. I wonder what large companies do to prevent disgruntled employees trying to log in as steve.jobs or bill.gates and DoSing them every day.

Typical geek shit

[Sycraft-fu]

For some reason, geeks seem to think there is magic, perfect, computer security. "Just do THIS and your servers are secure, nobody can ever break in!" Those of us who've dealt with physical security understand there's NO SUCH THING. Good security is a layered approach. You never rely on one thing for security, you have layers so that when, not if, a layer fails you aren't automatically fucked, the other layers hopefully catch it.

While moving SSH to another port may not be a real big security improvement, security improvement don't have to be big to be useful, particularly if the cost is low, and in this case the cost is zero.

Also here's some news: It is 2013 and just now the bots seem to be adapting. That means that it was pretty effective. Seems to me SSH has been in use for, oh, getting close to 18 years now. That's not a bad amount of time for something to stop the bots.

The sooner geek admins start to understand that there is NO perfect security, ever, the sooner we'll start to have better computer security.

Re:No

[SuperKendall]

I'd never heard of "security through ignorance", but I find it compelling.

Perhaps we could call it "ostriching ".

Re:No I haven't, and here is why:

[Anonymous Coward]

I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel.

And I change languages and character sets every chapter.

Re:No I haven't, and here is why:

[Zaiff Urgulbunger]

I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel. And I change languages and character sets every chapter.

Not bad, not bad! But I'll share a little pro-tip with you; I do all the above, PLUS I turn my monitor upside down when I'm typing in my passphrase so that even if someone stole my SSH key, they'd still have to figure out it's orientation!!

Not a problem

[Jeremi]

I'm running my ssh server on port 23¾ now; that ought to keep the muggles out for a while.