How to secure a LAMP server on CentOS or RHEL

LAMP is a software stack composed of Linux (an operating system as a base layer), Apache (a web server that "sits on top" of the OS), MySQL (or MariaDB, as a relational database management system), and finally PHP (a server-side scripting language that is used to process and display information stored in the database).

In this article we will assume that each component of the LAMP stack is already up and running, and will focus exclusively on securing the LAMP server(s). We must note, however, that server-side security is a vast subject, and therefore cannot be addressed adequately and completely in a single article.

In this post, we will cover the essential must-do's to secure each part of the stack.

Securing Linux

Since you may want to manage your CentOS server via ssh, you need to consider the following tips to secure remote access to the server by editing the /etc/ssh/sshd_config file.

1) Use key-based authentication, whenever possible, instead of basic authentication (username + password) to log on to your server remotely. We assume that you have already created a key pair with your user name on your client machine and copied it to your server (see the tutorial).

PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

2) Change the port where sshd will be listening on. A good idea for the port is a number higher than 1024:

Port XXXX 

3) Allow only protocol 2:

Protocol 2

4) Configure the authentication timeout, do not allow root logins, and restrict which users may login, via ssh:

LoginGraceTime 2m
PermitRootLogin no
AllowUsers gacanepa

5) Allow only specific hosts (and/or networks) to login via ssh:

In the /etc/hosts.deny file:

sshd: ALL

In the /etc/hosts.allow file:

sshd: XXX.YYY.ZZZ. AAA.BBB.CCC.DDD

where XXX.YYY.ZZZ. represents the first 3 octets of an IPv4 network address and AAA.BBB.CCC.DDD is an IPv4 address. With that setting, only hosts from network XXX.YYY.ZZZ.0/24 and host AAA.BBB.CCC.DDD will be allowed to connect via ssh. All other hosts will be disconnected before they even get to the login prompt, and will receive an error like this:

(Do not forget to restart the sshd daemon to apply these changes: service sshd restart).

We must note that this approach is a quick and easy -but somewhat rudimentary- way of blocking incoming connections to your server. For further customization, scalability and flexibility, you should consider using plain iptables and/or fail2ban.

Securing Apache

1) Make sure that the system user that is running Apache web server does not have access to a shell:

# grep -i apache /etc/passwd

If user apache has a default shell (such as /bin/sh), we must change it to /bin/false or /sbin/nologin:

# usermod -s /sbin/nologin apache

The following suggestions (2 through 5) refer to the /etc/httpd/conf/httpd.conf file:

2) Disable directory listing: this will prevent the browser from displaying the contents of a directory if there is no index.html present in that directory.

Delete the word Indexes in the Options directive:

# The Options directive is both complicated and important.  Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
Options Indexes FollowSymLinks

Should read:

Options None

In addition, you need to make sure that the settings for directories and virtual hosts do not override this global configuration.

Following the example above, if we examine the settings for the /var/www/icons directory, we see that "Indexes MultiViews FollowSymLinks" should be changed to "None".

<Directory "/var/www/icons">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
<Directory "/var/www/icons">
    Options None
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
Before After

3) Hide Apache version, as well as module/OS information in error (e.g. Not Found and Forbidden) pages.

ServerTokens Prod # This means that the http response header will return just "Apache" but not its version number
ServerSignature Off # The OS information is hidden

4) Disable unneeded modules by commenting out the lines where those modules are declared:

TIP: Disabling autoindex_module is another way to hide directory listings when there is not an index.html file in them.

5) Limit HTTP request size (body and headers) and set connection timeout:

Directive Context Example and meaning
LimitRequestBody server config, virtual host, directory, .htaccess Limit file upload to 100 KiB max. for the uploads directory:

<Directory "/var/www/test/uploads">
   LimitRequestBody 102400
</Directory>

This directive specifies the number of bytes from 0 (meaning unlimited) to 2147483647 (2GB) that are allowed in a request body.

LimitRequestFieldSize server config, virtual host Change the allowed HTTP request header size to 4KiB (default is 8KiB), server wide:

LimitRequestFieldSize 4094

This directive specifies the number of bytes that will be allowed in an HTTP request header and gives the server administrator greater control over abnormal client request behavior, which may be useful for avoiding some forms of denial-of-service attacks.

TimeOut server config, virtual host Change the timeout from 300 (default if no value is used) to 120:

TimeOut 120

Amount of time, in seconds, the server will wait for certain events before failing a request.

For more directives and instructions on how to set them up, refer to the Apache docs.

Securing MySQL Server

We will begin by running the mysql_secure_installation script which comes with mysql-server package.

1) If we have not set a root password for MySQL server during installation, now it's the time to do so, and remember: this is essential in a production environment.

The process will continue:

2) Remove the anonymous user:

3) Only allow root to connect from localhost:

4) Remove the default database named test:

5) Apply changes:

6) Next, we will edit some variables in the /etc/my.cnf file:

[mysqld]
bind-address=127.0.0.1 # MySQL will only accept connections from localhost
local-infile=0 # Disable direct filesystem access
log=/var/log/mysqld.log # Enable log file to watch out for malicious activities

Don't forget to restart MySQL server with 'service mysqld restart'.

Now, when it comes to day-to-day database administration, you'll find the following suggestions useful:

  • If for some reason we need to manage our database remotely, we can do so by connecting via ssh to our server first to perform the necessary querying and administration tasks locally.
  • We may want to enable direct access to the filesystem later if, for example, we need to perform a bulk import of a file into the database.
  • Keeping logs is not as critical as the two things mentioned earlier, but may come in handy to troubleshoot our database and/or be aware of unfamiliar activities.
  • DO NOT, EVER, store sensitive information (such as passwords, credit card numbers, bank PINs, to name a few examples) in plain text format. Consider using hash functions to obfuscate this information.
  • Make sure that application-specific databases can be accessed only by the corresponding user that was created by the application to that purpose:

