Hardening PHP through php.ini Configuration File.

If you have read my other post on hardening your LAMP stack / Plesk VPS, then you will know that by default most LAMP installs are not very secure by default.

Many of the default settings leave your system vulnerable and open to exploitation. Usually it starts with the system revealing too much information to potential hackers. The first step is always to reveal the least amount of information about your setup and humanely possible. The next step is reducing your attack vectors by switching off features you do not need or use.

In this article, that is what we will be looking into, how to harden PHP through php.ini configuration file.

Locating php.ini Configuration File.

Firstly, we need to locate all our php.ini files as there can be many, from the default files (sometimes 2 [1 for the web server and 1 for the CLI though not always]) to the copies made for individual domains if you are running a VPS. Use the following to find your php.ini configuration files.

$ locate php.ini

If you don’t get anything or are missing some that you already knew of, you may want to update the locate database with this:

$ updatedb

Once we have our list, its time to start making some changes. I find it is best to ensure we only change 1 to 2 things at a time before we go ahead and restart the server to make sure we have not broken anything. This way it is much easier to know what was the cause if we have broken anything.

Editing ‘php.ini’.

You can use whatever text editor you like, i use ‘vi’ but feel free to use nano/pico or some graphical editor on the desktop if you prefer.

Prevent Information Disclosure.

Turn off error outputting in the browser that could potentially reveal sensitive aspects of your web apps code.

display_errors = off

Disable Globals.

Register globals is set to be removed from php soon, and should be off by default. However many LAMP/WAMP/MAMP stacks still ship with it turned on unfortunately (likely [hopefully] still a minority of stacks though). So don’t take the risk of leaving it on, check it is turned off.

register_globals = off

Leaving this on leaves a massive vulnerability in your setup, namely because regular variables in your code that match GET vars in the url string will start out with the value of the GET variable. This means hackers can put whatever content they like into any variable in your code that could cause an unexpected outcome that they may want to target. With register_globals on the GET vars will always overwrite the default assigned value, this is a serious vulnerability if not turned off.

Disable Remote File Includes.

Prevent a hacker who has found some part of your web app that they can use to execute a remote script from succeeding by disabling PHP from reading/executing remote scripts.

allow_url_fopen = off
allow_url_include = off

Restrict File Uploads.

You can prevent file uploads if you do not have any use for such a feature by using the following:

file_uploads = off

If on, hackers can rename a scripts file to appear as an image, then successfully upload the file and when using the url to access the file can run their script. This is very bad because now they can execute scripts they have uploaded to your server. You might want to consider applying some rules to Apache/PHP to prevent the execution of scripts in your upload directories as a safety precaution.

I would recommend setting a sensible maximum file size for uploads to say 2 megabytes max.

upload_max_filesize = 2M

You can also change your default temporary file upload directory:

upload_tmp_dir = /var/php_tmp

If you want to make sure that malicious hackers cannot abuse your upload facilities, then ensure that you prevent script execution in the directories where you are storing your uploads. This is in either your htaccess file or httpd.conf file (which is out of the bounds of what this article is about but i will give you the snippet you need never the less).

<Directory /var/www/vhosts/yourdomain.com/httpdocs/your_upload_dir/>
Options None
AllowOverride None
php_admin_flag engine off
order deny,allow
deny from all
</Directory>

Protect Sessions.

Protect your sessions from being hijacked or shared in links people post online or send to friends by enabling cookie httponly. It will also prevent Javascript from reading your cookies.

session.cookie_httponly = 1

Also add a referer check, like:

session.referer_check = codeconsortium.com

You might want to change your default session save path to somewhere hackers won’t find as easily. E.g:

session.save_path = /var/lib/php

Disable Unnecessary Functions.

PHP includes many functions they you will likely never need or use, however they could be very helpful to hackers, disabling them likely will not affect your site, but will help make the hackers job much more difficult.

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

Summary

Much of the work shown above is courtesy of MadIrish, though i have shortened the descriptions down and focused more on the configuration changes than their descriptions / implications. If you want more in-depth descriptions of what we have done here, you should check out MadIrish’s website.

Other changes i made was the prevention of executing scripts in upload directories.

Though this article reproduces most of the steps of what MadIrish has achieved, this is more for my own record keeping than anything else. Though i hope it benefits others as-well, credit for most of this goes to MadIrish, good luck!

Nikto Server Auditing and Resolving Issues.

If you are security conscious and want to find an easy way to determine what aspects of your server setup are presently vulnerable to known exploits; then you may want to try a server security auditor/scanner. There are lots of security scanning/auditing scripts and apps out there, including some websites that will audit your site and provide you with a free report.

