WordPress Hosting

If you’re responsible for a WordPress site then you need to know how to keep it secure. You cannot afford to leave your product and investment unprotected. Most of these strategies will take you under two minutes to implement but can save you many hours of agonizing over how to clean up a mess created by the ravenous robots that roam the internet. You’ve heard the nightmarish stories of friends who have been hacked but you will never be among them if you take the time to implement a WordPress security strategy. Here’s a few quick strategies that will help you to make your WordPress installation less vulnerable.

Add a New User With Admin Permissions and Delete the Admin User

You may have heard this before but may not have taken the time to do it. This is the easiest and perhaps one of the most important adjustments you can make to boost your security. Don’t ever use “admin” for a username. All the robots who target WordPress know that it automatically generates the admin user and that most people are unlikely to change it. Create a new user first and make it an administrator. Select a username that is not easy to guess. Then use it to delete the admin user.

Allow Only Your IP Address to Access the wp-admin Directory

If you are the only person you want to have access to your blog and you don’t have any editors or contributors, considering denying access to every IP address except your own.  The wp-admin directory is vulnerable to attack, but this quick .htaccess trick will help you to protect it from security risks. Add the following code snippet to your .htaccess file. Replace the xx.xx.xx.xx with your static IP address. You can list multiple IP addresses by entering them on another line if you wish to allow access from other places.  

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Example Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
allow from xx.xx.xx.xx
</LIMIT>

Credit: Web Designer Ledger

Use SSH Instead of FTP

If you really want to cover your tracks and keep sniffers off your trail, use SSH to access your WordPress files instead of FTP. PuTTY is a free SSH client that you can use to transfer files between your machine and your server. SSH uses cryptographic technology to secure your session and will help keep you safe from traffic sniffers.

Get Regular Security Scans

This is essentially like a dental checkup for your WordPress blog to ensure that you don’t have any cavities. There are plugins that will take care of this for you. One is WP Security Scan. This plugin will scan your blog and notify you of any vulnerabilities and suggest things for you to do to make your blog more secure. It checks passwords, file permissions, database security, version hiding, WP admin protection/security, and removes WP generator meta tag from the core code of your blog.

Keep Your WordPress Version Updated

Chances are that your blog has not attracted the attention of a malicious hacker intent on destroying you. However, there are wicked armies of robots out there using any number of automated methods to try to exploit security holes in your installation. I know that upgrading can cause some tangles with plugins and is from time to time a huge pain, but it is necessary for your blog’s security, even if you’re not desiring new and updated features. Robots are very familiar with WordPress and know how to hack it, but if you keep your blog on the cutting edge you will generally be one step ahead of them.

Password Protect Your Most Important Directories

Enlist the help of AskApache Password Protection For WordPress. It adds multiple layers of security to your blog. The plugin is simple tot use. Simply choose a username and password and you are done. The plugin writes the .htaccess file without messing it up, encrypts your password and creates the .htpasswd file as well as setting the correct security-enhanced file permissions on both. Beyond keeping you safe from malicious attacks, it may even assist you in decreasing spam received on your blog.

Change Your WordPress Database Tables Prefix

This will help to protect you from SQL injections that can make your blog into a link farm. If this has ever happened to you, then you know it’s basically like getting heartworms. If you want to add an extra boost of protection when you install WordPress, make your table prefixes unique by editing wp-config.php file:

$table_prefix = 'wp_';

Change the ‘wp’ to something that is meaningful to you and this will automatically make your database more difficult to inject than 99% of all WordPress blogs.

Tweet This Post

You’ve installed CodeIgniter and you’ve written a couple of applications. Now, you want to run two of your applications under one install of CodeIgniter. The following article discusses how to run several applications within a single install of CodeIgniter. The approach is accomplished using an Apache’s Virtual Host.
Install Apache Virtual Host
1. To add a virtual [...]

If you are trying to restart an Apache server running on Ubuntu, Linux Mint or any other Ubuntu derived distro, you will get an warning message that your Apache server does not contain a fully qualified domain name.
Restarting Apache
# sudo /etc/init.d/apache2 restart
Warning Message
* Restarting web server apache2
apache2: Could not reliably determine the server’s [...]

This is a tutorial how to install a Subversion on your desktop. Subversion is an open-source revision control system. A repository is usually installed on servers so developers and programmers can have easy access to code. Subversion uses a check-in an check-out process for submitting changes to the repository. The repository can also be installed [...]

