After installing ConfigServer Security and Firewall, many of us try to achieve as many ‘green’ results as possible. The often tricky one (or two) options to achieve, is mounting /tmp and /var/tmp as ‘separate’ file systems. On a bare metal linux installation (no virtualisation) this is easy to achieve by creating a file system (partition or pseudo file system) and mounting it accordingly. Under virtualisation (openvz, virtuozzo etc) this is not so easy, in fact, it’s not actually supported at all. However, there are two things you can try.

  1. Nothing. Just leave it. After all, the message at the bottom of the check security page says ‘This scoring does not necessarily reflect the security of your server or the relative merits of each check’ In other words, getting all green doesn’t necessarily mean your server is secure.
  2. You can set up pretend mount points (this works on bare metal installations as well). Delete the /var/tmp directory and symlink it to /tmp (ln -s /tmp /var/tmp). Next, edit your /etc/fstab file and all the following line: /tmp /tmp   ext3    defaults,usrquota,bind,noauto,noexec,nosuid        0 0 Finally, be sure to change the permissions to 1777 (chmod -R 1777).

The second option above doesn’t really achieve anything except the green ‘OK’ from CSF. Traditionally, the /tmp and /var/tmp directory have been located on a separate file system, due to the volatile nature of the files and content that are temporarily stored there. If the server was compromised via this directory, it could be easy to stop the compromise by un-mounting the file system. Better still, if the file system itself was hacked or damaged, it would only be the /tmp and /var/tmp that was damaged, both of which are easily replaced and can be deleted, removed and recreated all while the system is still running, not to mention that no important data is ever stored in these directories either.

Click Here if You are Looking for an official ‘CentOS’ repository to perform the upgrade, instead of a compatible repository.

Upgrading PHP (from 5.1 to 5.3 for example) on a variety of common RPM based linux distributions (CentOS/RHEL, Whitebox, Fedora, etc) can be a tricky process. After some searching and playing around, I come across a simple method which should meet the needs of most. There is a fantastic repository known as the IUS Community Project.

We are committed to providing up to date and regularly maintained RPM packages for the latest upstream versions of PHP, Python, MySQL and other common software specifically for Redhat Enterprise Linux and clones.

A Word of Warning: Do not attempt the following on a server that has cPanel/WHM installed on it. You will break your server! Use the Easy Apache Updater through the WHM interface or the Easy Apache Updater script: /scripts/easyapache on the command line, to upgrade your PHP version and features.

The following process should get you were you want to be.

  1. Download and Install the IUS repositories. You can start here: http://dl.iuscommunity.org/pub/ius/stable/Redhat/. Pick your release version and architecture (execute the command 'uname -a' (as root without the quotes) on the command line if you are unsure which you version you are using).
  2. Download the two repository packages. The first package will have a file name starting with epel-release (epel-release-1-1.ius.el5.noarch.rpm at the time of writing) and the second file will have a file name starting with ius-release (ius-release-1.0-6.ius.el5.noarch.rpm at the time of writing). On the command line, as root, you could execute the following commands: wget -c http://dl.iuscommunity.org/pub/ius/stable/Redhat/5.5/x86_64/epel-release-1-1.ius.el5.noarch.rpm to download the EPEL IUS repository installer for CentOS (and variants) on the 64bit platform  and wget -c http://dl.iuscommunity.org/pub/ius/stable/Redhat/5.5/x86_64/ius-release-1.0-6.ius.el5.noarch.rpm to download the IUS repository installer for CentOS (and variants) on the 64bit platform.
  3. Install the repositories, starting with the epel-release repository first: rpm -ivh epel-release-1-1.ius.el5.noarch.rpm and then rpm -ivh ius-release-1.0-6.ius.el5.noarch.rpm.
  4. Clear the system yum cache with this command: yum clean all
  5. Make sure the version want and related components are available: yum list php5*
  6. Remove any existing php and related components: yum remove php*
  7. Install the base php version you are after: yum install php52.x86_64
  8. Install any additional components or modules you may require: yum install php53u-eaccelerator.x86_64 php53u-ioncube-loader.x86_64 php53u-mbstring.x86_64 php53u-mcrypt.x86_64 php53u-mysql.x86_64 php53u-pdo.x86_64 php53u-xml.x86_64 php53u-xmlrpc.x86_64 php53u-gd.x86_64 and any others in the list that you want.
  9. Finished!

It is worth noting at this point, that both the IUS repository and the IUS EPEL repository are still enabled. Care should be taken in leaving them enabled, especially if you have yum automatically updating your software on a regular basis. If this is the case, or you don’t want to risk breaking your system with yum late one night, disable these repositories as follows:

  1. As root on the command line, navigate to the yum repositories directory: cd /etc/yum.repos.d/
  2. Edit epel.repo file and change the 'enabled=1' line to 'enabled=0' You could use ‘nano’ (yum install nano if you don’t have it): nano epel.repo change the line and press ctrl+o and then ctrl+x to save and exit
  3. Edit the ius.repo file and change the 'enabled=1' line to 'enabled=0' Again, you could use ‘nano’: nano ius.repo change the line and press ctrl+o and then ctrl+x to save and exit.
  4. Finally type: yum clean all
  5. Finished!

Leaving the IUS repositories enabled shouldn’t really cause you any problems. Then again, waking up one morning to find MySQL 5.0.x is now 5.1.x and everything on your server is now broken or not working, may be a good enough reason to disable them until needed, avoiding any accidental upgrades.

