Posts Tagged ‘wordpress’

WordPress Suhosin Memory Limit

By Mark Davidson on February 27th, 2010

On my last post I was uploading some images to include in the post using WordPress. I noticed in my error logs that while resizing the images the PHP script attempts to raise the memory limit.

Feb 26 22:52:29 host suhosin[9636]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker 'XXX.XXX.XXX.XXX', file '/var/www/wordpress/wp-admin/includes/image.php', line 161)

This is fair enough and is a good idea for security and to stop your server getting overloaded by a single script. So I looked into how to fix this and its a very simple process.

You need to edit your suhosin config. I am doing this under Ubuntu 9.04 mine is located ‘/etc/php5/apache2/conf.d/suhosin.ini’. To fix it for WordPress just add the setting `suhosin.memory_limit` to the config file with the appropriate value in the case of WordPress it needs to be set to 256.

Your config should end up looking like this
suhosin.memory_limit = 256M

that is it really very simple. I am going to have a bit of a tweak with suhosin config later I think the default config can be improved a lot.

WordPress Auto Backup & Upgrade

By Mark Davidson on February 20th, 2010

As everyone I am sure knows to well upgrading wordpress can be a bit of a pain, so based on a couple of other scripts I found around the net I created this script for automatically backing up and then upgrading a wordpress install.

What it basically does is if you give it the full path of a wordpress install it will automatically reads the config file and get the DB details, then perform a backup of the db, then a backup of the wordpress files and then finally an upgrade of the wordpress install.

To run just use `bash wpUpgrader /var/www/wordpress/`

Download the Script Here

# Linux WordPress Upgrader Script
# Mark Davidson | [email protected] |

function wpExtract {
	echo $(grep -o "define('$1', '\([^']*\)');" $WP/wp-config.php | cut -f 2 -d ' ' | awk '{ print substr($0, 2, length($0) - 4) }')


if [ $# = "1" ]; then
	# need to either force full path input or create canconical version
	# Validate that this directory is valid and contains wordpress files 
	BACKUP_DIR=$PWD/backups/wp/$(date +%s)
	echo "Creating Backup Directory"
	mkdir -p $BACKUP_DIR
	echo "Backup Directroy Created " $BACKUP_DIR

	echo "Backing up wordpress database"
	result=`mysqldump -u $(wpExtract DB_USER) -p$(wpExtract DB_PASSWORD) --database $(wpExtract DB_NAME) 2>&1 > blog.sql` 
	if [ -n "$result" ]; then 
		echo $result
		echo "Taring DB Backup"
		result=`tar -cf db.tar.gz blog.sql 2>&1`
		if [ -n "$result" ]; then
			echo "DB backup could not tared be created exiting"
			echo "DB backup tared"
			rm blog.sql

			echo "Creating Backup of WordPress Files"
			tar -Pzcf blog.tar.gz $WP

			echo "Checking Backup Integrity"
			result=`tar -dPf blog.tar.gz $WP`
			if [ -n "$result" ]; then
				echo "Integrity check failed"
				echo $result
				echo "Downloading Latest WordPress"
				wget -O $TEMP/latest.tar.gz
				tar -zxf $TEMP/latest.tar.gz

				result=`tar -ztf $TEMP/latest.tar.gz | grep wordpress/index.php | wc -l` # Really basic chek that file is intact proberly a better way to do this
				if [ "$result" = 1 ]; then
					echo "File OK"

					echo "Extracting WordPress"
					result=`tar -C $TEMP -xf $TEMP/latest.tar.gz` #TODO: Validate extraction
					echo $result

					cd $WP
					result=`cp -avr $TEMP/wordpress/* .`

					echo $result

					rm -rf $TEMP/wordpress $TEMP/latest.tar.gz

					echo "New files copied vist to complete the upgrade"
					echo "File Corrupt or missing"
	echo "Incorrect Number of Arguments"

I based this script off a few others I suggested checking them out

Upgrade wordpress quickly in 3 easy steps from UNIX shell prompt
wordpress update script
WordPress Auto-Update Script For A Linux Server
WordPress Upgrade Script

WordPress & Apache mod_security: Part 01

By Mark Davidson on February 5th, 2010

After my initial post about wordpress and mod_security, I decided to have a bit more of a look around to find what rules other people had needed to disable to get it working.

I found a really good post over at – Mod security and wordpress the final config which had a few additional rules mentioned, but did not solve the problems I was having initially. So I thought I would draw on what they had posted and what I have learnt to produce a fully working list of rules that need to be disabled in order for WordPress 2.9.1 and mod_security Core Rules 2.0.3 to work together.

Below follows an example vhost file the important elements of it being the LocationMatch tags containing the SecRuleRemovedById.

<VirtualHost *:80>

    DocumentRoot /var/www/
    <Directory />
        Options +FollowSymLinks
        AllowOverride FileInfo

    <LocationMatch "/>
        SecRuleRemoveById 910006 # Google robot activity - Useful in someways but noisy for sites where you want them crawled
        SecRuleRemoveById 960015 # Request Missing an Accept Header -  Allow for Google Reader

    <LocationMatch "/wp-includes/">
        SecRuleRemoveById 960010 # Request content type is not allowed by policy - Allows for amongst other things spell check to work on admin area
        SecRuleRemoveById 960012 # Require Content-Length to be provided with every POST request - Same as above

    <LocationMatch "(/wp-admin/|/wp-login.php)">    
        SecRuleRemoveById 950005 # Remote File Access Attempt - This rule probably doesn't need to be disabled by everyone but it stops me putting /etc/ in posts and other such linux paths.
        SecRuleRemoveById 950117 # Remote File Inclusion Attack - Disable to allow http:// to be passed in args

    <LocationMatch "(/wp-admin/post.php|/wp-admin/options.php|/wp-admin/theme-editor.php|/wp-includes/)">
        SecRuleRemoveById 950006 # System Command Injection - Another rule that probably doesn't need to be disabled by everyone it stops .exe and various other extensions being passed in args.