I think I just solved an issue with WordPress Permalinks and password protected directories that use Apache’s .htaccess. Here’s the problem in detail. I have WordPress installed on the root of my domain. Under that domain, I have a directory that I want password protected using .htaccess. It’s just a directory containing a few PHP [...]

If you host your own WordPress blog, it’s probably on Apache. That all fine and good. For most sites Apache works wonderfully, especially as it’s so easy to find information on it, on mod_rewrite and everything else that everyone else uses.

One of the alternatives is Nginx, a really fast webserver that streaks ahead of Apache in terms of performance, but isn’t quite as easy to use. That’s partly because Apache is the default webserver on most Linux distributions and hosts. Want to try Nginx? Here’s how.

Install Nginx. On Debian based systems that’s as easy as

aptitude install nginx

Nginx doesn’t talk PHP out of the box but one way to do it is via spawn-fcgi. Here’s where it gets complicated. (Docs summarised from here)

1. Install php5-cgi. Again, on Debian systems, that’s

   aptitude install php5-cgi

2. Edit /etc/nginx/sites-available/default and add the following chunk of code to the “server” section:

   location ~ \.php$ {
           include /etc/nginx/fastcgi_params;
           fastcgi_pass  127.0.0.1:9000;
           fastcgi_index index.php;
           fastcgi_param  SCRIPT_FILENAME  /var/www/nginx-default$fastcgi_script_name;
   }

3. Install lighttpd for the spawning command.

   apt-get install lighttpd

   You’ll probably get an error at the end of the install if Apache is already running on port 80. Edit /etc/lighttpd/lighttpd.conf and uncomment the line

   server.port = 80

   and change 80 to 81. Now run the apt-get command again and it will install.

   /etc/init.d/lighttpd stop

   will stop lighttpd running. (You don’t need it)

4. Create a new text file, /usr/bin/php-fastcgi with this:

   #!/bin/sh
   /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f /usr/bin/php5-cgi

   The user “nobody” should match the user Apache runs as to make things easier to transition.
   Make it executable with

   chmod 755 /usr/bin/php-fastcgi

5. Create another new file /etc/init.d/init-fastcgi and make it executable with the chmod command too. Put this in the file:

   #!/bin/bash
   PHP_SCRIPT=/usr/bin/php-fastcgi
   RETVAL=0
   case "$1" in
       start)
         $PHP_SCRIPT
         RETVAL=$?
     ;;
       stop)
         killall -9 php
         RETVAL=$?
     ;;
       restart)
         killall -9 php
         $PHP_SCRIPT
         RETVAL=$?
     ;;
       *)
         echo "Usage: php-fastcgi {start|stop|restart}"
         exit 1
     ;;
   esac
   exit $RETVAL

6. Start the PHP processes with

   /etc/init.d/init-fastcgi start

   and make sure it starts on every reboot with

   update-rc.d init-fastcgi defaults

That’s the PHP part of things. In Debian, the default root is “/var/www/nginx-default” so put an index.php in there to test things out. Stop Apache and start Nginx (if this is a test server only!) and visit your site. Works? Now to get WordPress and WP Super Cache working.

Open up /etc/nginx/sites-enabled/default in your editor and comment out the text already there with # characters. Paste the following in. Change paths and domains to suit your site. (via)

server {
        server_name  example.com www.example.com;
        listen   80;
        error_log   /www/logs/example.com-error.log;
        access_log  /www/logs/example.com-access.log;

        location ~ \.php$ {
                include /etc/nginx/fastcgi_params;
                fastcgi_pass  127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_param  SCRIPT_FILENAME  /www/example.com/htdocs$fastcgi_script_name;
        }

        location / {
               gzip  on;
               gzip_http_version 1.0;

               gzip_vary on;

               gzip_comp_level 3;

               gzip_proxied any;

               gzip_types text/plain text/html text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

               gzip_buffers 16 8k;
               root   /www/example.com/htdocs;
               index  index.php index.html index.htm;
# if the requested file exists, return it immediately
               if (-f $request_filename) {
                       break;
               }

               set $supercache_file '';
               set $supercache_uri $request_uri;

               if ($request_method = POST) {
                       set $supercache_uri '';
               }

# Using pretty permalinks, so bypass the cache for any query string
               if ($query_string) {
                       set $supercache_uri '';
               }

               if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
                       set $supercache_uri '';
               }

# if we haven't bypassed the cache, specify our supercache file
               if ($supercache_uri ~ ^(.+)$) {
                       set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
               }

# only rewrite to the supercache file if it actually exists
               if (-f $document_root$supercache_file) {
                       rewrite ^(.*)$ $supercache_file break;
               }

# all other requests go to Wordpress
               if (!-e $request_filename) {
                       rewrite . /index.php last;
               }
        }
}