Official CentOS Repository for PHP

There isn’t one. But there is the testing repository. Edit your /etc/yum.repos.d/CentOS-Base.repo file or create a new /etc/yum.repos.d/CentOS-Testing.repo file with the following in it:

[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=0
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing

# CentOS-Testing:
# !!!! CAUTION !!!!
# This repository is a proving grounds for packages on their way to CentOSPlus and CentOS Extras.
# They may or may not replace core CentOS packages, and are not guaranteed to function properly.
# These packages build and install, but are waiting for feedback from testers as to
# functionality and stability. Packages in this repository will come and go during the
# development period, so it should not be left enabled or used on production systems without due
# consideration.

Be sure to change the value of the line ‘enabled=0’ to ‘enabled=1’ when you want to use the repository. Change it back to ‘0’ when you are finished, to avoid any accidental upgrades.

Feel free to post your comments and feedback. If you need a little extra help, please do let me know.

If your server has SUHOSIN installed/enabled, regardless of whether you have cPanel/WHM or not, this should work for you. Disabling PHP functions using the 'disable_functions' section of your php.ini file won’t really work too well if you using SUHOSIN. Instead, comment out the 'function_disable' line and add the following under neath it:

suhosin.executor.func.blacklist = "show_source,shell_exec,passthru,exec,popen,allow_url_fopen,system"

Of course your list of disabled features may not be the same as the example above, so be sure to add or delete the functions you want disabled or enabled from the list. Once you are done, restart apache and check your results with a phpinfo.php file. The following code inside a phpinfo.php file should do it:

<?php
phpinfo();
?>

Save the file and access it via your browser.

Search the page for the following value:

suhosin.executor.func.blacklist

The Local Value and Master Value should contain the following (as per the example in this case).

show_source,shell_exec,passthru,exec,popen,allow_url_fopen,system

Some plugins (cPanel or Other) may still complain that these functions are not disabled. You can rest assured, that they are disabled. In the case of wanting to simply please the software application (content management system etc) you can still add the entries as desired using the 'disable_functions' section of your php.ini file, although they won’t actually have any affect, as the values are overridden by the suhosin line. In some cases, apache may complain about both lines existing, in which case you may have to modify the software application to skip the check instead.

What about if I want to enable a feature for one particular domain?

If you want to enable or disable feature/s for one particular domain, a custom configuration can be set. On a standard server without cPanel/WHM, you would edit the vhost for the domain concerned. This may be the main /etc/httpd/conf/httpd.conf file or it may be an include file. This will depend on your servers configuration. The short of it is, you simply add the following line to the end of the vhost configuration for the particular domain:

php_admin_value suhosin.executor.func.blacklist 'show_source,popen,allow_url_fopen,system'

In the above example, I’ve allowed shell_exec and passthru by not specifying them in the blacklist. If you browse to your phpinfo.php file, you’ll notice the Local Value and Master Value are now different. The local value is the configuration on the domain concerned, the master value is the server wide global configuration. Note: you need to be visiting the phpinfo.php file via the domain or dedicated IP Address of the domain you are making the change for.

The process is exactly the same on servers with cPanel/WHM. The only difference is that editing the /etc/httpd/conf/httpd.conf is discouraged, as future re-compiles of apache and updates of cPanel/WHM can cause the changes to be lost. Instead, each vhost in the /etc/httpd/conf/httpd.conf file should have one or some of the following lines at the end of the vhost section:

Include "/usr/local/apache/conf/userdata/*.conf"
Include "/usr/local/apache/conf/userdata/*.owner-username"
Include "/usr/local/apache/conf/userdata/std/*.conf"
Include "/usr/local/apache/conf/userdata/std/*.owner-username"
Include "/usr/local/apache/conf/userdata/std/2/*.conf"
Include "/usr/local/apache/conf/userdata/std/2/*.owner-username"

Don’t worry if you don’t have all of the above lines, or they don’t look exactly the same. So long as you can see an include line to a directory, that is all you need. Go to that directory (in this example I’m using Include "/usr/local/apache/conf/userdata/std/*.conf" and create a file called domainname.conf or username.conf (so long as it ends in .conf). Edit the file and place the following line in it:

php_admin_value suhosin.executor.func.blacklist 'show_source,popen,allow_url_fopen,system'

Save your file and restart apache

/etc/httpd/init.d/httpd restart

Browse to your phpinfo.php file and compare the Local Value against the Master Value. They should be different!

If you have any feedback, troubles or would like some additional assistance, be sure to let me know in the comments.

I recently had the need to reset my Endian Firewall Admin ‘admin’ password via SSH/Console. I believe the reasoning for this was due to the following bug:

http://bugs.endian.it/bug_view_advanced_page.php?bug_id=1824

In case the bug does not apply to you, or you’re just too lazy to visit, here’s what you need to do.

1. Login via SSH or Locally at the console.

2. Type the following:
htpasswd -m /var/efw/auth/users admin

3. At the Password prompt, type in your new password, retype your password and you’re done!

4. Login to the Endian Firewall Web Administration with your new password

5. Fixed!

Why does this happen?

Well the short of it (from the bug report) is that resetting the password  with a password that contains the ‘$’ symbol or ‘%’ symbol, via the Web Administration interface, well it breaks 🙁 There is a solution to the problem on the page at the link above if you’re into hacking files and things 😉 It’s actually quite simple.