Here we will look at the basic usage of Nikto 2 and some of the common issues that it points out, and how we can resolve them. This guide is targeted at users running a LAMP stack (Linux, Apache, MySQL and PHP). However, it may still apply to some other setups out there. Hopefully the information in this article will help get you started.

If you do not have Nikto already, you can download it here.

Usage is relatively simple, just type:

$ perl nikto.pl -h yourdomain.com

Or do a more comprehensive scan with:

$ perl nikto.pl -j yourdomain.com -C all

Here are some common results you will get and what some things to consider when remedying the issue.

+ Cookie PHPSESSID created without the httponly flag

+ Cookie __cfduid created without the httponly flag

The __cfduid cookie is set by CloudFlare, so you won’t see this if you do not use CloudFlare. Its nothing to be concerned about.

+ The anti-clickjacking X-Frame-Options header is not present.

How to set the X-Frame-Options Response Header. Just add this code snippet below to your /etc/httpd/conf/httpd.conf file. Don’t forget to restart the httpd server.

After setting this, and running another test, you might find you now get this:

+ Uncommon header ‘x-frame-options’ found, with contents: DENY

I am not sure why this is, my best guess is that nikto expects SAMEORIGIN instead of DENY. Either of which is fine though. Unless you know otherwise, i would just ignore this at this point.

+ Uncommon header ‘cf-cache-status’ found, with contents: MISS

This is CloudFlares cache for your sites assets. Make sure your servers clock time and your httpd.conf’s headers are set properly to ensure that the sites assets are not interpreted as being stale. You may need to login to CloudFlare, purge the cache and visit the site a few times to ensure the CloudFlare cache is up to date. Then this issue should be resolved.

+ Server leaks inodes via ETags, header found with file /n8YeaczG.pl, fields: 0x3c3 0x4bbd982a52140

Disable ETags from within your /etc/httpd/conf/httpd.conf by setting the following:

+ robots.txt retrieved but it does not contain any ‘disallow’ entries (which is odd).
+ “robots.txt” contains 7 entries which should be manually viewed.

If you have a robots.txt file, you may receive one of the 2 above messages, they are not that important. If it says you do not have any disallow entries, while it is not much of a security risk (unless you are exposing sensitive data in html files [which is ridiculous and you shouldn’t be doing that]) you should add some default disallow entries. The reason why this is, search engines will use this file to determine what pages on your site should be indexed and cached etc. By adding some disallow entries for pages that will present just forms or stuff that is useless to your users google and other search engines can focus on indexing the pages on your site that really count. This is important because since googles panda update, pages on your site that have a high html to content ratio are actually really bad for your sites page rank. So for SEO purposes, block form pages and pages with useless junk or high html/content ratios in your robots.txt file. This will mean the pages that google does index should have better content:html ratios that will improve your overall page rank.

How to write a robots file.

+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.

I get this despite using Apache on a Linux machine with no .net/asp or other MSFT technologies on board. I can only presume its a cautionary tale told for all scans. If you know otherwise, please let me know in the comments as i could not find anything related to this on a LAMP stack. If you are running IIS though, and have .net setup, check the link in the error message for some advice on how to disable the debugging setup.

+ No CGI Directories found (use ‘-C all’ to force check all possible dirs)

If you denied from all the traffic for the cgi directories then that is the most likely message. This is a good thing. However it is best to do as it says and use the ‘-C all’ option as a precaution. This might possibly be a little brutal on your server though as it scans every possible known location for cgi directories and other stuff no doubt. It will likely take a long time, though should you find any directories still open, you best make sure you have a directive to deny from all.

The cgi directories are not the only directories you will likely need to close up. Plesk for example has a number of directories left wide open. See my other post on hardening plesk for more information on how you can fix some of the remaining issues.

Hardening LAMP / Plesk VPS / DDoS Mitigation.

If you want to harden the security of your Plesk VPS, there are a couple of things you can do from disabling non-essential apache modules to reduce attack vectors and from adding/activating some apache modules that can help in the department of security. In this article i will share with you what i have found after a couple of days of research and give you some practical tips, apache modules to install/enable/disable and some 3rd party services i have found to be of use.

What we will cover:
1) Disclaimer.
2) DNS / Proxy services (like CloudFlare).
3) Installing mod_evasive.
4) Installing mod_security.
5) Adding a rule set to mod_security courtesy of OWASP.
6) Enabling/Disabling useful Apache Modules.
7) Plesk Firewall Changes.
8) Configuring ‘httpd.conf’.
9) Disabling Directory Browsing.
10) Prevent PHP exposing itself in HTTP Headers.
11) Further Reading.

Disclaimer.

I am not a security expert by any measure, and make no guarantees that any of this will work for you! Please test your setup on a test bed before deploying and backing up your server (scripts/assets/database/configs etc) should be standard practice as i cannot be held responsible for any damages caused.

