I have been searching for a while now. But i can't find a start-up and advanced sought-of checklist to understand the most important things to consider while going for dedicated hosting server for a website/application.

I am working with a college and we have installed an IBM server there.

  1. OS: CentOS 6.4
  2. Application Type: PHP/MYSQL
  3. Terminal access software: PuTTY with SSH (I have also created Public|Private tokens)

Other software which I have installed are:

  1. Virtualmin (Helped me to install LAMP stack)
  2. Memcached

Basically I have followed all steps which I have found in this tutorial at youtube. I found it decent to understand as it gave me a start: http://www.youtube.com/watch?v=lpJfFZoWeho

But this was not core about security.

I just want to know, like all other newbies that what would be the best checklist that I can go through and learn to assure that things are secure on broader aspects.

It would be a great help for everyone who just want to start.


@Terry's advice is quite solid. Let me offer a more conceptual view.

Your server will be secure if everything that runs on it is accounted for and appropriately maintained. While this sounds like a tautology (it is), it points at some general principles:

  • Always apply security updates from the software vendor. Linux distributions have tools for that; let them run.
  • If possible, don't install software which does not come from the Linux distribution vendor, because extra software means extra work to apply security patches.
  • Don't run anything that you do not need. A new, blank OS installation tends to spawn quite a number of services which are not strictly necessary for your operations. In particular, use netstat -a to see what remotely reachable services are on your machine, and lsof to find the corresponding process.
  • Make sure that, at any time, there is a properly defined chain of responsibility. If something bad happens, people should know who to contact and how. A server without a clearly defined sysadmin is a server which will soon be part of a botnet, or already is. Make sure that when you go on holiday, there is someone else available to fill in for system administration tasks.
  • Make backups. Keep several successive backups instead of keeping just the last one. This helps a lot for recovery after an attack, if only for postmortem analysis. Remember that your server is meant to run a service: availability is a primary goal. Frequent and comprehensive backups can help you put the service online faster.

Red Hat provides a security guide for RHEL 6, which is also applicable to CentOS. This is available here. CIS also provides a rather decent checklist located here.

However, if this server is for anything remotely important, I'll highly recommend hiring an expert to perform a thorough audit of your system for you.


Keep your software patched, especially software that accepts input from untrusted sources (i.e. users, the internet, anyone who isn't you).

Only allow what is necessary. Example: don't allow global inbound SSH, only allow connections from the IP range of your offices.

Avoid configurations where users can put themselves at risk. Example: require SSH keys and disallow passwords. It's easy for a user to pick a bad password, it's much harder for them to pick a bad private key.

Ensure your database queries are resistant to SQL injection

Ensure your document root is well defined and you're not serving up more files than you intend.

Minimize privileges your database accounts have (they probably don't need table drop and create, for example)

Avoid any places in code where you're taking user input and executing or evaluating it

Identify your weak points and install protective mitigations. Example: memcached doesn't have great access control features, so bind it to localhost or block unwanted inbound connections with IPTables.

Delete data belonging to your users that no longer has value for you. You can't lose what you don't have.

In a hosting environment, understand that your host has access and control over that environment as well so there are going to be some risks you can't avoid. If they misbehave or make mistakes, you're data and systems will be at risk. Probably not fine for state secrets, maybe an acceptable level of risk for your site. That's a judgement call you'll have to make on your own.

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