Virtualmin Tips & Hacks | How to Setup, Integrate and Automate PHP-FPM & Nginx Reverse Proxy in Virtualmin Practical Full Guide
Chapter 1: Installing the Software
If you have just installed Virtualmin on a stock server or VPS, you're probably running CentOS 6 at the time of this writing (October 2014). CentOS 7 has just been released recently, and Virtualmin support for it is not as matured or stable compared to CentOS 6
CentOS 6.5 (and 6.6) ships with the following default software:
PHP 5.3.3 (this version of PHP has reached its end of life and is no longer supported by the PHP team)
MySQL 5.1.73 (a very old version of MySQL server. Current stable version is MySQL 5.5)
Apache 2.2.15 (although aged, it is considered one of the most stable version of Apache ever released. The RedHat/CentOS team is still actively maintaining it)
For the purpose of this book, we will be updating PHP to the latest stable 5.4 and upgrading the aged MySQL server to the current 5.5 from the “EPEL” and “REMI” repositories. We will also install “mod_fastcgi” which is required for Apache to “communicate” with PHP-FPM from the “RepoForge” repository.
A quick note about Software repositories – some 3rd party software repositories may use the same package name as the base CentOS packages – enabling and using these software repositories may cause you to accidentally over-write the standard base packages with those from these 3rd party repositories. Hence, use these 3rd party repositories with care.
TIP: When you run the “yum install ...” command (without the '-y' flag), it will display the package name PLUS the name of the repository it is located. You need to manually enter “y” to confirm the install if want to go ahead and install the software.
EPEL (Extra Packages for Enterprise Linux)
Ref: https://fedoraproject.org/wiki/EPEL
EPEL is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux such as RHEL (RedHat's commercial OS), CentOS (Same as RHEL, but community supported), Scientific Linux (SL) and Oracle Enterprise Linux (OEL).
EPEL packages are usually based on their Fedora counterparts and does not conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager, etc.
Download and Install the EPEL repository:
# wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# rpm -ivh epel-release-6.8.noarch.rpm
(Note: If you're using a different CentOS distro, e.g. 64-bit instead of 32-bit, please visit the EPEL page and download the appropriate rpm package for your machine.
To check for the latest news/updates or software versions, please visit:
REMI:
Ref: http://blog.famillecollet.com/pages/Config-en
The REMI software repository a yum repo maintained by a French programmer - Remi Collet. It usually has the latest version of the software in found in the core CentOS and Red Hat repositories, and it uses the same package names as in the official repositories.
For example, the official CentOS repository uses the name “php-cli” (the command line version of PHP and is based on PHP 5.3.3). IF you install “php-cli” from the REMI repository, it will automatically upgrade the “php-cli” to the latest PHP 5.4.34
Because of this (packages using the same naming convention as the official repos), the REMI repository is “disabled” by default so that you don't accidently “upgrade” a system software without realizing it.
You'll have to explicity 'enable' this repo if you want to install a particular software from this repo. The Remi repository also depends on the EPEL repository which is why we have to install the EPEL repo first.
Download and Install the REMI repository:
# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
# rpm -ivh remi-release-6.rpm
RPMFORGE: http://repoforge.org/use/
RPMFORGE is another popular softwaare repository trusted by many open-source enthusiast. It is now known as “RepoForge”, a project that maintains various RPM packages for Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux. It provides a set of repositories compatible with various RHEL-derived distributions.
Download & Install RepoForge:
# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm
If you're using a different CentOS distro, please visit http://repoforge.org/use and select the appropriate version for your server.
NOTE: Do not install it YET – because later, when we run the 'yum update' command to update the installed repositories, the default “AWStats” package will be replaced by the package in RepoForge repository which will cause the AWStats reporting to break. We'll address this issue later.
Now it's time to update the software repositories (EPEL & REMI)
Update the EPEL repository.
The command below will update the latest packages from the EPEL repository
# yum update
Type “y” and hit the enter key.
Install/Upgrade MySQL 5.5 and PHP 5.4
The command below (with the flag --enablerepo=remi) will activate the REMI repo and tells the yum package manager to install/upgrade the software from REMI:
# yum --enablerepo=remi upgrade mysql
*Note: the command above will also upgrade PHP 5.3 to PHP 5.4 because the yum utility will ensure all the interlinked software dependencies are met (e.g. one of which was the php-mysql which was linked to MySQL 5.1 – so when we upgrade MySQL to 5.5, the yum utility will also upgrade the corresponding “php-mysql” packages to PHP 5.40).
When prompted, type 'y' and press the enter key.
Note: The 4th column tells you which software repository the software package is being installed from. Once the software upgrade has been completed, run this command to update some of the essential tables in MySQL:
# mysql_upgrade
Install PHP-FPM
Now that all the system software is up to date, let's install PHP-FPM from the REMI repo
# yum --enablerepo=remi install php-fpm
This will create the directory: /etc/php-fpm.d/ with the default “www.conf” pool file. We will need to create a new 'pool template' called “www.bare” in this directory later.
Install 'mod_fastcgi' from RepoForge
Ok, now we will install the “RepoForge” repository so that we can install the “mod_fastcgi” package. This “mod_fastcgi” required for Apache to communicate with the PHP-FPM server.
# rpm -ivh rpmforge-release-0.5.3-1.el6.rf.i686.rpm
# yum install mod_fastcgi
The the command above will install a file called “fastcgi.conf” in the /etc/httpd/conf.d/ directory. Edit that file with your favorite editor and replace ALL the content in that file with just these 3 lines of code:
LoadModule fastcgi_module modules/mod_fastcgi.so
AddHandler php-fpm .php
Action php-fpm /php-fpm virtual
(note: the source code for the 3 lines above is found in the “fastcgi.conf” file)
Chapter 2: Virtualmin Configuration
Ok, now that all the necessary software has been updated and installed, let's login to Virtualmin now.
Note: if this is the first time you are logging into Virtualmin, it will prompt you to go through series of “Post Installation Steps” where it will fine-tune some of the server settings (e.g. optimizing the MySQL /etc/my.cnf for you based on the memory setting you choose and assigning a root password for MySQL).
Once the post-installation steps have been completed, proceed to Virtualmin's Configuration page. Click on the the Virtualmin menu, and click: “System Settings” > Virtualmin Configurations”
You will see the following:
The 2 important fields to note are the:
Command to run before making changes to a server. /root/updatehandler.sh
Command to run after making changes to a server. /root/phpfpm.sh
This is the “key” to making all the PHP-FPM automation work. Basically, this feature allows you to run custom scripts prior to making changes to a server (e.g. before a Virtual Server is created), as well as run another custom script AFTER making changes to a server (after Virtualmin has completed setting up a new virtual server).
This applies to “deleting” a virtual server as well. In the screenshot above, we have entered 2 scripts:
“updatehandler.sh” is a simple shell script to check if the default “php.conf' file exist in /etc/httpd/conf.d/ - and if it does, to rename it to 'php.conf.orig'. This is to prevent Apache from loading the “mod_php” module which takes priority over the “mod_fastcgi” - in other words, Apache will run PHP as “Apache 2.0 Handler” instead of talking to PHP-FPM.
“phpfpm.sh” is the main script that creates new PHP-FPM pool under the Virtual Server's ID and restart the PHP-FPM service in the background. It is also remove this PHP-FPM pool if the Virtual server is destroyed.
Chapter 3: Virtualmin “Server Template”
Now, let's create a new Server Template that includes the required Apache directives to communicate with the PHP-FPM service via the “mod_fastcgi” module.
In Virtualmin, click on the “System Settings” > Server Templates”
If you already have an existing custom Server Template, you can click on that template and then click on the “Clone it” button.
Give it the cloned template a new name, say “PHP-FPM”.
There are many options and settings that you can set in the Server Template, in our case, we are only interested in the “Apache Website” section.
Click the drop-down list (at the “Edit template section”) and select “Apache Website”
NOTE: The “FastCgiExternalServer ...” line should be just one long line, there is NO carriage return or the script will fail. You can download the custom script package that is provided with this book - The download link is at Chapter 10.
Further down on this same page, you will see this section:
Change it to “Apache mod_php (run as Apache's user)” (see the screenshot above)
This option does not add any additional FCGID directives to the “httpd.conf” file which may cause problem.
Chapter 4: Automation: Custom Scripts
In Chapter 2, we've setup Virtualmin to run 2 custom scripts – “updatehandler.sh” before creating the virtual server, and “phpfpm.sh” after the virtual server has been created. In this chapter, we'll take a closer look at these 2 shell scripts, plus a few other “helper” scripts.
You can download the scripts here: http://ilovevirtualmin.com/books-scripts/php-fpm
Download the “vserver.tgz” file and extract it in the /root directory. You will see the following files and directory:
updatehandler.sh
phpfpm.sh
createpool.sh
www.bare
fastcgi.conf
nginx/ ← this is a folder.
nginx.conf
proxy.inc
microcache.inc
virtualserver.com
nginx-proxy
createvhost.sh
Let's look at each of these custom scripts:
1. “updatehandler.sh”
Basically, this script checks if the /etc/httpd/conf.d/php.conf exist. If it does, then will rename it to “php.conf.orig” to prevent Apache from loading this module and running the PHP interpreter as 'mod_php'. This will enable 'mod_fastcgi' module to run and communicate with the PHP-FPM server.
It will also make a backup copy of all the files in the /etc/httpd/conf/ and /etc/httpd/conf.d/ to the “/root/config-bak/” for safe-keeping.
“phpfpm.sh”
This script makes use of the conditional statement “If the $VIRTUALSERVER_ACTION“ provided by Virtualmin. This is a cool feature in Virtualmin that allows one to create some really funky scripts by using the various conditional statements provided by Virtualmin. Here's the code listing:
This script (phpfpm.sh) uses the 'sed' command to create a new PHP-FPM pool under the Virtual Server's userID (account owner) in the /etc/php-fpm.d/ directory.
It uses the base pool template file (“www.bare”) and replaces ALL occurences of “www” with the “userID”.
You can also tweak the settings in the “www.bare” file to suit your server environment.
If If the $VIRTUALSERVER_ACTION test returns 'DELETE_DOMAIN' (i.e. the virtual server was deleted from Virtualmin, then this script will remove the PHP-FPM pool file and restart the PHP-FPM service to remove that user's process.
*NOTE: The additional “if” statement, i.e.
if [ -f /root/nginx-proxy ]; then
…CODE to create/delete Nginx vhosts…
fi
The conditional statement above checks if the file “nginx-proxy” (it's a blank/empty file) exist in the “/root” folder. By default, it doesn't, but resides in the “ngnix” folder instead. So, if you want to the script to automatically create the Nginx reverse-proxy vhost files, you need to copy the “nginx-proxy” file to /root
(OR you can just issue this command: # touch /root/nginx-proxy )
3. “www.bare”
This is the php-fpm pool template file that will be used by the '/root/phpfpm.sh' script. All occurences of 'www' will be replaced with the Virtual-server's userID.
You can tweak the variables, e.g. the “pm._*” to suit your server environment/resources.
4. “fastcgi.conf”
This is the custom (and much simpler) 3 liner which tells Apache to load the 'mod_fastcgi' module and create a new PHP handler (called “php-fpm”) to process all .php files. We wil use this file to replace the default “fastcgi.conf” that came with the 'mod_fastcgi' module.
Once all these custom scripts are in place, you're good to go. Create your Virtual Servers as you normally would, and Virtualmin will automatically setup the new virtual-server to run PHP-FPM under its own userID.
If you want to do more fancy stuff with automating the Virtual Server creattion, refer to this documentation: http://www.virtualmin.com/documentation/developer/prepost
It has a few sample scripts to get you started, and below are the list of variables which are useful:
List of Virtualmin's Environment Variables
Chapter 5: Setup PHP-FPM on existing Websites.
The earlier chapters assumes a brand new Virtualmin server that does not have any existing Virtual Servers (websites). This allowed us to configure Virtualmin to discard the other PHP Sapi and uses PHP-FPM only. If you have existing websites (Virtual Servers) in Virtualmin, we need to reconfigure the existing sites first – otherwise, those sites will stop working after PHP-FPM has been installed.
This chapter will guide you through the necessary steps to achieve this. I do strongly recommend that you do NOT do this on a Production server because the chances of breaking something is quite high, e.g. a small typo error can cause havoc. Test it out on a development server (VPS) first, and once you've the steps down pat, only then you can implement it on your live server.
Ok, with that out of the way, let's proceed!
Backup!
Needless to say, the first step is to backup ALL the existing Apache's configuration so that in case anything goes awry, you can restore them.
# cd /etc/httpd/
# mkdir -p /root/apache-config/
# cp -R conf/ conf.d/ /root/apache-config
The 3 commands above will copy all the existing configuration to the /root/ directory.
Once you've backed-up the configuration files, you can follow the steps outlined from Chapter 1 – 4 to setup PHP-FPM to work with Virtualmin.
BUT, do NOT create/modify/delete any virtual servers yet!
This is to prevent Virtualmin from triggering our custom scripts.
We need to make the following changes first:
Step 1. Modify /etc/httpd/conf/httpd.conf
After installing PHP-FPM , mod_php will no longer be loaded in Apache, and neither will “FCGId” - so we need to modify all the existing Virtualhost configured in the /etc/httpd/conf/httpd.conf to work with PHP-FPM instead.
Open the file with your favorite editor – find and delete ALL the following lines of code that beings with:
AddHandler fcgid-script .php
AddType application/x-httpd-php .php
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/pixms/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/pixms/fcgi-bin/php5.fcgi .php5
RemoveHandler .php
RemoveHandler .php5
IPCCommTimeout
FcgidMaxRequestLen
And ALL occurences of that starts with “php_”
For example, “php_admin_value engine Off”
After that, you need to append the following lines of code for EACH virtual host, e.g.
<IfModule mod_fastcgi.c>
Alias /php-fpm /home/USER/cgi-bin/php-fpm
FastCgiExternalServer /home/USER/cgi-bin/php-fpm -socket /home/USER/cgi-bin/USER.sock -pass-header Authorization -idle-timeout 100
</IfModule>
Replace “USER” with the actual UserID of that Virtual Server. You can find the 'USER' for each virtualhost by looking for the “DocumentRoot” line.
For example:
DocumentRoot /home/pixms/public_html
This tells you that the 'USER' in this case is 'pixms'
Step 2. Rename /etc/httpd/conf.d/php.conf
Rename 'php.conf' to php.conf.orig. This is to prevent Apache from loading the mod_php module.
# cd /etc/httpd/conf.d/
# mv php.conf php.conf.orig
Step 3. Create the individual PHP-FPM pools
Make sure the template pool file (www.bare) exist in /etc/php-fpm.d/
If not, then either create it (from the source code listing in Chapter 4 or copy it from the downloaded custom script package.
# cd /etc/php-fpm.d/
We are going to use the powerful 'sed' utility to do the heavy lifting for us.
The syntax is:
sed 's/www/USER/g' www.bare > USER.conf
where 'USER' is the virtual server account-owner ID.
For example, assuming the UserID for our virtual server is “pixms”, we would issue the following commmand:
# sed 's/www/pixms/g' www.bare > pixms.conf
Source code for: createpool.sh
(note: this scripts needs the template file, “www.bare” in the /etc/php-fpm.d directory)
Step 4: Final Check
Have you edited all the <VirtualHost> containers in the /etc/httpd/httpd.conf file?
Have you created a dedicated php-fpm pool file for each VirtualHost (VirtualServer)?
Once everything has been checked, you can start the PHP-FPM service:
# service php-fpm start
Before restarting the Apache server, issue this command to check that there are no errors in the /etc/httpd/conf/httpd.conf file:
# httpd -M
If there are errors in the config file (/etc/httpd/conf/httpd.conf), it will be displayed on the screen, e.g. if I missed removing one of the 'php_admin_' directive.
If there are no errors, you can safely restart Apache:
# service httpd restart
Chapter 6: Apache Handlers 101 / PHP-FPM
This is an “informational” chapter – to give you some theory and background about Apache Handlers and PHP-FPM. It is not required reading, but recommended so that you'll have a better understand of what is an Apache Handler and what is PHP-FPM?”
In the early (or was it late) 90s, a web-server can only process and display HTML and images. It cannot access databases, and it can do any of those fancy 'dynamic' stuff that we see today.
To overcome the problem, the programmers came up with “CGI” protocol – a way for web-servers to communicate with other 'programs' (or applications) written in some other programming language such as Perl, C/C++,
The developers of the Apache webserver then came up with the concept of “Handlers” - basically a module/method that tells Apache how to communicate with external programs (e.g. Perl script, PHP scripts, etc) when it encounters a specific file type.
For example, if a web-visitor requested for a *.cgi file, then an appropriate handler will instruc Apache to invoke the CGI script/parser to process that file. If the requested file is a *.php file, then the appropriate PHP handler will instruct Apache how to process the *.php file.
So, in a nutshell, that is what an Apache “Handler” is (in layman's terms) – it instructs Apache how to handle/process different file types.
For PHP files, there are essentially 3 different type of “Handlers”
Load and run the entire PHP engine (interpreter) within Apache itself. This is known as “mod_php” or “Apache 2.0 Handler”. This is the default method.
The “CGI” handler – Apache will invoke the /usr/bin/php-cgi script to process the PHP file and passes all the environment variables to the cgi program. The cgi program will process the requests and then pass the results back to Apache. Once that is done, the cgi process is killed.
The “Fast-CGI” handler – this is an enhancement to the CGI protocol where the “fast-cgi” process is not killed after it has completed its job. It can potentially “live forever” and is usually run as a daemon process alongside Apache. Also, the communication between Apache and the FastCGI application is via the IPC (Inter Process Communications) such as the Unix socket or TCP socket.
In the first case, i.e. “mod_php” - each instance of the child apache process has the entire PHP stack/engine within itself. This cause un-necessary bloat to the Apache processes because not every web requests are going to PHP scripts, some web requests are just requesting for images, css, javascripts. Hence, running “mod_php” causes in-efficient memory usage – and can be an issue if a heavy traffic website has lots of graphics.
Usually, 'mod_suexec' and 'mod_suPHP' will be used together with 'mod_php' to enable Apache to run the PHP scripts under the same userID as the Virtual Server to provide extra security and account isolation, i.e. the scripts in one virtual server cannot access the files on another virtual server.
The CGI handler is no longer used in modern applications because the action of spawning/killing CGI processes is very CPU intensive and inefficient.
The FastCGI handler is preferred. It allows PHP scripts to be executed by the PHP engine/parser outside of the Apache web server, i.e. each request is passed from the Apache web server to the FastCGI process via a communication socket (IPC).
The advantages of FastCGI is that the processes are 'persistent' - Multiple persistent processes can configured to run in the background to handle incoming PHP requests. This avoids the costly CPU intensive operation of spawning/terminating processes in the 'CGI' method.
So, where does PHP-FPM comes into the picture? PHP-FPM is actually “FastCGI” with its own built-in “Process Manager” (PM).
One thing to take note of is that most FastCGI applications/processes run in parallel in daemon (server) mode alongside Apache. These FastCGI applications are managed by a “PM” (Process Manager).
In Apache, when we used the “fastcgid” module (the default setting in Virtualmin), Apache uses its own built-in “PM” to manage the FastCGI processes.
But when we use the 'mod_fastcgi' module (installed from the RepoForge repository), Apache hands over the control of the “Process Manager” to the PHP-FPM engine which has its own “PM” - which is far more efficient.
By the way, the “FPM” stands for “FastCGI (F) Process (P) Manager(M)”
For more information about PHP-FPM, visit: http://php-fpm.org/about/
It has been noted that PHP-FPM can serve up millions of PHP requests without any issues. Of course, this would also depend on the hardware specifications.
Chapter 7: Setting up Nginx Reverse-Proxy
Virtualmin has built-in support for running “Nginx” as the primary Web-server instead of Apache. If you opt to run Nginx, then you will need to disable the Apache webserver in Virtualmin, as well as a number of other packages such as the Awstats package. At the time of this writing (Nov 2014), the Nginx support (as the primary web-server) in Virtualmin is not as robust or full-featured compared to the Apache web-server
The goal of this chapter is to run Nginx as the “reverse-proxy” to our Apache web-server, i.e. Nginx will serve all the static files & pages (all the image, css, and html files), while the PHP files will be served by Apache+PHP-FPM.
A Word about Performance before we begin.
Nginx's role as a reverse-proxy is to boost website performance by offloading some of the load from the Apache web-server. Personally, I've not been able to detect significant performance boost from using Nginx as a reverse-proxy – but most probably it is because my website doesn't have thousands of visitors a day.
Running Apache with PHP-FPM is sufficient for most people, but anyway, it is always good to be prepared … who knows, perhaps one day your website will be 'slashdotted' and you'll be glad that you have Nginx on your side.
The first step is to download and install the Nginx repository:
Go to http://nginx.org/en/linux_packages.html#stable
# wget http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
# rpm -ivh nginx-release*
# yum install nginx
Type “y” and press the 'enter' key.
This will install the latest Stable version of Nginx on your server. But take note that the default Nginx install above assumes that it will act as the “main webserver” and not as a “Reverse Proxy”.
In order to set it up to act as a reverse proxy, I've prepared the necessary configuration files. In Chapter 4, the extracted the custom script package (vserver.tgz) has a folder called “nginx” with the following files:
nginx.conf
proxy.inc
microcache.inc
virtualserver.com
createvhost.sh
nginx-proxy ← this is a blank/empty file
Copy all these files to the /etc/nginx/
# cd /root/nginx
# cp * /etc/nginx/
# mkdir -p /etc/nginx/vhosts
Note: You will need to overwrite the existing “nginx.conf”.
Copy the “nginx-proxy” (this is a blank/empty file) to the /root directory.
The script “phpfpm.sh” checks if this file (nginx-proxy) exist in /root – if yes, then it will proceed to create the necessary Nginx reverse proxy configuration (vhosts) files when you create a new Virtual Server from Virtualmin. Without this file (nginx-proxy), the “phpfpm.sh” script will NOT create the nginx vhost configuration file.
# cp nginx-proxy /root/
Now let's login to Virtualmin and make some adjustment the following settings:
Webmin > Servers > Apache Webserver
and click on the “Global Configuration” tab:
Now, as before, we need to create a new Server Template in Virtualmin to use port “8080” instead of port 80.
Virtualmin > System Settings > Server Templates
You can clone one of the existing templates (e.g. the one we had created earlier for creating PHP-FPM).
Select the “Apache website” from the “Edit template section” drop-down list as before.
We need to modify the “Default Settings” template and change the port to 8080 too!
Click on the “Virtualmin > System Settings > Server Templates” again.
And click on the “Default Settings” template.
Once you've done this, we're ready to create our first Nginx-Reverse-Proxy powered site.
VERY IMPORTANT NOTE: If you have existing websites (virtual servers) running on port 80 via Apache, do NOT restart Apache or Nginx OR create a new virtual server. If you do, then all your existing websites will fail to load.
You need to modify/update the Apache config file /etc/httpd/conf/httpd.conf and replace port 80 with “8080”, for example:
Original: <VirtualHost X.X.X.X:80>
Change to: <VirtualHost X.X.X.X:8080>
where X.X.X.X is the IP address of your own server.
Then, you need to create EACH of the nginx vhosts files for every existing website you have. In the /root/nginx/ directory, there is standard template vhost file - “virtualserver.com” which you can use a reference for the syntax.
We will use the provided script - “createvhost.sh” to create the required vhosts, i.e. you just need to run the script, enter the “userID” (account owner ID of this virtual server) and the domain name (e.g. pixms.com). It will prompt you for the server IP address if you did not define it in the script (replace “X.X.X.X” with your server IP and uncomment it)
Here's the source code of the “createvhost.sh” script.
IP_ADDRESS: The actual IP address of your server
NGINX: The domain-name (without the 'www'). E.g.: “ilovevirtualmin.com”
XUSER: The userID of for this virtual server (account-owner)
Chapter 8: Securing your Server (Bonus)
Server Security is huge topic, and it is simply not possible to cover everything in a chapter or even one whole book. In this chapter, we will just cover the 4 essential steps which I believe every server administrator should take to “lock down” the server - regardless of whether the server is running Virtualmin or any other control-panel.
These 4 steps are:
Run only the services required, stop all the other services
Secure /tmp
Install a Firewall
Install LMD (Linux Malware Detect)
Essential Services Only
Every service that we run on our server listens to a “port” - for example, the Apache webserver listens to port 80, SSH server listens at port 22, Mailserver at port 25, etc.
Think of these 'ports' as “doors” on a fortress wall – the more doors you have on the fortress wall, the more targets the 'hackers' would have to practise on.
To minimize this, we should shut down any services that we intend to use on our server. For example, if we don't intend to provide the mailing list service or the DAV login service to our users, then we should turn them off.
We can do this from the command line by using the 'chkconfig' command or from the Webmin's Bootup and Shutdown interface, i.e.
“Webmin > System > Bootup and Shutdown”
The default setup in Virtualmin is quite sane, but the following services can be safely turned-off as well:
xinetd
splash-manager
mailman (if you don't intend to provide mailing list service)
Securing /tmp
In most cases, the /tmp directory in a freshly installed/commissioned Linux server is NOT secured, i.e. it allows anyone (or script) to upload files to the /tmp directory and execute them.
Run this simple test to find out whether your /tmp/ directory has the executable bit set:
Create a simple 'hello world' Shell script in the /tmp directory:
#!/bin/bash
echo “hello world”
Then,chmod +x the script and try to run it.
# chmod 755 hello.sh
# ./hello.sh
If you see: “hello world” printed on the screen, then we need to fix it.
Repeat this for the /var/tmp directory as well.
To do this, we just need to edit the /etc/fstab file and add these 2 lines:
NOTE: The entries in your /etc/fstab may be different – depending on your Operating System and if your server is a VPS, your hosting company may provide a different “fstab” layout. If in doubt, please check with your hosting provider.
Once you've done with editing the /etc/fstab, you can either reboot your server or issue this command to remount all your partitions for this to take effect.
# mount -a
Note: The command above *should* causes all filesystems mentioned in /etc/fstab to be remounted, except the partitions with noauto option, but on certain VPSes, it may not work. Try running the 'hello.sh' file again to see if it runs. If yes, then best option is to reboot your VPS.
Installing Firewall
Although Virtualmin comes with its own interface to help you manage the “iptables” rules and chains, it can be quite cryptic and daunting, especially if you are new to it.
(The Virtualmin Firewall Interface can be found at: Webmin > Networking > Firewall)
An easier and more intuitive alternative is the CSF firewall from www.configserver.com
Login to your server via SSH and install csf firewall from the command line:
Look for this line (near the top of the file)
# lfd will not start while this is enabled
TESTING = "0" ← the default is “1”. Change it to “0” to enable CSF firewall.
Then, look for this section: “IPv4 Port Settings” and add port “10000” and “20000” to the “TCP_IN” and “TCP_OUT” line. See the underlined (in red) below.
# service csf start
Now, let's install the CSF plugin for Webmin:
Point your browser to: Webmin > Webmin Configuration > Webmin Modules
Select Install “From local file” - and enter this path into the field: /usr/local/csf/csfwebmin.tgz
Then, click “Install Module ” button. Once installed, you can access the CSF firewall interface from: Webmin > System > ConfigServer Security and Firewall
The first time you click on the link, you'll be prompted to update a symlink, i.e.
Click on the link provided and you will then see the CSF web-interface.
The first thing you should do is click on the “Check Server Security” button.
This will cause the CSF firewalll tu run a scan/security audit on your server setup. It will give you a summary of what needs to be “fixed” or changed to beef up the security of your VPS/server.
Then, follow the recommendation to further secure your server.
NOTE: You'd probably see CSF complained that both “portreserve” and “rpcbind” being enabled even t hough you have already issued the command:
# chkconfig rpcbind off && chkconfig portreserve off
And the Webmin > Bootup & Shutdown menu showed that they are not running either. The reason why CSF showed them as 'enabled' is because they are still enabled on run levels 2, 4, 5. To completely turn them off at ALL runlevels, run this command:
# chkconfig --level 2345 portreserve off
# chkconfig --level 2345 rpcbind off
Consider shutting down the following services as well:
# service xinetd stop && chkconfig --level 2345 off
# service saslauthd stop && chkconfig --level 2345 saslauthd off
Installing LMD
Linux Malware Detect (LMD) is a malware scanner for Linux. It is designed around the threats faced in shared hosted environments and released under the GNU GPLv2 license.
(LMD is also popularly known as “Maldet” - Malware Detect).
It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature and from malware community resources.
The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they are also easily exported to any number of detection tools such as ClamAV.
To download and install the latest version of LMD:
# maldet --update-ver
To update the latest malware database:
# maldet --update
Maldet Configuration File is located at: /usr/local/maldetect/conf.maldet
Edit this file and make the following changes:
You can leave the rest of the configuration at its default values. Sample Usage :
To scan a directory: the syntax is: maldet -a <path_to_directory>
For example:
# maldet -a /home/USERID/public_html
It will report the number of files it had scanned, as well as the number of 'hits' (if malware is found) and the number of malware cleaned (if any)
To view the report of the scan generated, type:
# maldet --report <SCAN_ID>
To restore a file that has been quarantined:
# maldet --restore /usr/local/maldetect/quarantine/<FILENAME>
Creating a daily cronjob to scan your files:
When you first installed LMD, the installation script will create a daily cronjob at /etc/cron.daily/maldet
The file paths for the following control-panels are supported/built-in:
Cpanel
Plesk (PSA)
Ensim
DirectAdmin
Default Apache DocRoot (/var/www/html)
The file paths setup in Virtualmin is similar to Cpanel – so you don't have to make any changes to the script.
NOTE: You may have noticed that maldet uses the question mark (?) instead of the usual asterix (*) to denote wildcard. For example, if you want to scan all the user-accounts under the /home/ directory, you would use:
# maldet -a /home/?/public_html
note: The “?” denotes the wildcard characteristics instead of the typical *
Comments
Post a Comment