Take the 2-minute tour ×

Possible Duplicate:
My server’s been hacked EMERGENCY

I got a 32-bit Debian VPS from http://linode.com and I really haven't done any sort of advanced configuration for securing it ( port 22; password enabled ).

It seems somehow there is ssh scanning going on from my IP, I'm being flagged as this is against the TOS. I've been SSHing only from my home Comcast ISP which I run Linux on.

Is this a common thing when getting a new vps? Are there any standard security configuration tips? I'm quite confused as to how my machine has been accused of this ssh scanning.

share|improve this question

marked as duplicate by Michael Hampton, John Gardeniers, freiheit, sysadmin1138 Nov 12 '12 at 23:14


add comment

4 Answers

up vote 6 down vote accepted

Personally, it sounds like you have been compromised. I would re-install the OS and then reconfigure SSH with:

  • key-based auth only
  • use AllowUsers or AllowGroups to lock down users allowed onto the box
  • make use of iptables to lock down allowed IP addresses.
share|improve this answer
How did I get compromised though? –  meder May 9 '10 at 6:58
Read your logs and find out. Although the relevant entries may no longer exist. –  Ignacio Vazquez-Abrams May 9 '10 at 7:30
Which log files? I don't have apache setup atm. –  meder May 9 '10 at 8:37
Possibly a weak password. –  David Rickman May 9 '10 at 8:40
Read log files such as /var/log/auth.log to see who logged in or attempted to log in and which user they logged in as. Other log files such as /var/log/syslog will show more comprehensive, general information that can also give clues. Remember the attacker may have had access to modify or delete these logs. Also, this should not be a substitute for reinstalling the OS. –  thomasrutter Nov 12 '12 at 4:20
add comment

Many system compromises are the result of being scanned and a weak password being brute forced. Unfortunately, this has become part of everyday internet life and you need to secure your server against such attacks. Here is a good guide for getting started:


share|improve this answer
good guide, sound advice. –  bobby May 18 '10 at 0:51
add comment

This stared as a comment on freedom_is_chaos's answer, but grew too large...

@Meder: Other services, such as SSHd itself, keep logs - not just Apache. Though any well coded exploit (or an exploit created by a good quality off-the-shelf-exploit-generator) will probably cove its tracks once it gets in.

A poorly chosen password for root or an account that has sufficient privileges via sudo is the most likely attack vector here, given the exploit is making many SSH connections (to try spread itself to other servers the same way it infected yours). You need to stop the VM immediately. The longer it is up the longer it is a problem, potentially causing further infections.

If you have any data on the VM that you want to keep still shut it down immediately - don't mess around taking backups first because unless things have changed since I last use Linode's services you can create a fresh, unexploited, VM and attach the old drive to it to pull data off. Be careful not to trust that data, especially executable binaries and scripts, though - double check anything you use in case it has been modified to make future exploits easier (you don't want to accidentally copy into the new VM a back-door that was installed into the old one).

Also give the page linked to by tasaro a read. That looks like a good summary of how to try secure a simple VM. If you will not (can not for some reason) use key-based authentication at least use strong passwords - don't worry about them being memorable, as you can store them in something like keepass instead of needing to remember them (just make sure you keep your keepass daatase in a safe). While a remote exploit could easily get to something like "elephant4" via a dictionary based brute-force guess it is unlikely to hit upon something like "eGz3nk7aVdN7OIChoPy7". Also make sure that you use different passwords for different services - that way if one manages to slip out somehow you only compromise one service not many others too.

share|improve this answer
Actually, my password was a common word + 1 digit. I rewiped it and changed it to include !, @, letters and a number. –  meder May 9 '10 at 23:56
Sounds like someone could have guessed that. –  David Z May 10 '10 at 0:47
What would happen if you disabled Password Authentication and somehow lost your local private key which you haven't backed up? –  meder May 10 '10 at 0:53
@meder: this is the same as losing a securely chosen password: you would be locked out. In systems like Linode run you could stop the VM, create another along side, connect the old VM's root partition to the new one, and use chroot to take control of the old environment and reset your root password. With other arrangements (like a dedicated server or most VPSs which you can't link up that way) you would need to ask your hosting provider to boot from external media and do something similar (many will charge for this, a few bad apples will refuse or just do an OS refresh and charge anyway). –  David Spillett May 10 '10 at 7:52
Just keep your private key(s) safe, the same way you would a secure password. –  David Spillett May 10 '10 at 7:53
show 2 more comments

The most likely explanation is that your server has been compromised.

What next?

Once you've get a fresh new image, don't forget to disable root login via SSH. That way, you're forced to log in via a user account first then elevate to root using su. Don't give any regular user accounts sudo privileges that don't need it.

It's also a very good idea to use AllowUsers in your SSH config to restrict SSH access to those that need it. If possible, ensure these users have strong passwords somehow.

Why reinstall from scratch?

If you continue to use the same system, you can never be sure you have removed every last back-door the attacker installed. If the attacker exploited an escalation of privileges bug in order to gain root, then he/she would even have been able to replace system and/or boot binaries.

share|improve this answer
add comment
