Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

One customer emailed my about their provider about to shut down a server because ssh attacks.

I logged in to the server and found a lot of ssh-scan processes, and some strange files in /tmp. I had to shut it down, since I didn't know what to do. Before rebuilding the server, is there a way I can find out how this happened in order to prevent it from happening again?

share|improve this question
While this question is on-topic here, you'll find more expertise on Information Security. Do not repost; if you wish, you can ask a moderator to migrate it to the other site (use the flag button for this). – Gilles May 12 '12 at 23:40
Try running ssh-vulnkey to scan the .ssh folders and the machine keys for those vulnerable keys that may have been created during the Debian debacle. Otherwise, it's likely a weak password. In this case I'd attempt to brute-force the hashes from /etc/shadow to see whether that is the case and implement policies on a new machine in the future to prevent the same. – 0xC0000022L May 13 '12 at 21:21

SSH scans are usually brute-force attacks. They just try common usernames with easy, common passwords. I've seen a system get compromised using the guest account, with password ‘guest’. Sigh.

Most machines are sprayed with such packets all the time. As a blanket solution, I like to do two things on the firewall:

  • Use geoip and ipset to allow access to port 22/tcp from specific countries only. There's a unusually high percentage of these attacks originating in .cn netblocks, for instance.

  • Use rate limiting on 22/tcp SYN packets so that the same IP address can only connect N times a minute before getting blocked for 10 or 15 minutes. This deters scanning software, and also slows down potential damage to other people's networks. It's a community service.

There are other ways too depending on your needs and restrictions.

On the target computers themselves, you should also lock down system accounts and implement a password policy that forbids easy passwords (wordlist checking, minimum length, etc).

share|improve this answer
Frankly, I'd say forbid passwords for authentication with SSH as it is a lot safer than password, unless one uses some of those affected keys from the Debian debacle. – 0xC0000022L May 13 '12 at 21:19
Yikes, don't remind me. Stayed up all night rekeying hosts, VPNs etc when the announcement came out. And I use Cluster SSH. Debian released packages that warn you about dodgy keys, though so if anyone still has affected keys, they're idiots. Anyway, about SSH auth: I agree in principle, but I've noticed some people find it just as easy to have a pathetic passphrase (or no passphrase at all, sigh), so the overall security can be even lower than password authentication. At least you an impose password quality restrictions server-side. – Alexios May 13 '12 at 23:43
no passphrase is no sin as long as the key is stored securely (e.g. in an encrypted container). But I guess I understand what you mean and agree. Security and convenience still contradict each other too often and users will always choose convenience. – 0xC0000022L May 14 '12 at 0:24

Check the webserver logs for patterns in errors and access logs. Start with the error logs. Same for auth.log, for brute force login attacks. If you just rebuild your server with the same webapp or password on SSH, it'll be only a couple of days before you're hacked again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.