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 thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port?"
No, because that's crappy "security".
Denyhosts/fail2ban is a much better solution.
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.
We are preventing this sort of attack on our Linux servers utilizing ConfigServer Firewall and a standard SSH port only we know. It's unlikely somebody is going to find our new SSH port before they are blocked for port scanning by CSF. There are other options then CSF such as cPanel Hulk, but we also like the other options CSF offers such as being able to use a distributed list of IP's to block which allows for a distributed firewall amongst all of our servers. http://configserver.com/cp/csf.html
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.
Correction: most of the hack attempts you're seeing appear to come from China. I expect it's likely most of the attacks would come from botnets, which thrive in China thanks to the high adoption rate of pirate software. The actual hackers could be anywhere.
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?
What's the practical difference between being able to log in to root and being able to log in to a member of the sudoers group?
I've been using google authenticator for a year or so on my linux boxes. It was pretty easy to set up too: https://code.google.com/p/google-authenticator/wiki/PamModuleInstructions
"That'd be quite effective against a single host, but much less effective against a botnet of thousands, each of which gets their quota of 5 tries..."
I disagree with that. Assuming an attacker controls one million bots which is a reasonably big botnet (the largest known peaked at 30 million). That only give him 5 million tries to guess a valid login/password pair. But let's assume, the attacker already knows the login.
Where do you start? There is about 1 million words in the english language. So a simple password choice of one (truely) random english word and adding a single random number defeats the botnet in 50% of the cases.
A common password policy (uppercase, lowercase, 8 characters at least, at least one digit and one special character) would be enough to defeat mid sized botnet without having to do anything.
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.
Like others have said, moving sshd to a high port was never meant to be additional security, just annoyance-reduction to reduce the sheer load in terms of bandwidth and log space. I did that for a while, but then (well over a decade ago) I saw an article about port knocking which is where you (i.e. the sshd) don't answer until the system receives a secret sequence of connection attempts at various ports... i.e. a secret "knock". The secret knock is a kind of password, and can be sent by executing a specialized client, or if you are somewhere where you don't have one available, by manually making telnet attempts, i.e. "telnet 16111; telnet 28123; telnet 22222".
The knock is basically a password for OSI network layer connections. This not only reduces the annoyance level of unsophisticated phishing attacks, but basically eliminates them altogether with a layer of real security. That security is not very strong... in a targeted attack, anyone who can monitor your link layer anywhere along a connection you make can see your secret knock... but it's an easy add-on and better than just playing tag with script-kiddies by moving ssh protocol to a high port.
You regularly connect via SSH from random IPs?
Your phone doesn't have a static IP, neither does a hotel or a random customer whom whose premises you need to quickly fix something. Or aunt Judy, if shit happens to your home server while you're away.
Random IPs in China?
You usually recall you've set up such blocks when you're already on your business trip you didn't expect 5 years ago.
And looking at my logs, they use botnets anyway. Heck, among 37 distinct IPs from today on one box, I see even a pwned IP from Vatican.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
Upon 10 failed attempts on a given account, drop them to a fake shell prompt and log them. Put the longest or most entertaining logs up on a public web page for mockery.
Also known as "how to increase CPU and bandwidth usage on my server tenfold". It's like answering positively to a telemarketing call just to waste their time. It might seem like fun, but your number goes on a suckers list.
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.
The reason people move it, is because that doesn't stop them from trying to log in. Why waste the bandwidth? Also, good luck having a machine with 300+ users using ssh keys. Clearly you own one server, and are the only user. Thanks.
iptables can be fantastically complex and powerful to protect enterprise networks from all manner of attack. It is also fast and easy to do a simple, basic, strong setup which will provide a powerful firewall to secure a server.
Some useful iptables tutorials and references:
1) From CentOS, but iptables runs the same way regardless of OS. This one creates a pretty solid simple iptables ruleset to protect a server.
2) An Ubuntu tutorial, again simple and informative.
3) From the netfilter/iptables project homepage. Good primer on network concepts too.
4) Deeper information, but very useful. Another good discussion of network concepts.
I recommend typing in a simple text file with the iptables commands, the chmod'ing it so that it is executable. Then execute it ("./myrules"). This works for a small, but powerful list of rules that can protect a server. Some of the tutorials talk of rulesets with thousands of lines. There are different, more efficient ways to load those.
Quick overview of iptables:
1) There are three default chains (containers which sets of rules) called INPUT, FORWARD and OUTPUT.
2) Each of these can have a default policy of ACCEPT or DROP. Input should have a default policy of drop. IMPORTANT - while you're first playing with iptables, make sure input has a default policy of Accept ("iptables -P INPUT ACCEPT") or you may well lock yourself out of your machine. Once you've got the rules set up as you'd like (you view the rules with "iptables -L -v"), then you can do "iptables -P INPUT DROP".
3) Always set these three "housekeeping" or basic rules (prefacing with a '#' is a comment):
# For the loopback interface 127.0.0.1, accept everything. Append to input chain.
iptables -A INPUT -i lo -j ACCEPT
# For ICMP packets, accept pings only
iptables -A INPUT -p ICMP --icmp-type echo-request -j ACCEPT
# For established connections, accept everything, using the older state module
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
4) Your input chain, which deals with incoming packets, will have a default policy of drop. Only ports which are then specifically allowed will be open:
# Accept SSH on port 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Accept HTTP on port 80
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Accept HTTPS on port 443
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
5) You're not using your box as a router, so your FORWARD chain should not get any activity. I leave the policy as Accept, so if there is any traffic logged here, I know something unusual is going on:
# Otherwise, accept all for FORWARD
iptables -P FORWARD ACCEPT
6) Finally your output chain should just allow everything:
# Accept everything:
iptables -P OUTPUT ACCEPT
7) Check your iptables ruleset with "iptables -L -v". If everything looks good, set your default input policy to drop with "iptables -P INPUT DROP"
And that is a spiffy, powerful way to block all ports but 22 (ssh), 80 (http) and 443 (https) by using iptables.
There, I fixed the title for you.
I use both a nonstandard port as well as Denyhosts. My block file only numbers in the hundreds, yours in the many thousands. Why? Because every random scan that hits my system flags my IP as "not likely" and moves on, when it hits your IP you get flagged as "valid target" and then you get hit with focused attacks.
If you're going to pretend to understand security, then at least get the saying right. Yes, it's never a good idea to only use obscurity, but there's rarely any valid reason to NOT use it as part of a layered model.
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
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.
Quite simple really. They will find the disgruntled employee, and fire him.
Before anyone else comes in again with "security through obscurity doesn't work", running ssh on a non-standard port certainly isn't.
There's plenty of people out there who are scanning port 22 to find SSH instances. You can bet there's databases out there of IP addresses which responded with ssh and their ssh ident string that they returned. The second an SSH hole is found, those lists will be the first point of call for an attacker who wants to hit known vulnerable systems before they get patched.
If the people building these databases had to scan all ports to find ssh, they'd be spending a very very long time portscanning the internet.
2222 is the worst alternate port you could use, that's probably the second port a multi-port brute-force script will try after 22.
"When information is power, privacy is freedom" - Jah-Wren Ryel