I have a Debian Apache PHP server. I want to secure it after the classic installation process.

My usual steps are :

  • list items
  • update all packages
  • remove all unnecessary services like named, portmap, lwresd...
  • add a startup iptables script: block everything except 22 and 80 inside and allow all outside. Force SYN packets check, force fragments packets check, drop XMAS packets, drop Drop all NULL packets, drop local ip on wan, all only icmp type 0 and 8.
  • SSH : remove root login and password authentication. Use keys instead. Allow only the valid username. Protocol 2 only
  • PHP : expose_php=Off, limit PHP modules to used one's, don't display errors to the visitor: display_errors=Off and log_errors=On, allow_url_fopen=Off, allow_url_include=Off and remove dangerous functions
  • Apache: ServerSignature Off, ServerTokens Prod
  • Install additional package: fail2ban (SSH bruteforce protection), chkrootkit (rootkit detection), logwatch (day to day log care), munin (ressource monitoring), apticron (watch for new update)

Do you see something else?

5 Answers 5


I'd recommend getting a host based IDS configured and the signature database populated, removing any content supplied with Apache. Also overhawling the permissions model around logging so that you don't need to be root to read the files.

There's also several things you might want to do depending on what you do with the server - check the timeout and max post size for apache, set an open_basedir for PHP (along with the usual performance tweaks).

  • On the host based IDS one that I've used successfully on debian based systems is OSSEC ossec.net Commented Sep 18, 2012 at 17:58

In addition to the everything you've already done, there are ancillary Debian repositories that you may find it useful to use if you prefer to keep your installation closer to bleeding-edge:

http://www.dotdeb.org/ is a good example

These repositories are by no means a replacement for the official Debian distros; being closer to bleeding edge gives you updates quicker, but it may not have been tested to the same rigorous standards that the Debian package maintainers uphold. As always, it's a trade-off.

If you need to block spammers, moblock can help with this at the IP level, and there are a good selection of managed lists (Bluetack, spamhaus etc).

  • Using another Debian repo doesn't really have much to do with securing a server... much less an unofficial one. A good NIPS/HIPS can do whatever moblock does and more.
    – user10211
    Commented Sep 18, 2012 at 11:16
  • Updates are important, and Debian takes a little longer in some cases to approve and test these, hence the suggestion. snort and friends are great, and IDS is important, but on their own they do not take spam into account without some complex config. You would typically use it in conjunction with Autoshun. Cross-checking blacklists is a quick way of preventing your website (if it hosts user content like comments etc) from becoming a distribution point for XSS attacks and other malicious garbage. Moblock is a simple setup and does well IMO.
    – parallaxed
    Commented Sep 18, 2012 at 13:09

Though it is for Ubuntu, it should help to catch the point: http://www.thefanclub.co.za/how-to/how-secure-ubuntu-1204-lts-server-part-1-basics


Don't forget to edit permissions for www-data and for your SSH user within the web root.

If this is some sort of webapp, and end-users are allowed to upload files, you'll want to make sure nothing they upload is executable. Some clever hacks involve the uploading of binaries disguised as .jpg images onto servers with bad permissions.

This is an excellent post (see best answer) about permissions: https://serverfault.com/questions/357108/what-are-the-best-linux-permissions-to-use-for-my-website


SELinux, if you're inclined to set that up. The Red Hat guide is almost fully compatible with how it's set up on Debian.

  • Please explain how or why you believe SELinux would improve security.
    – this.josh
    Commented Dec 1, 2012 at 7:57
  • @this.josh I'm sorry, but are you joking? Do you know what SELinux is?
    – Kenzo
    Commented Dec 1, 2012 at 22:24
  • I have written and compiled SELinux modules and then bypassed their enforcement. SELinux is a tool that may be used well or poorly. Adding SELinux to a Linux based system will not necessarily make the system more secure.
    – this.josh
    Commented Dec 3, 2012 at 6:00
  • Which modules written by other people have you bypassed?
    – Kenzo
    Commented Dec 3, 2012 at 15:44
  • @this.josh That's what I thought.
    – Kenzo
    Commented Feb 2, 2013 at 8:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .