Slashdot Mirror
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?
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.
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.
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...
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.
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.
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.
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.
paul reinheimer
If you lock out the account, and not the incoming host, then you simply provide a DoS mechanism to lock out legitimate users.
"National Security is the chief cause of national insecurity." - Celine's First Law
I thought all the cool kids put machines behind firewalls then SSH after connecting to the VPN.
Having to work for a living is the root of all evil.
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.
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'll probably have to go learn about key-based security. But meanwhile, I'm really happy with sshguard. It defends against brute force attacks by monitoring logs and aplying increasingly (exponentially) tougher time-outs as attacks from IP addresses continue. It's reduced my log from 100s of entries per day to about 15. http://www.rferl.org/content/world-press-photo-winners/24903576.html
They've got it in FreeBSD ports, which makes it easy to install into an existing firewall.
If this were Usenet, I'd killfile the lot of you.
Why doesn't somebody invent a tarpitting method, where you write something that'll listen on thousands of ports, completes a fake ssh handshake (slowly), rejects all authentication attempts, logs gropers to fail2ban; but then have your real SSH daemon on a higher port, using certificates only? For you, no problems; for them, like searching futilely for a needle in a haystack...
Wastes the gropers' time, and burns their bots. Get enough people doing this, and it might send a message to the idiots doing it.
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
If you want to end almost any possibility of brute force, load this with iptables:
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.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
I'd never heard of "security through ignorance", but I find it compelling.
Perhaps we could call it "ostriching ".
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
So your saying a 32 char password is better then a 16 char password, whoda thunk it.
Or, to rephrase that, all you've done is make it 500 trillion times harder to crack your ssh (if you're using good passwords), if you are using keyfiles for both then there pretty much needs to be a remote exploit in both the listeners.
I'm running my ssh server on port 23¾ now; that ought to keep the muggles out for a while.
I don't care if it's 90,000 hectares. That lake was not my doing.
The below will create a dynamic blacklist. Any IP address that connects more than three times in five hours (pass or fail) will go into a blacklit that will persist until they stop trying for at least a day.
This will recodr your bad actors _and_ it will "expire" in case you invalidate a system by accident (e.g. over-use).
iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press