I think the gzip settings above will compress cached files if necessary but Nginx can use the already gzipped Supercache files. The version of Debian I use doesn’t have gzip support compiled in, but if your system does, take a look at the gzip_static directive. Thanks sivel.

Now, stop Apache and start Nginx:

/etc/init.d/apache stop; /etc/init.d/nginx start

WP Super Cache will complain about mod_rewrite missing, and you should disable mobile support.

How has it worked out? I only switched on Friday. The server did do more traffic than normal, but I put that down to the floods in Cork. Weekend traffic was perfectly normal.

Load on the site is slightly higher, probably because my anti-bot mod_rewrite rules aren’t working now. Pingdom stats for the site haven’t changed drastically and I think the Minify plugin stopped working, must debug that this week. Switching web servers is a huge task. I disabled mobile support in Supercache because I need to translate those rules to Nginx ones. A little birdie told me that he’s going to be writing a blog post on this very subject soon. Here’s hoping he’ll put fingers to keys soon.

Have you switched to Nginx? How has your switch worked out for you?

Related Posts

• WP Super Cache 0.8.4, the garbage collector
• WP Super Cache 0.8.7
• WP Super Cache 0.9.5

When you install WPMU by default the subdomain option is checked. This is for blogs in the format of username.yourdomain.com.

There are two steps that need to be done to your server in order for this to work.

In Apache, there needs to be a line in the domain’s virtual hosts section as follows:

ServerName yourdomain.com
ServerAlias yourdomain.com *.yourdomain.com
DocumentRoot /your/doc/root/
ServerAdmin webmaster@yourdomain.com

The Server Alias line with the *.yourdomain.com is what controls this. If you do not have access to change this, ask your webhost for support. More and more hosts are enabling this by default.

The second thing that needs to be done is adding the DNS record. Where you add it depends on your domain hosting. Basically, you need to add a line like this:

*.yourdomain.com in A YOURIPADDRESS

These wildcards mean that any subdomain request will fall through to the WPMU install, where MU will look up the name in the database. If it finds it, it serves up the blog.

Note: if you choose the subfolder option on installation, you do not have to do either one of these steps.

• October 19, 2009 — WordCamp New York (1)
• October 17, 2009 — Make a tags page like WordPress dot com (7)
• September 24, 2009 — Changing the domain (5)
• August 19, 2009 — Getting member blog posts on the main page (12)
• August 13, 2009 — Another new release, and upcoming (6)

© andrea for WPMU Tutorials, 2009. |
Permalink |
No comment |
Add to
del.icio.us


Post tags: apache, dns, subdomain, wildcard, wordpressmu, wpmu

Need real genuine helpful support? MU Support.

Feed enhanced by Better Feed from Ozh

You can stop others from hotlinking on your site with the use of the .htaccess file in Apache. Hotlinking is when others are directly linking to an image or a file on your server. It’s bad because, they are using your server’s resources and bandwidth for free. You can edit your .htaccess file usually located [...]

If you own a website, there are times you need to bring your site down for maintenance or repair. Instead of the ugly 404 page not found, a nicely crafted maintenance page is ideal for your users to see. Enter .htaccess, a powerful Apache configuration file capable of many powerful functions. It can perform authorization [...]

I was asked in my previous post as to why I installed the popular Apache web server instead of lighttpd, a fast and highly optimized web server with a small footprint. If you need enough convincing, Youtube, Wikipedia and Meebo all use the lighttpd web server. Well, you asked for it — you’ll going to [...]

My development server is old. You’ll get a chuckle when you see the specs. It runs on a 400Mhz Pentium II CPU with a 128MB RAM and a 40GB drive. This old relic still manages to run Apache, MySQL, PHP and a local DNS. The server has also gone through 4 Ubuntu upgrades from version [...]