Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

We have clean CentOS 5.6 setup and virtualmin on it, that's all. What type of security steps would you suggest are appropriate? this page have a good summary of checklists i think. which steps on these are required to do? or do you have better suggestions rather then those security hardenings:

(Esspecially ddos and brute force attack protection is a problem it seems)

Firewall Protection:

    APF – Configure both ingress and egress firewall protection.
    BFD – Detect and prevent brute force attacks.
    CPHulk – Detect and prevent brute force attacks.

HTTP Intrusion and DOS Protection:

    Mod_security – Install and configure mod_security for Apache with auto-updating ruleset.
    Mod_evasive – Install and configure DOS, DDOS, and brute force detection and suppression for Apache.
    PHP SuHosin – PHP Hardening through the Hardened PHP Project. Available on request.

Server Hardening:

    Disable IP Source Routing – Enable protection against IP source route attacks.
    Disable ICMP Redirect Acceptance – Enable protection against ICMP redirect attacks.
    Enable syncookie protection – Enable protection against TCP Syn Flood attacks.
    Enable ICMP rate-limiting – Enable protection against ICMP flood attacks.
    Harden host.conf – Enable spoofing protection and protection against DNS poisoning attacks.
    Harden Apache – Prevent module and version disclosure information.
    Harden SSH – Allow only SSH version 2 connections.
    Harden Named – Enable protection against DNS recursion attacks.
    Ensure Filesystem Permissions – Fix permission on world writable directories and prevent against directory-transversal attacks.
    Harden temporary directory and shared memory locations – Enforce noexec, nosuid on tmp and shm mounts.
    Harden “fetching” utilities - Allows root-only access of wget, curl, and other utilties often used in web-based attacks.
    Remove unnecessary packages – removes RPMS which are not needed to prevent against potential vulnerabilities and free up disk space.
    Disable unused services – Disable services which are not used.
    Disable unneeded processes – Disable processes which are not needed for server operation.
    PAM Resource Hardening – Protects against exploits which use core dumps and against user resource exhausting through fork bombs and other shell attacks.
    PHP Hardening – Enable OpenBaseDir protection.

Security Audits:

    Rootkit Hunter – Nightly scan to detect system intrusions.
    Chkrootkit – Nightly scan to detect system intrusions.
    Nobody Process Scanner – Scans for unauthorized "nobody" processes.
share|improve this question

closed as off-topic by Tom O'Connor Aug 25 '13 at 22:25

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must be relevant to professional system administration. Server Fault is a site dedicated to professionals; novice questions are off-topic. Please see the Help Center for more information on topicality. The best advice we can give you is to hire a professional to help you out." – Tom O'Connor
If this question can be reworded to fit the rules in the help center, please edit the question.

btw i am trying to stick to only "epel" reposity as 3th party repo for stability/security. Please consider to using epel via yum while suggesting to install some apps. – Ünsal Korkmaz Apr 23 '11 at 15:16

This is a wide range question and my first answer may sound rude:

Remove Virtualmin!

Please don't get this wrong, but the possibility to open some doors with some clicks points directly to the biggest security thread: The subject between keyboard and chair.

If you want a secure setup, you should:

  • Only install, whats needed
  • Only run, whats proper configurated
  • Check the security advisorys for all software, you install
  • always check the "paranoid" section of software documentation, if you are.
  • try to use techniques that are maybe installed (apparmor,SELinux)

If you have a big automated security stack, you don't understand at all, you may have a bigger risk of getting hacked, than you would have with a small stack, you really know.

The biggest common mistakes in hosting environments are the webapps and the db(connection) settings. Take good care of Joomla and friends, make your DB only listen on localhost. Always use settings restrictively as possible. For example: Avoid chmod 777, read your logs. Monitor the machine with nagios. Be paranoid.

I'm really sure, you'll find help in specific cases here. In much cases "secure setup OS APPLICATION" produces a useful search result on a search engine of your choice.

share|improve this answer
dont get me wrong but its better to use virtualmin (or another panel) rather then installing apache,mysql as ultra newbie about server management. – Ünsal Korkmaz Apr 23 '11 at 15:11
you may think that. Because it brings some results. The other aspect is, that virtualmin/webmin sometimes mess up config files and is harder to debug then. – ansi_lumen Apr 23 '11 at 15:38
Apache is really not a big deal and well documented. The complications with virtual hosts are some years ago. MySQL is installed and secured really quickly. I would offer you, to guide you here step by step through the relevant steps. May take a few days at all, but gives you a solid base. – ansi_lumen Apr 23 '11 at 15:44
dude, i agree with ansi_lumen. Get rid of that shit. If you can't understand how to configure apache then you should not be the person in charge of making security decisions. – Jordan Eunson Apr 25 '11 at 5:36

Along with forcing SSH to version 2, don't forget to disable root logins, and preferably, disable password logins and force key based authentication. Also, its a very good idea to change the default port for SSH.

For the firewall, make sure to set the default rule for each of them to Deny, then specifically allow rules to Accept.

We also use DenyHosts to ban machines that are known attackers, or that fail too many attempted logins.

share|improve this answer

If you can't understand how to configure apache then you should not be the person in charge of making security decisions

share|improve this answer

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