Securing a LAMP server (Part 1)

lampWeather you are just starting out and want some basic tips or you have run a server for a while there comes a point when you realise a need for security on it, by default a lot of configurations are set incorrectly or not at all. Hopefully these articles will shed some light on the fundamentals.

I’m going to cover securing the typical LAMP set up, with the exclusion of Linux security, since that is a much larger topic that I may cover at a later date. This will be a two part article with the first covering securing Apache and the second MySQL & PHP.

For those who don’t know a ‘LAMP server’ is a system generally consisting of Linux, Apache, MySQL & PHP.

Linux – The operating system the server runs, it could be Debian, redhat, ubuntu or any variant in between, similarly a ‘WAMP server’ is a server running on Windows rather than Linux.

Apache – The web server which deals with requests and responds to the users, you can think of this as the glue, a user asks for X web page and the web server, parse the underlying code, gets, compares or adds the┬ánecessary data from/to the database, then displays whatever information is needed back to the user.

MySQL – The database that runs in the background, this could be any alternative (PostgreSQL, MariaDB, CUBRID) for this article I will assume you are using MySQL, the most implemented one.

– The programming language behind the website, again we are focussing on PHP for this article, but this could also be any language, some alternatives are Perl, Python, Ruby, Django or C (although these are less common)
So without further ado:

Apache security

Unnecessary modules – Apache comes with default modules enabled, in most use cases these are unnecessary and could cause potential problems. To disable simply edit the httpd.conf file and put a “#” before any LoadModule that you want to disable (commenting it out) some modules that are recommended to disable are:
mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.
This obviously is wildly different for each environment and is up to you to decide what you need or not, to find out what each module does you can read a description on the module index. Remember to restart apache after any changes.

User and group settings – It is best practice to run apache from it’s own non-privileged account. To do this first create the user and group:

groupadd apache;
useradd -d /usr/local/apache2/htdocs -g apache -s /bin/false apache

then simply edit the httpd.conf again to reflect this (User apache, Group apche)

Restrict access to root – Another httpd.conf edit, you want to stop users from accessing the root directory, this is enabled by adding the following:

<Directory />
   Order deny,allow 
   Deny from all 

conf and bin directories– These directories should only be accessed by authorized users/accounts. firstly you should create the group by running the command:

groupadd apacheadmin

Then simply change the owner and permissions using the following:

chown -R root:apacheadmin /usr/local/apache2/bin
chmod -R 770 /usr/local/apache2/bin
chown -R root:apacheadmin /usr/local/apache2/conf
chmod -R 770 /usr/local/apache2/conf

If you need to add a user to the group just run:

usermod -a -G apacheadmin

httpd.conf hardening – This disables directory browsing, server side includes, CGI execution and symbolic links, you would think such a command should be massive, incorrect. Simply add “Options None” if you are restricting root access also your httpd.conf should now look like or include:

<Directory />
   Options None
   Order deny,allow 
   Deny from all 

Disable .htaccess – To disable .htaccess use you can add the command “AllowOverride None” in the httpd.conf also

Apache version banner– This is set to send everything by default (apache version, OS, php version) making an attackers job easier. To disable this add the following line to httpd.conf:

ServerSignature Off
ServerTokens Prod

Lower Timeout – Lowering this could potentially help if ever faced with a denial of service attack, to change this again in the httpd.conf, add the following (the numbers are seconds):

Timeout 45

Limit large requests – Also good for protecting against DoS attacks, the lower the number the better, This is about finding a balance between what your users need and what you want to allow. the numbers after LimitRequestBody are bytes you allow the user to upload, LimitRequestFields is the number of headers you will accept & LimitRequestFieldSize is the size of the headers you will accept, an example would be (again httpd.conf):

LimitRequestBody 102400 
LimitRequestFields 30 
LimitRequestFieldSize 4094

Adjust KeepAlive settings – Unless your server is extremely high load this should be kept on, however fine tuning it depends on the servers specs, optimizing this is for performance and the possible mitigation of DoS attacks. I would however recommend some minimums of:

KeepAliveTimeout 5
MinSpareServers 10
MaxSpareServers 20
StartServers 10
MaxClients 250
MaxRequestsPerChild 300

Immutable bit – Although not foolproof it could thwart some attacks and keep your config file from being seen, to set the immutable bit on your httpd.conf run the following command:

chattr +i /path/to/httpd.conf

mod_security -This module implements a web application firewall, detecting, logging and blocking suspected malicious requests, protecting against most common attacks, RFI, LFI, SQL injection, XSS and more.

mod_evasive -This module focused on mitigating against denial of service attacks, emailing you the results it finds as it does so.

mod_httpbl -This module blocks visitors to your website that are known attack sources, utilizing the database created by “Project Honey Pot”

Run in a Chroot environment – This used to be an incredibly difficult task to accomplish, and although difficult still well worth doing, however now with mod_security this has become a walk in the park. Firstly mod_security must be first on the list of modules (httpd.conf):


AddModule mod_security.c
AddModule ...
AddModule ...
AddModule ...

Next you would need to add the following line to “modsecurity.conf”:

SecChrootDir /chroot/apache

Lastly you can start Apache with the following comand for it to be in it’s own jail:

chroot /chroot/apache /usr/local/web/bin/apachectl start

I hope you have enjoyed this first part and hopefully learnt a some fundamentals about securing Apache, and stay tuned for part 2 where I will delve into securing MySQL & PHP.
As always comments and likes/shares are always appreciated.

Sharing is caring!

Leave a Reply

Your email address will not be published. Required fields are marked *