It is easy to take shortcuts when securing a server, but you will risk data loss in the event that an attacker gains root access to any of your servers. Even for simple installations, you need to secure your server beforehand. Securing servers is a broad topic, and varies depending on the OS and applications being run on them.
This tutorial focuses on securing Apache under CentOS 6. There are a few post installation steps you can take to protect yourself from privilege escalation, as well as under-privileged attacks.
Without further ado, let’s get started.
Step 1 – Installing the web server
Of course, if you don’t have Apache or PHP installed, you should do that now. Execute this command as the root user, or use sudo:
yum install httpd php
Step 2 – Securing your home directories
Now that Apache is installed, let’s go ahead and start securing it. First, we want to make sure other users’ directories are not visible by anyone except for the owner. We’ll chmod all home directories to 700, so that only the respective owners of the home directories can view their own files. Run this command as root, or use sudo:
chmod 700 /home chmod 700 /home/* chmod 700 /home/*/*
By using wildcards, we’re covering all the files currently residing in the home directory.
Step 3 – Apply a security patch to Apache for user privilege separation
Before we patch Apache, we need to first install the repository that contains the package with the patch. Run the following commands as root (or sudo).
yum install epel-release yum install httpd-itk
With “apache2-mpm-itk”, we can tell what user PHP should run as based on the virtual host. It adds a new configuration option
AssignUserId virtualhost-user virtualhost-user-group, which allows us to tell Apache/PHP to execute user code under a specific user account.
If you’re sharing this server, I assume you’ve already created a virtual host for Apache before. In that case, you can skip to step 4.
Step 3 – Creating your first virtual host
You may follow the template below to create a virtual host in Apache.
NameVirtualHost mytest.website <VirtualHost mytest.website> DocumentRoot /home/vhost-user/public_html ServerName mytest.website </VirtualHost>
Open your favorite text editor to
/etc/httpd/conf.d/example-virtualhost.conf and then add the content above into it.
Here’s the command for using nano:
Let me explain the configuration here. When we specify “NameVirtualHost”, we’re actually telling the web server that we’re hosting multiple domains on one IP. Now, in this example, I used
mytest.website as a example domain. Change that to yours, or a domain of your choice.
DocumentRoot is what tells Apache where the content is located.
ServerName is a directive we use to tell Apache the website’s domain. And one last tag,
</VirtualHost>, which tells Apache that’s the end of the virtual host configuration.
Step 4 – Configuring Apache to run as another user
As mentioned earlier, part of securing your server includes running Apache/PHP as a separate user for each virtual host. Telling Apache to do this is simple after we’ve applied the patch – all you need to do is add:
AssignUserId vhost-user vhost-user-group
… to your configuration. Here’s what the example virtual host would look like after we’ve added this option:
NameVirtualHost mytest.website <VirtualHost mytest.website> DocumentRoot /home/vhost-user/public_html ServerName mytest.website AssignUserId vhost-user vhost-user-group </VirtualHost>
The magic is in the line beginning with
AssignUserId. With this option, we’re telling Apache/PHP to run as the following user/group.
Step 5 – Hiding Apache’s version
This step is quite simple; just open Apache’s configuration file by executing the following command as the root user:
Find “ServerTokens”, and change the option after it to “ProductOnly”. This tells Apache to only reveal that it’s “Apache”, instead of “Apache/2.2” or something similar.
Step 6 – Restarting Apache to apply the changes
Now that we’ve secured the server, we must restart the Apache server. Do this by running the following command as root or with sudo:
service httpd restart
These are just a few steps you can take to secure your server. Once again, even if it’s someone you trust that’s hosting a website on your server, you should plan to protect it. In the scenarios above, even if a user account is compromised, the attacker won’t have gained access to the entire server.
Want to contribute?
You could earn up to $300 by adding new articles
Suggest an update
Request an article