With the advent of virtual computing or more commonly referred to these days as cloud hosting, it’s possible for more people to run ‘full’ servers as the costs have come down. Frequently these servers are Linux servers of one flavour or another depending on the experience of the user.
Virtual platforms deploy ‘servers’ as default (and sometimes outdated) systems. Whilst these systems are set up for ease of use they are not set up for security. Mainly this is because each situation that someone may want a server for is different. There is no magic bullet or blanket ruleset in terms of securing a server.
With Linux in mind there are common issues that contribute to the insecurity of a server.
- Old or insecure daemons that have not been updated
- Weak access passwords and methodology
In terms of common hacks these days it’s really the last two points that have most relevance.
Users are a necessary evil. They require access to the system but there needs to be a balance between functionality and security. As expected, users want maximum functionality whilst admins want maximum security.
Common issues caused by users are the flipside of this article namely the security of the users themselves and what attackers can upload to your system with user permissions. For example, an attacker could upload a freely available php shell script, and if web accessible this gives the attacker a command line prompt to your system with webserver permissions. Of course, this should be locked down aswell but there are many systems that (incorrectly, of course) run their webservers as the root user.
The methodology of the server setup is another common stumbling block. Do the users need shell access? Who needs superuser access apart from the owner? Do you allow superuser access from anywhere, on the standard default ports?
For example, we recently set up a virtual server on a brand new allocated IP address and left direct root access open. Within 30 minutes there were authentication attempts from random IP addresses trying to guess the root password, and also no doubt probing for insecurities in the authentication daemon (OpenSSH in this case). Bots are scanning vast ranges of IP addresses all the time.