Please contact your support team if you have a question or need assistance for any Rackspace products, services, or articles.
If you think your server has already been compromised there are some steps you can take to resolve this. Take a look at this Community article, this article goes over a few of the steps you can take to resolve the compromise.
Ideally you would never want to have to resolve a compromised server issue. The best thing to do would be to harden the server from the beginning to minimize the possibility of a compromise. We have a Knowledge Center article that goes over how to harden the server to prevent compromises, this article covers the basics of securing user(s), SSH login, and some basic firewall rules. This article is by no means an exhaustive list of how to secure a server, it is not meant to be - It is merely a starting point. To further harden a server you can get some good info from these links:http://cloudfaqs.wordpress.com/2013/09/14/20-linux-server-hardening-security-tips/http://www.gtcomm.net/blog/securing-a-linux-server-hardening-ssh-security/http://security.stackexchange.com/questions/18480/building-a-secure-server-with-centosSome examples of steps I take on my own servers are to:
This Community article goes over adding a normal user, adding them to the sudo group for administrative access, changing the SSH default port, setting up SSH keys via Putty (Windows SSH client), and common sample iptables (firewall) rules.
There are some additional steps you might want to consider when looking into hardening your server:
https://community.rackspace.com/products/f/25/t/531You will find most if not all of these steps covered in the articles linked above.All of the steps I have listed only cover some of the ways of hardening the basic OS functionality, however most attacks happen at the application layer. That is a different and additional layer that is far too broad to even begin to go into.
Great stuff here, thanks, Chris.
I especially agree with these items you listed:
Some examples of steps I take on my own servers are to:
A good time saving trick is to create a server, lock down everything, then take an image of the server, to be used the next time you need a server. That will save you all of the effort of locking things down the second+ time through. For example, if you've followed everything Chris mentioned above, a new server based on that image will already prevent root login via SSH, which isn't a problem since your SSH user and Key are already configured on the new server.
Thanks again for sharing, Chris.
Alan BushTechnical Community ManagerRackspace Cloud