Further more, i use yum on CentOS and will not translate these instructions for use on other platforms or other package managers. If you are using apt-get, rpm, dpkg or anything else you will need to go to the original sites; the links for which i have provided and find alternative install instructions there.

CloudFlare and CDN’s.

Where DDoS attacks are concerned, there are some things you can do to help mitigate the attack but overall your options will be severely limited on any VPS. VPS’s generally mean you are already sharing your hardware with several other virtual servers, which could scale in any quantity depending on your provider and their policies.

The more virtual machines running side by side with your own VPS on the same hardware the lesser chance of successfully mitigating a DDoS attack. This is due to the limitations of bandwidth from the switch to that hardware combined with how much traffic your site and the other VPS’s on the same hardware are using.

Further more, the switch itself could have already peaked its limit, meaning nothing you do on your server will help to mitigate the attack.

If that is the case, then you have 2 options:
1) Migrate your DNS to CloudFlare or any other DNS/proxy/CDN services out there (there are lots to choose from, though CloudFlare is one of the most up and coming out there).
2) Contact your VPS provider and enquire as to any DDoS protection they are using at the switch/router level and wether they have any additional more dedicated filters that can be used. If they do provide such a service though it will likely come at a premium. Some ISPs/hosting companies will allow you to use your own hardware if you own it to filter out such attacks though will still likely charge you to use it (for the electricity and rack-space being used). Even then, such filtering boxes can be fallible.

From my own experience so far, i highly recommend trying out CloudFlare

Also, once setup on CloudFlare, considering installing their apache module from the downloads section mod_cloudflare.

Note that using CloudFlare comes with some added advantages, being a CDN, scripts/css/images and so fourth are cached, and further more, additional features can be enabled for blocking scrapers and spambots. Lastly as a really nice addition are the statistics that CloudFlare provide for you on bandwidth, and hits/visitors etc.

Now moving on to some more important tricks we can use to help mitigate weaker attacks on our system such as single DoS scripts and content scrapers etc.

Apache Modules.

Before we go ahead and do anything here, i highly recommend you back up your entire system setup, including your site contents and database and keep a copy of the backup on your local machine. I cannot be held responsible for data loss because something went wrong, so please, just backup your stuff, ok?

For this we will want 2 apache modules, mod_evasive and mod_security.

Mod_evasive will attempt to monitor connections looking for excessive repeat requests to the same resources from the same source and block out what it deems to be either DoS, DDoS, content scrapers or some other brute force attack. You can read more about that here.

Mod_security will employ a number of tactics to cover a large range of security implications from brute force attacks, xss attacks and also work to patch exploits in the OS once discovered by the community prior to the release of updates from the software providers. This is a much more sophisticated module and the original site for the project can do its description much greater justice than i can, so you can read more about it here. Though i will provide you with an extract from the site:

Just as a note here, i am using Plesk 11, HTTPD 2.2 on a CentOS setup. You may wish to tweak the install steps according to your own setup. If you do not have/use yum, you may want to use apt-get instead which is fine.

Apache Module mod_evasive.

Some of the older install instructions use the wrong download link which is no longer active, i have provided the more up to date link in the instructions for you. You will also need wget, which if you do not have on your Plesk install i suggest you install.

That should be mod_evasive installed. It is best to ensure you have not broken anything so do a restart of the HTTP Daemon.

Apache Module mod_security.

Next up, in order to install Mod_Security we need to ensure we have the following dependencies:

I am using mod_security_2.6.7 (there was a 2.7.0 prelease candidate but i don’t recommend using pre-release candidates as they may have bugs etc and 2.6.7 is considered stable).

I am also using apxs, which if you do not have/use, you may want to consult the original install instructions.

Before we can use this however, we have to edit the httpd.conf file to ensure that it is including the libxml and lua libs, use your preferred text editor to add the following at the top of the list of LoadModule section labelled (Dynamic Shared Object (DSO) Support).

If the server fails to load the httpd server, then swap the commented out LoadFile lines with the uncommented ones.

As before, it is best to ensure you have not broken anything so do a restart of the HTTP Daemon.

Adding the OWASP Rule Set.

The Open Web Application Security Project (OWASP) is a set of predefined rules to harden your mod_security setup. According to OWASP, mod_security does not do a great deal on its own, while it will by default add some protection, it will need a decent rule set to really put this thing to task. Many of the rule sets are commercial and will cost you money, however OWASP provide a nice set of rules for free to harden any server.

You can check out the project on their homepage.

Installation was a little tricky as their docs seems slightly inconsistent and poorly explained a few things. However assuming you are running Plesk 11, i will run you through the necessary steps to get this setup easily.

One of the things in the official docs was that the install directories were all wrong, or at least wrong for Apache 2.2 on a Plesk 11 setup. If this does not work for you then go ahead and follow the original docs, otherwise give this a go.

