We have all done it at some point; a quick change in production to some settings in your CMS configuration, probably in a panic reacting to some ongoing issue, and made a temporary backup of wp-config.php or settings.php with a bak or similar extension. Tested the fix and then probably forgotten to remove the backup - no problem? Big problem! - Putting the issues of such bad practice aside for a moment (fixing production directly and 'reacting' in this way), in this post I want to explore in greater depth why this is a serious issue, how it leads to compromised web sites, who is exploiting such scenarios and how to defend against them.

I regularly encounter issues that arise from reviews of server security, log reviews etc that provide good examples of how Ansible can be used to respond to an issue.
If you are using a utility like Logwatch to keep an eye on activity on your servers you may occasionally see an entry such as 'Connection attempts using mod_proxy' - Addressing this with Ansible is simple, and maintains the state of your security measures.

This is a follow on post to the 'Using Apache to block Spammers' post.
It shows how to use Includes in your Apache configuration to re-use useful rules.

There are certain PHP files that you want access to but don't want to make public.
Common examples of these are:

• PHPInfo.php
• APC.php
• memcache.php

You also don't really want to deploy these on all of your sites on a server nor have them in your git repositories for sites.

A neat way of dealing with this is to use rewriting in your web server config files (e.g. Apache, NGINX, IIS etc) to do the following:

Last month I wrote a post about blocking spammers from a Drupal (or any Linux / Apache) site by identifying the originating IP address from the watchdog table.

By way of an update I thought I'd share a way you can do this using the Apache configuration. Ideally this would be done in the vHosts/Httpd files if you manage your own server but works equally well within the .htaccess files that most people have access to on shared hosting.

One of the housekeeping tasks that I undertake is to review the activity of comment spammers on our websites.
All of our Drupal sites use Mollom to keep us almost Spam free (big thumbs up to Mollom!)
But if you review the logs you can see that Mollom is protecting you from an alarming rate of attack and it would be good to not bother ourselves or Mollom with such traffic is possible. So the solution is to drop the traffic upstream of our web sites.
There are many ways of doing this from Firewalls to Drupal modules.

Basic Content authoring in Drupal

Each node in Drupal has an option to be 'Published' or 'Unpublished Published' under “Publishing Options” in the node edit screen. This enables content authors to be able to create content before publishing it on the live site. The field out of the "core" box can have the values of published and unpublished (this can be extended but that's a topic for another post).

If you are developing commerce sites and review your logs regularly, chances are you will come across 404 errors looking for crossdomain.xml. We get a lot from the plugins that looks for coupons on e-commerce sites (e.g. Drop Down Deals). In fact you are likely to get them on any sites you develop - but we have seen them more frequently on ecommerce sites.

We were engaged by the History of Parliament Trust to work on their flagship website that publishes the results of research into the members and constituencies of all British parliaments since 1386. This data rich web site is managed by the Drupal CMS and has tens of thousands of 'nodes'. We were tasked with solving various issues with the site's performance and importing data from the DTP files used to create the published volumes.

Whether you are running Drupal,Wordpress, Expression engine, Joomla or in fact any web site one of the regular tasks you should carryout on your web site is a bit of log analysis. It is often left up to modules, plug ins or someone else to protect your web site until it too late.
We all rely on Google Analytics to tell us about visitors and maybe use our log analysis software (AWStats, Webaliser etc) to report on log entries - but it is always worth using tools locally to dig deeper into your logs. These can range from simple reports on accesses to your site to more detailed forensic analysis of site activity.
By doing this we get to know better how visitors are accessing our site and can uncover some interesting answers to questions such as:

• How often is Google actually spidering my site?
• How many errors am I getting and what are they?
• Who is stealing my content?
• Is anyone trying to crack my site?

In this post I will briefly cover some useful techniques to analyse you logs and see if any one is abusing your hospitality.

When you first install Drupal it creates the master user (1) - this should ideally not be used to create content and it is good practice to create a new user for administrative purposes (not called admin but with an equivalent set of permissions) and an administrators group so that the super user doesn't get used - it may even be worth blocking the super user once you have done that. But be aware that some modules need to impersonate that user. If you want to restrict login for that user you can create an Access Rule to deny Admin for user name - this will effectively disallow logging in as Admin.

Issue: In a Drupal site a logged in user gets a 403 page (access denied) if they browse to the user/login page. Well? (I hear you ask) Why do you want to see the login page if you are logged in?? Good question - but it is not really an error or an access denial issue is it - it is more a 'user path/flow' issue. A good solution would be to see the user's own profile page.

It is easy to forget that the files in your web site are visible to anyone even if they are not linked to or are not files normally requested. In this post we look at how to use the.htaccess file to control access to your site.