Brutish SSH attacks continue to bear fruit 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 …
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.
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!
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.
Reggies Law:
Rule one:
Don't explain the reason you posted an avatar that explains the reasoning of your comment.
Rule two.
When in a pub beware of beer goggles. See rule one.
> 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.
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.
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
MaxStartups 1
LoginGraceTime 10s
AllowUsers <list only those necessary>
MaxAuthTries 1
PermitRootLogin no
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:
FW_SERVICES_ACCEPT_EXT="0.0.0.0/0,tcp,22,,hitcount=3,blockseconds=300,recentname=ssh"
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.
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.
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.
...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
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