The filename extracted from the tarball may be different depending on the build/revision from the git repository.

Also, in this next section, i tried the newer 2.2.6 configuration but it seemed incompatible with the current stable build of mod_security, i could not find very good documentation explaining all the necessary steps or the difference, but my guess is that 2.2.6 is meant for the new mod_security 2.7.0 pre-release. So i went with 2.2.5 which worked. Version 2.2.6 will give you issues! (namely the httpd won’t start due to misconfigurations).

In that last step not only do we need to rename the copy to remove the “.example”, but also to change “_setup” to “_config”, this is an issue as the docs only say to remove example, and cite a wrongly named file. Just an error in their docs which i am sure will be addressed at some point but don’t let that trip you up.

Next up we need to make some changes to the file, we need to change the deny option on secDefaultAction to pass, according to the doc, (which actually will cause an error).

What they meant to say was set it the following:

To look like:

Use whatever text editor you prefer. I used vi, but feel free to use nano or pico etc.

Next up, we want to set up all the symlinks, linking the rules we wish to use into the ‘activated_rules’ directory.

I have corrected the following again from the docs to match the directories that are being used for httpd configurations in Plesk 11, which were invalid in the original docs but thats fixed in the steps i have given you below:

Now, if we peak inside the activated_rules, what we should have is a list of symlinks:

If you have something similar to that, then you are good so far.

Next up we need to edit our httpd.conf file to include the rules. This is what i added, and i added mine below the ‘extendedStatus on’ section which is only a bit below the LoadModule section. I would recommend doing the same so that it follows after the loading of mod_security.

That should load all the symlinked rule files into mod_security, and thus you should be done. :)

Now to restart the httpd server once again and check that everything is ok.

Enabling/Disabling Apache Modules.

With a complex server that is exposing itself in so many ways to the outside world, the least number of modules you can have running will help in reducing possible attack vectors that can be exploited by malicious hackers. Plesk makes enabling and disabling apache_modules super easy so we should not need to fire up the CLI/SSH any further at this point. Log into your Plesk panel and go to the “Tools & Settings” tab. There click on ‘Apache Modules’ which should be under ‘General Settings’ group.

Please check carefully the function of each apache module before turning it off, although i do not need them myself, you may depending on what your doing with your server. I have gone and made it easy by grouping them into some useful groups to explain what they are roughly about, and also provided a link for each module so you can get the official story on what its about before you go ahead and turn it off.

Here are a list of modules you should turn ON:

So, the evasive20 and the security2 modules correspond to the modules we installed earlier, if they are not on already turn them on now!

If you are running Plesk and not something else like CPanel, you will still need to be running mod_perl and mod_python even if you do not use perl or python scripts yourself on your server Plesk depends on these scripting engines (sucks i know, would love to disable them both, i just don’t use them).

Here are some modules you should turn OFF:

Filtering and substitution modules you likely will never use. (each one refiltering the same content and with potentially multiple rules being applied to each. Madness!)

Modules for remote management of database, mostly using really peculiar and obscure methods not suitable for average Plesk VPS users.

Chances are you won’t be using LDAP.

Mostly things you won’t need or care about.

With regards to deflate, please bear in mind that firstly, most browsers will cache images, css and scripts, so deflating them is pointless. Secondly as for html output, use a decent framework with template optimisation and caching for your code. For example, in php there is the Symfony framework which automatically optimises your html (strips whitespace from your html [to some limited extent, but can be optimised further with some understanding of the template engine]). Also, minify your assets manually prior to upload or during the process of building a local cache for your sites assets, this will have the same affect as using deflate except it only need be done once, where as deflate does it every single request (not good for performance!). You get extra points for using CloudFlare which acts as a CDN and will cache all your assets for you.

Next up, if you are not using SHTML SSI, CGI scripts, Tomcat/Server side Java Applets, then disable all of the following:

These are mostly tracking and logging, from a security stand point that can be a good thing, however chances are most of these logs won’t ever be checked, and all bloat your servers load time. If you need them, just pick a few but don’t enable them all. Remember that CloudFlare will block some of the damage and also log a lot of the activity for you, further more mod_evasive and mod_security will also block quite a lot of varying attacks now. I would only be activating them if i have an issue that needs a closer look, otherwise its just more crud running in the background.

You likely won’t need rpaf, if you don’t know what it is, you likely do not need it, same for mod_aclr for nginx.

Chances are you can also disable most of the authn_ and authz_ modules, unless you have specific use cases for them. The same also applies to all the proxy modules.

By disabling most/all of the above not only do we reduce the number of attack vectors but actually save a lot of memory and your website will generally load much faster. Since making these changes i have noticed nearly more than half the load time on my site. Thats nearly twice as fast. (site being CodeConsortium).

