Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

I'm running CentOS 5.5 (basic LAMP with Parallels Power Panel and Plesk) and have thus far neglected security (because it's not my full-time job, there is always something more important on my todo-list). My server does not contain any secret data and also no lives depend on it - Basically what I want is to make sure it does not become part of a botnet, that is "good enough" security in my case.

Anyway, I don't want to become a full-time paranoid admin (like constantly watching and patching everything because of some obscure problem), I also don't care about most security problems like DOS attacks or problems that only exist when using some arcane settings.

I'm in search of a "happy medium", for example a list of known important problems in the default installation of CentOS 5.5 and/or a list of security problems that have actually been exploited - not the typical endless list of buffer overflows that "maybe" a problem in some special case.

The problem that I have with the usually recommended approaches (joining mailing lists, etc.) is that the really important problems (something where an exploit exists, that is exploitable in a common setup and where the attacker can do something really useful - i.e. not a DOS) are completely and utterly swamped by millions of tiny security alerts that surely are important for high-security servers, but not for me.

Thanks for all suggestions!

share|improve this question
Although I wouldn’t know how to answer your question (which features should be enabled/disabled to make centOS safer [probably you don't need to do much]) i still would like to say that configuring a firewall and understanding just how many attempts to break into your server you have (and their nature) could be very useful to understand which services need most your attention. I use CSF firewall for this purpose. – Bruno Flávio Jun 5 '12 at 8:12

You could do a lot worse than starting with the sans security checklist.

You might not be too bothered about what your server is (ab-)used for, however if the trail of a police investigation leads back to you then the insecurity of your system could prove very expensive. I'd recommend setting aside at least 3 full days to get your system up to spec.

Once you've removed all the services you don't need, then applied all the patches to the stuff you do need, then the really important stuff is:

  • ssh - restrict access to a named group / individuals - not root
  • add additional protection for ssh such as port knocking or fail2ban
  • make sure you're not running an open http proxy
  • plan to check for and apply security patches at least once per month

This should give you a basic and maintainable level of security.


share|improve this answer

I suggest the absolute basics are,

  1. Implement iptables (whatever you find easiest, hand crafted or one of the small or large pre-built packages) and lock down access to non-public services to a specific list of sources (e.g. allow everyone to get to the web service, but only a subset of IP addresses you are in control of get access to ssh). Use products like DenyHosts, Fail2Ban.
  2. Patch everything on a regular schedule. Lots of people are keeping up with security issues for you already, and rolling security patches into the OS and applications, use that experience, and simply stay on top of updates.
  3. Use some of the standard log monitoring or intrusion detection products which will alert you of suspicious behaviour (LogWatch, AIDE, etc.)

I don't know what security releases are like for CentOS, I usually use Debian which has an excellent track record in that area.

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.