The number of attacks against secure shells protecting Linux boxes, internet routers and other network devices has continued to climb over the past several years, an indication that they still bear fruit for the miscreants who mount them. Data collected by DShield.org, a organization that aggregates firewall logs from across the …
Rule number one ...
.. is actually, if you don't use it, completely remove it.
SSH is easy to fix .. use keys (or certificates) and not passwords .. remember to turn the passwords option off in the sshd config.
Lock them out after a few bad guesses.
Denyhosts is a program which is easy to install and configure. It checks the logs for brute force password guesses and locks out the addresses which try. You still want to choose fairly strong passwords.
There are packages to monitor log files, and take action against attackers, that abate this problem considerably. Fail2ban may be the best-of-breed of these --- powerful, flexible, easy to configure. It can be set to monitor for repeated ssh connections by an IP, and to temporarily firewall off that IP after a settable number of failed logins. An attack that requires hundreds of attempts for a statistical chance of success becomes useless if it is limited to, say, 5.
Fail2ban has really cleaned up my logs. The distributions should be making it part of their standard packages, IMO.
I got sick of seeing the continual barrage of attacks in my logs and on my network monitor so I eventually changed my server to use a port other than 22. I recommend others do the same if it's feasible. It usually is.
The methods change but end result doesn’t
Ok its Friday night and I am in the pub and yes theirs better things for me to be doing but this has enraged me enough to put my beer down and comment:
It was the same ten years ago with telnet but that was susceptible to snooping, with SSH the word secure in its name people let their guards down.
First of its not acceptable and never has been to have your box listing to outside world to SSH at worst if you have to, use portknocking, denyhosts, change the default port number and use an IP well away from the boxies primary IP where all the main services run from, remember smaller the foot print the less you stand out and at best use initial PKI based VPN and SSH access, and then never enable initial root access! The trouble is theses days is that Joe Blogs Window cleaners doesn’t get a managed webspace anymore as a basic hosting package thay get a full root access VM residing on a nice quad core box that WHEN compromised can be used to case significant trouble.
Paris because her box has been compromised loads of times!
@ Richard Kay & Carlo Graziani
This is the correct solution, however learner distros should enable fail2ban by default. It should be part of the meta package in ease of use distributions
@ Richard Stubbs. Fail
If you are so far gone you have to add this for a comment:
"Paris because her box has been compromised loads of times!"
You are pouring good money after bad. Drink little and often and don't use your connection in a pub.
Don't explain the reason you posted an avatar that explains the reasoning of your comment.
When in a pub beware of beer goggles. See rule one.
more sloppy reporting
> attacks against secure shells protecting Linux boxes ... bear[s] fruit
Article URL: http://www.theregister.co.uk/2009/04/17/ssh_attacks
This is not an ssh attack. This is a password-guessing attack. Sure, calling it an "SSH attack" makes for a better headline than "online attackers continue to punish poor password choices", but please credit us with enough savoir faire to know the difference.
I hereby rate this article "vindaloo"--overspiced, and made for plebs.
Keys do avoid passwords, but keys mean that if an account on a box with public keys for other boxes is compromised, the other boxes are wide open.
Fail2ban works very well at shutting out brute force attacks. Using a password cracker to identify simple passwords and configuring PAM to refuse simple passwords on password change completes the circle.
Sysadmins have to make users choose good passwords or at least make it difficult for users to choose simple passwords. It sucks but it was ever thus.
DenyHosts and similar are great if the attacker is brute-forcing from a single IP. However, many of the attacks I see in my logs are coordinated login attempts from hundreds of IPs (presumably botnets), each IP trying just two or three times. Those tools aren't so useful against these sorts of attacks.
Sadly, it's not always possible to avoid using port 22. where I work they obligingly allow port 22 out through the firewall, but not many others, so I can't access my home machine on its traditional non-standard port. Instead, I have port 22 enabled on the home network to a machine that only allows public key access and no passwords. I have an old 16MB memory stick from the days when that was a lot - ideal for holding a private key for temporary use in a remote machine (subject to whatever security caveats apply to using such machines). I also have a script to ban anyone who persists in trying to use port 22 and fails too often.
However, I claim to have some idea about what I'm doing, average Joe isn't going to want to mess with generating key pairs and using them, or will copy the private key to the remote machine's hard disk for convenience.
I actually meant don't use passwords as the single-factor remote authentication method, i.e. passing username and password over the network. The keys or certificates should be handled properly using a strong password to protect the private key anyway .. that is best practice.
If someone keeps their private keys on a server without password protection of the keys then its the 2-factor equivalent of .rhosts ... and yes if you can compromise one machine, you can compromise them all.
Of course, you run sshd on a non-standard port as well, turn off any support for SSHv1 as well and ensure your server key is at least 1024 bits long.
It's pretty straightforward to change the SSH port and only allow certificate based logins. We use Login Failure Daemon (LFD) to perm ban IPs that fail 5 times in a given time period. Also agee with Frumious, this is more about poor password choices than SSH weakness.
I used to see this regularly in my logs (desktop machine, FreeBSD) before I was behind NAT.
Most of the IPs resolved to ISPs in China :-)
Not a problem with denyhosts - http://denyhosts.sourceforge.net/
Also helps if sshd is correctly configured - e.g. only members of the wheel group can ssh in, no root login. This is default on FreeBSD IIRC, but I've seen some Linux distros with slacker defaults. Limiting connections to permitted IP address is a good idea when feasible.
There should be very few members of the wheel group, and avoid obvious usernames such as "admin". Consider using one time passwords if possible (involves playing with PAM).
Distros that have ssh enabled by default should also install & enable denyhosts, and have a conservative sshd.conf. Running sshd on a different port avoids a majority of the connection attempts, but doesn't really solve the problem and shouldn't be relied on alone.
The easiest way to prevent this is surely just to firewall off your sshd port to only allow trusted hosts. OK, PITA if you're using dynamic IP addresses, but that's easily avoided by choosing the right ISP.
Password guessing works poorly when guesses are limited. On Linux, packet filtering can be rate sensitive using the iptables "recent" module. Coupled with a few SSH configuration directives such as
AllowUsers <list only those necessary>
rate-limited packet filtering can be quite effective at frustrating such attacks.
openSUSE can be configured in a single line (in /etc/sysconfig/SuSEfirewall2) to rate limit:
This will cause SSH connections (specifically, TCP SYN packets from anywhere to port 22) from a single source in excess of three to be ignored for five minutes following the most recent. Roughly equivalent iptables directives are
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--update --seconds 300 --hitcount 3 -j DROP
This of course will not prevent a low-speed, distributed, determined attack, but it does keep out the riff-raff. No additional program is required (such as log watchers). Note that the packet filters are not aware if traffic is legitimate or not; one can be hoist on one's own petard.
And, by the way, security via obscurity is not effective security.
No, don't use things like fail2ban!
The danger with things like fail2ban and denyhosts is that you've now got an additional lump of software that's exposed to the internet, and this one may not have been written by people quite as smart as the ssh developers. See for example the following CVEs: 2007-4323 2006-6301 2007-5715 2007-4321 2009-0632. The most common problem is that the attacker can attempt to log in with a malformed username which gets written to the log; the log file parser is confused by this and does something undesirable.
They also don't excuse you from using strong passwords since it's quite easy for an attacker to launch a distributed attack where each password guess comes from a different IP.
If you can't live with untidy logs, or want to save the cost of the CPU needed to do the encryption, then I suggest just using a non-standard port number.
As it hasn't been mentioned yet
Perhaps it is too obvious, but no one seems to have mentioned using AllowUsers in the sshd_config - not something most Linux distros do by default, but very often essential.
Thank you! I don't know why all the nutters in this thread are talking about some shit called "Fail2ban" when you can easily achieve the same thing with bog-standard iptables.
I don't know, kids these days, etc...
Why doesn't the OS lock the account being attacked after 3 wrong passwords or at least suspend it for a while. If the attack continues against the same account extend the time of the suspension or lock it out.
If the same address is hitting lots of accounts (or non existent accounts) block it.
The big question is why does Linux need add-on packages to do any of this? It has been built in to VMS for years.
The penguin has been chosen as a mark of my cynicism.
Erm, I'm sure WINDOWs has has this built-in for ooooh years...?
Go on penguintards, flame away!
> Why doesn't the OS lock the account being attacked after 3 wrong passwords
That would make DOS attacks a bit too easy wouldn't it?
Agreed... I was going to post that - it's basic iptables configuration and I'm surprised someone would want an app to do it. The same technique works for DNS amplification attacks and for misconfigured NTP clients.
SSH server owners can try SSHblack which blacklists IP addresses that fail authentication.
Anyone want to take bets on the OS the attackers are using? I say give them a Honeypot full of bad honey.
Follow the Slicehosts tutorials
Slicehost have some pretty good tutorials on securing Linux boxes - here's page 1 (of 2) for Debian Lenny:
The whole point of fail2ban
...for those of you who it obviously escapes - what if you need to have your SSH available to a large number of hosts? What if you need to support a number of users who might connect from multiple locations? What if you need to SSH from a shared machine that may possibly be compromised by another user being an idiot? What if you need to SSH from a NAT'd address space?
IPtables is fine if you have a limited and reasonably static number of machines you need to connect from, and those machines have static IP addresses, and no-one else has access to them. Otherwise, fail2ban is a useful tool. There's nothing wrong with a combination of those approaches, say, denying connections from all networks but the NAT'd one you use some of the time, but still using Fail2ban in case another one of the thousands of hosts on the NAT'd network is compromised.
I can say Fail2ban also the bees knees when it comes to monitoring SMTP connections, and cutting off dictionary and bot connections quickly.
You can lock out accounts in *nix (using the tally2 PAM module). It can be useful, but it doesn't prevent someone trying to bruteforce different accounts, and allows you to maliciously block other people's accounts.
I won't go into the stuff my Linux boxen can do that my Windows box can't, the list is too long. :P
iptables drop connection rule is nice
I have some iptables rules running on the firewall that allows 2 entries, after that it just drop the connections for a given time. the nice thing is that the poorly written password checking scripts will then hang until connection timeout, making the scripts highly inefficient, taking very long time to finish the list of passwords to guess.
One day I'll get around to doing this...
Write a little APP that sits on port 22 and when a connection arrives, make a connection back to the same IP address. Then just pipe the traffic through both ways and hope they try deleting something important before they realise who they're hacking.
I only allow ssh from two or three outside IPs.
My logs are full of entries about denied ssh connections from lots of places, not just China.
I'm not sure how iptables-drop-connection or fail2ban would improve on this.
- Vid Hubble 'scope scans 200,000-ton CHUNKY CRUMBLE ENIGMA
- Bugger the jetpack, where's my 21st-century Psion?
- Google offers up its own Googlers in cloud channel chumship trawl
- Interview Global Warming IS REAL, argues sceptic mathematician - it just isn't THERMAGEDDON
- Apple to grieving sons: NO, you cannot have access to your dead mum's iPad