Sometimes performance is a benefit when mitigating DDoS (depending on the level of the attack), where if your site is being reduced to a crawl, at least if the content is served a bit quicker and the assets are cached on some CDN, the site may still be usable (potentially).

There may be more modules you can disable, however it is your responsibility to work that out for yourself, see what you need and don’t need. Also try them out few at a time rather than doing all of them and then finding you broke something, much easier to eliminate the potential causes from the list if you only do a few or 1 at a time.

If you want to know what modules are loaded, try ‘$ httpd -M’ to list them.

Plesk Firewall Changes.

By default, plesk leaves quite a few services exposed that you probably won’t need access to from the outside, particularly when access is already being provided through an html interface via the Plesk Panel.

Change the following to “deny incoming from all” for the following at your own discretion:

  • MySQL Server (this can be administrated through PHPMyAdmin, no need to allow direct access to this).
  • PostGreSQL Server (same as above).
  • Tomcat Administrative Interface (if your not using java on the server that is, otherwise you *might* need it).
  • Samba (Just not likely to need it, FTP will do fine).
  • Ping Service

With regard to the ping service, i choose to deny all traffic for the simple reason that, if your using CloudFlare, then your servers original IP address should be hidden behind CloudFlare. However if some malicious hacker does find your IP address, they should not be able to view the website as the traffic did not originate from cloudflare (thanks to the mod_cloudflare) so there browser should not receive any html or valid responses. So the last thing we want to do is validate their suspicions that the IP they have uncovered is legit by returning a ping request. In-fact what we want is to tell any potential hackers the least amount of useful information we can get away with; without crippling our own network.

The other thing to remember is, some of the older attacks still use ping for DDoS, denying inbound ping requests will lighten the load on the server if an attacker should choose to use this method. That said, the switch, router and even servers NIC can still be overloaded if the packet size and quantity is very large, and while we cannot really stop inbound ping based DoS attacks, at least we are not wasting outbound traffic by responding to it.

Configuring ‘httpd.conf’.

We can add some more fine grain refinements to our httpd.conf file for a little bit extra security.

1) Set, ServerSignature to Off. This will reveal less info in the http headers about your server setup.
2) Set ServerTokens to Prod. Also works to reveal less info in the http headers.
3) Add Header unset X-Powered-By.
4) Limit request body.
5) Limit XML request body.
6) Lower the timeout to 45 seconds.

I recommend only setting 1 or 2 of these at a time and then testing them before changing more. You can do this incrementally by testing each config by running ‘httpd -t’ on the CLI.

If you have already setup your CloudFlare, or any other CDN for that matter, and are using some tool to monitor your HTTP Headers. Then you may notice that most of the resources still say X-Powered-By etc while the main page html does not. This is because you need to log into your CloudFlare/CDN and purge your cache after you have saved the above settings and restarted your HTTPD server. After restarting your server and purging your CDN cache, you will notice the X-Powered-By header strings disappear.

Disabling NMAP and SendFile, is more for the instability issues that can occur. Both are designed to allegedly improve performance of serving static content, however i did not notice any decrease in performance by disabling them. This is likely because my site is entirely dynamic with the exception of assets that are already being cached on the CDN. Therefor if you use a CDN and most of your site is dynamically generated via PHP, Ruby or likewise then just turn these both off as they won’t do much for improving performance but could reduce stability issues for your OS (which is good).

Setup a sensible default for public directories that apache has access to.

Any other instances for the setup of vhosts/alias and directories etc, use -Indexes to prevent browsing of directories everywhere.

Some default apache/Plesk installs will setup an alias to /icons/, make sure that you disable this by commenting out the alias line. You can also keep the remaining setup for this by once again negating the Indexes and lastly, change the last bit to ‘Deny from all’.

Do the same again for the CGI scripts directory.

Though i added the header unset directive for the X-Powered-By, the same does not work for MS-Authored-By header string, in order to remove this, comment out the LoadModule lines for:

  • #LoadModule dav_fs_module modules/mod_dav_fs.so
  • #LoadModule dav_module modules/mod_dav.so

Some of the above tricks were found here.

Disabling Directory Browsing.

Also, you can edit your vhost.conf so that the line for Options disables indexes and allows symlinks. By doing this symlinks being active means the OS treats symlinks like regularly directories and takes less time to by passing checks on wether the folder is a symlink or not and checking if the directory it points to exists or not. This way we don’t check if it exists before trying to follow it, so it speeds things up a little. Disabling indexes will turn off directory browsing, which just adds a little extra onto our security.

Prevent PHP exposing itself in HTTP Headers.

In your php.ini turn expose_php to Off.