To adjust access permission of MySQL users, use these instructions.

First, retrieve the list of users from the user table:

gacanepa@centos:~$ mysql -u root -p
Enter password: [Your root password here]
mysql> SELECT User,Host FROM mysql.user;

Make sure that each user only has access (and the minimum permissions) to the databases it needs. In the following example, we will check the permissions of user db_usuario:

mysql> SHOW GRANTS FOR 'db_usuario'@'localhost';

You can then revoke permissions and access as needed.

Securing PHP

Since this article is oriented at securing the components of the LAMP stack, we will not go into detail as far as the programming side of things is concerned. We will assume that our web applications are secure in the sense that the developers have gone out of their way to make sure that there are no vulnerabilities that can give place to common attacks such as XSS or SQL injection.

1) Disable unnecessary modules:

We can display the list of current compiled in modules with the following command: php -m

And disable those that are not needed by either removing or renaming the corresponding file in the /etc/php.d directory.

For example, since the mysql extension has been deprecated as of PHP v5.5.0 (and will be removed in the future), we may want to disable it:

# php -m | grep mysql
# mv /etc/php.d/mysql.ini /etc/php.d/mysql.ini.disabled

2) Hide PHP version information:

# echo "expose_php=off" >> /etc/php.d/security.ini [or modify the security.ini file if it already exists]

3) Set open_basedir to a few specific directories (in php.ini) in order to restrict access to the underlying file system:

4) Disable remote code/command execution along with easy exploitable functions such as exec(), system(), passthru(), eval(), and so on (in php.ini):

allow_url_fopen = Off
allow_url_include = Off
disable_functions = "exec, system, passthru, eval"

Summing Up

1) Keep packages updated to their most recent version (compare the output of the following commands with the output of 'yum info [package]'):

The following commands return the current versions of Apache, MySQL and PHP:

# httpd -v
# mysql -V (capital V)
# php -v

Then 'yum update [package]' can be used to update the package in order to have the latest security patches.

2) Make sure that configuration files can only be written by the root account:

# ls -l /etc/httpd/conf/httpd.conf
# ls -l /etc/my.cnf
# ls -l /etc/php.ini /etc/php.d/security.ini

3) Finally, if you have the chance, run these services (web server, database server, and application server) in separate physical or virtual machines (and protect communications between them via a firewall), so that in case one of them becomes compromised, the attacker will not have immediate access to the others. If that is the case, you may have to tweak some of the configurations discussed in this article. Note that this is just one of the setups that could be used to increase security in your LAMP server.

Subscribe to Xmodulo

Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.

The following two tabs change content below.
Gabriel Cánepa is a GNU/Linux sysadmin and web developer from Villa Mercedes, San Luis, Argentina. He works for a worldwide leading consumer product company and takes great pleasure in using FOSS tools to increase productivity in all areas of his daily work. When he's not typing commands or writing code or articles, he enjoys telling bedtime stories with his wife to his two little daughters and playing with them, the great pleasure of his life.
Your name can also be listed here. Write for us as a freelancer.

6 thoughts on “How to secure a LAMP server on CentOS or RHEL

  1. I'm surprised to see a security guide for RHEL/CentOS that doesn't mention SELinux. Can you please include best practices around SELinux?

  2. @Adam,
    Thank you for your comment. The reason why I did not include some topics in this article (such as iptables, fail2ban, SELinux, mod_security, and mod_evasive, to name a few) is because this was not supposed to be a full reference guide (articles are limited to about 1000 words). But I must admit that you're right about how useful (and needful) SELinux is, so I will consider writing some sort of follow-up on this article based exclusively on it.

  3. "A good idea for the port is a number higher than 1024"

    No, this is a bad idea. Only root can bind to privileged ports, but regular users can bind to ports above 1024. If you don't know where I'm going with this, then perhaps you shouldn't be writings articles about Linux security.

    • Tomas,
      Thank you for your comment. Although I would have preferred a more nice language (you went ahead to assume that I do not know what I am writing about), you gave place to an interesting discussion.
      We will agree to the fact changing the port where the sshd daemon is listening (to whatever number it is) will not completely secure a server against break-in attempts. But since by default port scanners -such as nmap- will not scan ports higher than 1024 (unless instructed especifically to do so) the higher the number, the better. At least, this has been my experience. I used to run SSH on its default port and got tons of intrussion attempts each day; I changed it to what I thought was a "safe port number" and those attempts just vanished overnight.
      We could go on and on about security here, but as I stated this was meant to be a quick tutorial instead of a full reference guide.
      In addition, I am not the only one who thinks that a port number higher than 1024 is a good idea (for example, please refer to this article from The Linux Foundation: http://www.linux.com/learn/tutorials/305769-advanced-ssh-security-tips-and-tricks).
      I am also aware that some people will even discourage changing the port. So if it works for them as my technique worked for me, that's great.

    • I see you are against using a non-privileged port as an SSH port. Then you should elaborate why it's such as bad idea. You are not helping anyone who is reading this article.

      "If you don't know where I'm going with this, then perhaps you shouldn't be writings articles about Linux security."

      This is really not a mature way to initiate a discussion on the article contributed by a fellow Linuxer. Please learn to share your knowledge that you yourself learned from others, and be more appreciative of the work of others.

Leave a comment

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

Current ye@r *