Remember, you will likely have quite a few versions of php.ini all over your file system, you have the default one, then sometimes another default for the CLI (which can differ), also you may have one for the Plesk system, and again another for each individual vhost.

Here is a nice script to tell you which php.ini files are exposing your server.

Output should be something like:

If you have a very short list, or none at all, then you may need to update your locate database.

Summary.

These are the steps i have taken so far, though i am continuing the search to harden the Plesk / LAMP stack. As i find new techniques that are particularly profound i will follow up with more articles. If you have any suggestions, please leave a comment below or head over to the forum. Some of the links below in the further reading section cover topics i am yet to fully investigate, and i will write more articles about other new techniques soon.

Further Reading.

Some of the resources i found which you may find useful and may include more tricks you can use not covered here.

Official / Links for Best Practices (ordered by least paranoid security approach / simplest first):
Official Apache Security Documentation
Symantec – Securing Apache: Step-by-Step.
WPSecure Server Guide.
SANS Institute – Security Consensus Operational Readiness Evaluation.
NSA Guide on Securing your OS (features documentation for most OS’s).

An auditing checklist from DISA (supposedly they do audits for the US DoD [Department Of Defence]) here (its in a zip file).

Some other links you may find interesting:
TechRepublic
20 ways to Secure your Apache Configuration.
Mad Irish: Hardening PHP from php.ini.
How To: Harden and Secure Your Linux Server – ASL and Plesk.
DDOS Protection | Sysctl protection | DDoS Deflate.
GotRoot.
Developer.Mozilla The X-Frame-Options response header MDN.

Good luck.

Setting up LAMP and PHPUnit on CentOS for staging.

I needing to setup a staging environment that more or less emulates the platform of your deployment system, i needed to setup a LAMP stack with PHPUnit for testing on the target platform.

Using CentOS and help from my good friend Cordoval (you can check out his cutting edge blog at http://www.craftitonline.com) we setup using Apache, PHP and MySQL.

We used the yum package manager to get things up and running:

First we needed to setup php :

and mysql:

With that done, we needed to then setup PEAR:

Then i followed the guides found here: (http://ulaptech.blogspot.co.uk/2011/07/install-phpunit-in-rhel-centos-or.html)

I will copy the instructions but all credit goes to the link above:

1. Make sure that you’re PEAR is version 1.9.2 or above. 

2. Discover all channels required.

3. Install PHPUnit with all the dependencies

<–

optional, at the time of writing this is beta so I had to force install it

4. Done. Test PHPUNIT.

Deploying SF2 Projects on Plesk VPS.

Having recently setup the new codeconsortium.com website i thought i would share some of the steps i took to get things working as it was not all smooth sailing. First off i just to clarify the platform i am using, it is a linux setup utilising Plesk and a typical LAMP setup with that.

My project written in Symfony2 and all custom code (minus FOSUserBundle), did not get off to a great start on deployment, so for other people deploying their web apps on a VPS running plesk i will share the steps i took to get things working.

First you need to obviously create your account and you can do that under Plesk control panel, this is a relatively simple step and as we are more concerned about the more complex arena of what we need to do on the command line i shall leave the creating of the account under Plesk to the documentation that it ships with.

Once you have your account setup and you have your SSH credentials handy we can begin. Firstly, download the Symfony2 framework from their site preferably WIHOUT vendors, this will greatly reduce the transfer time of things if you are going to just FTP them onto your server, but you could use git to do this also.

If you don’t have git i suggest using yum to install git. You can do this with:

Once git is installed you can download SF2 that way, otherwise just FTP SF2 onto the server, preferably inside your httpdocs directory.

The next steps we need to take is to resolve some issues with the default setup of vhost.conf, which should be located in your domains conf/vhost.conf. Once you are in your domain dir (something like /var/www/vhosts/YOUR-DOMAIN.COM/) you should find the file which you can open with the vi editor like so:

Then we need to make some additions, which i shall explain after this snippet, you need to edit your vhost.conf file to look like this (codeconsortium.com is my own domain, substitute this with your own accordingly.):

A few notes on the above snippet now, firstly, the most common issue people have is with open_basedir, which has a tendency to create permission errors with scripts, usually resulting in a blank screen with no error output. The other issue we resolve is to allow scripts and resources to be accessible through symlinks (particularly useful for assets where it is more efficient to symlink your bundles assets than copy them, particularly when you update your bundles later on). Then the section after regarding AllowOverride etc, opens up some of the remaining permissions issues. The last part of this vhost.conf allows us to use thw web folder as our actual web root directory, thusly protecting the rest of your source code (particularly your configs containing database passwords etc) from outside snooping. Once this is done, just restart apache like so:

Now that your vhost.conf configuration is out of the way, you will need to upload your project to your symfony/src/ directory on your server. You can do this either through FTP or the SCP utility on the command line, its up to you. I personally prefer using Cyberduck FTP client because you can add all manner of file types to exclude, namely large revision control files such as .git files etc. Excluding such files can cut your upload time in half in some projects with very large repositories.

Once your project is uploaded successfully, we should run the vendors install script, which you can do via:

This will install all the vendors that you did not download from the SF2 website. It makes much more sense to use the power of your VPS’s large bandwidth to download vendors than to download them to your local work machine and then use what is usually a very poor upload bandwidth of your ISP to get it all onto the server.

Before we run the check.php utility we will want to set the proper permissions on both the cache and log directories, so from your symfony/app directory do the following:

This is necessary so that symfony can write to the cache and logs directories. Once that is done, we must now run the check utility from the command line also, this helps identify any issues with your setup which will likely be a few on there. To run this type:

Following the issues highlighted modify your php.ini accordingly, usually you will do this by opening it in vi, and your default php.ini is usually in /etc/php.ini but we don’t want to edit this one, we want to edit your local php.ini which will overwrite the default one. If you choose to edit the default one found in /etc/php.ini then any changes made will effect all users on that server, depending on your root level of access on your VPS you may not actually be able to edit this anyway.

To edit your local php.ini file using vi again, edit:

OR if you do not have root access it will just be

And make all the according changes as per the issues the check.php script mentioned. Then we restart apache again:

Just to be sure that we got everything right, we can test that our settings are the right ones being used by creating a little test script in our httpdocs/symfony/web directory, create a file called phpinfo.php and edit it to look like the following:

Once all of those issues are resolved, we now want to make sure that there are no funky ‘.htaccess’ files in your root dir that might interfere with your project, so cd into your domains httpdocs directory and locate the default .htaccess directory, and delete it, if you don’t find one in there then that is good also. DO NOT remove the .htaccess file found in symfony/web you need this.

Now go to your browser and under your domain run your script, e.g; www.your-domain.com/phpinfo.php. This should output a really nice looking page with all the configs of php. Check for all the appropriate settings and check all the php.ini includes you see on the page are correct. Hopefully the chosen php.ini should have its configs overwriting the default ones, if not see what php.ini file your setup is favouring and edit that accordingly.

Now we should go back to our symfony directory and setup our entities and database stuff. Go to your symfony/app/config directory and edit your parameters.ini file so that you have input all your database credentials. If you don’t have any database credentials then you need to go into your Plesk control panel and create a new database and get your login credentials from there.

To implement this you now need to run these 2 commands (the first one you will need to run for each bundles group namespace):

That should be your database setup now, now all you have to do is install your assets. As we enabled the FollowSymLinks setting under our vhost.conf this should be no problem, just run the command below:

Now that this is done, we should be ready to test our site out, check your domain to see if you can access your site.

Hopefully all is well and you don’t have any issues, but if you do, check your error log, which you can find in your domain’s statistics directory, statistics/logs/error_log if you do not have a statistics directory then check /var/log/httpd/error_log and see what issues are coming up there. The last occuring issues will be at the very bottom of the error log, so look their first.

Assuming all is well, we can now delete the phpinfo.php script (its not good to leave this around, it can be a security hazard to leak all of your setup info)

Also remove app_dev.php and config.php from your web directory as these are only needed for dev environments.

I would also recommend once everything is working and you have tested out everything on your site that you further edit your php.ini file in your local domain area so that you set the error reporting to:

but keep ‘log_errors = On‘ as you will want a log of anything that is breaking down if someone reports it then you can trace the log to duplicate the conditions hopefully under which the bug was generated, or at least point you in the right direction.

The last step is to setup some additional tools, namely php’s APC, which is really useful for optimising your sites php performance overall. Though installing APC is not required, it can dramatically improve performance and is recommended. You can read about that in my other blog article http://www.reecefowell.com/2012/01/17/installing-apc-on-plesk/

DateTime::__construct(): It is not safe to rely on the system’s timezone settings.

If your getting the above error, then you have a misconfiguration in your php.ini file, this is very easy to remedy. Firstly find out which php.ini file your setup is using, you can do this using phpinfo(), just echo that out on its own in a plain php test script, like so:

Then locate where it mentions what php.ini you are using (do a page search on the output), and then load that php.ini file up and look for the line that states:

‘date.timezone’

it may be commented out like this ;date.timezone. Once you find it, set it to your region and capitol, as i have here:

date.timezone = ‘Europe/London’
And ensure that the semicolon is not at the beginning of this line. Save the file then restart your web servers Apache/PHP and the following error you saw should go away.

Enjoy.

Installing APC on a server running Plesk

I needed to install APC on a Plesk VPS today, and thought i would share what i did. Following the guide in the blog below i made some additions for a few things that were missing.

Original Guide here.

I also happen to be running CentOS, version 6.

Following the same steps in the linked site, i will add the few that you need that were missed and hopefully this will help anyone else who had the same issues i did with this. (if your like me an impatient you can add -y for most of these to speed up the setup process, it just auto answer yes to any yes/no prompts [mostly do you want to download this? sort of things]).

SSH into your server, preferably with some kind of admin/root access, and then type in the following one at a time.

Now we need to install the following as some installations of CentOS don’t have this but you may require it to use some of the PECL extensions.

Now chances are being a web server your setup most likely won’t have a dev tool chain, so we need 2 more things before we install APC. We need a compiler and we need a makefile utility (make will do). But first you can check if you have them before going to the extent of downloading something you may not need, to check if you got them:

If any of the 2 above do not show any results and comes back with nothing then you do not have them and need to install them, if your missing just one then install the one your missing. You will need both of them for the next step, if it comes up with a directory then you have it installed. If not we will get them with:

Now we should be able to download and install APC (don’t use the -y option here):

Now we need to create the extensions configs, first we create the ini file we need:

Then edit the file in vi (i would recommend vi over nano/pico as they tend to glitch over ssh)

Now type this into the vi editor (you need to press ‘i’ before you can type):

So save this file press the escape key and then type :wq and press enter, which should save and quit vi. I choose to disable the cache by default because this setting will apply to all users of your server and it can be a pain if people don’t want it running, they can enable it for themselves in their own directories etc/apc.ini

Lastly we need to restart the http server.

G11946006052010_JPG_P

HP Pavilion dv6-3119sa Entertainment Notebook PC (XU644EA) Review

New laptop! YAY. So i decided i wanted a new machine to run linux on as its a bit tiresome running Linux in a VM, and on my Macbook Pro the EFI is often problematic for linux installs; that said there are work arounds but i preferred to avoid that grief and go for the simpler option. So i bought a new laptop for my Linux installs so i could take it out and share what i am working on with friends with anything *nix related.

I had planned in the future to learn a bit about hypervisors and how to effectively run and manage linux machines on a hypervisor and this is great for that. Now i can take it out and work with friends in person with it.

So for the review; i had looked around pretty hard to find a decent laptop that wouldn’t break the bank but that also had good hardware and a design that does not compromise. Which incidently is very difficult to find. Most laptops out there in my humble opinion are just ugly; though for those of us who prefer something with a bit more taste the HP Pavilion DV6-4119SA is a beautiful machine. If your a fan of Mac’s; much like myself, then you will love this machine for running Windows. The typical install of Windows it ships with (Windows 7) works great on the Core i5 processor in it, though like most new machines you will need to decrapify it (URL: http://www.pcdecrapifier.com/) to make it run at its best.

The streamline shape and slim profile along with its black chick keys and multi touch trackpad this machine is quite reminiscent of the aluminium Macbook’s. Of course this is discounting the fact that the case design is not a unibody design and it comes with a drive trey instead of slot loading optical drive. That said overall its a really nice machine, specially for windows users who desire a better looking machine that delivers results.

Things of note however are that you don’t get a recovery dvd as seems to be customary in so many modern PC manufacturers these days and that for running Linux you may encounter a few hick-ups.

I find the trackpad to be somewhat annoying in Linux distro’s, namely because HP decided to emulate the Macbook to the degree that the trackpad has only one click button under its surface which maps wether you have a right or left click on the basis of which side of the touchpad your finger is pressed on. This is very annoying on the typical Linux desktop environment because Synaptic’s don’t seem to offer any linux drivers or software to support this; or least not that i have found yet and so i am left without a right click option as a result because Linux considers clicking anywhere a left click even on the right hand portion of the trackpad.

Also in my experience thus far i find the Wireless to be sketchy but this may not be the fault of the machine or Linux. To clarify on this Windows 7 runs on Wifi just fine with no problems; setup was quick and pane-less and i was on the web in no time. In Linux however it has been a different story, Linux Mint 10 LXDE and XFCE seem to connect to the wireless router just fine, though Mint 10 KDE and Gnome seem to not want to connect at all and i have tried playing around with the settings but am yet to find the problem, it could be a configuration issue. Xubuntu is also facing similar problems. Kubuntu and Ubuntu are yet to be tested on this issue.

On the plus side however i consider the boot up of most Linux distro’s on this machine to be very fast.

In terms of price, i find ordering directly from HP to offer the best price on this laptop and was not able to find it cheaper elsewhere so i would recommend buying direct. I did do a froogle search and also checked amazon and ebuyer directly but they could not beat HP’s own price.

http://h40059.www4.hp.com/uk/homelaptops/product.php?id=XU644EA&experience=direct

In conclusion i highly recommend this laptop from my usage of it thus far, it has great design, works well, boots fast and looks great.