I do a lot of web development these days, on number of projects, which often require their own domain, so I thought I’d share a quick tip that I’ve found helpful.

In a nutshell, I use wildcard domains and used the Apache vhost alias module in order to be able to automatically create a domain per project.

Setting up bind

The first step is to set up wildcard DNS for your machine, in this case *.dev.mymachine. Assuming you’ve got bind set up, this is just a matter of configuring a local zone for your network (or adding this to your existing local zone).

It’s late, and I’m tired, Google “wildcard dns bind” and that’ll point you in the right direction.

Setting up the vhost

Next, you need to set up an Apache vhost for your wildcard domain, but crucially, instead of specifying DocumentRoot in the normal way define VirtualDocumentRoot.

First, enable the module:


a2enmod vhost_alias

Then, set up and enable a definition which uses variables supplied by the vhost_alias, which will use the structure of the url line to load the appropriate web page.


<VirtualHost *>

ServerAdmin webmaster@myhost.com
ServerName myhost.com
ServerAlias *.myhost.com

# Indexes + Directory Root.
DirectoryIndex index.html index.php
VirtualDocumentRoot /home/%2/mycode/%1/

<Directory "/home/*/mycode/">
AllowOverride All
Options +Indexes +Includes +FollowSymlinks +ExecCGI
</Directory>

</VirtualHost>

The above code will use the directory name plus the user’s username, for example, fizzbuzz.marcus.myhost.com.

What this means is that you don’t need to create a new virtual host for each one of your projects, which may save you a little time.

For me, a handy bit of functionality I needed for my Idno powered personal lifestream site, is the ability to make posts via email.

Idno has a powerful mobile view, but sometimes even that is too bandwidth intensive, and quite often I like to be able to fire and forget; use the native apps on my phone or laptop that better handle disconnection.

So, I put together a quick plugin that allows you to make posts via email!

How it works

The plugin, once installed and configured, will let you generate a secret email address to which you send your email.

Out of the box the plugin will allow you to make status updates, long form posts (where the length of the subject and message body exceeds 140 characters), and even upload photos, and you can extend it further in your own plugins!

Installation

Installation requires you to have access to your own mail server (which if you’re a good indieweb / prism-breaking citizen you should be). You create an email alias that will pipe the email through a incoming email script, and then configure your email server to direct email to this handler for your domain.

The repository readme has some more detailed instruction (and of course there are many other techniques for firing email through the script).

» Visit the project on Github…

Mod_security is a plugin for the popular Apache web server that lets you block malicious traffic on your web applications based on rules you define. Essentially, it acts as a firewall for web apps, blocking suspicious traffic and malformed requests. It is highly configurable, and comes with a good set of default rules to get you started.

I had need to configure it for a particularly security sensitive client site recently, and while I was at it I thought it’d be cool to fire it up on my personal server. I installed the module, reloaded Apache and began watching the output of the audit log.

Holy Pingback spam Batman!

Pingback, is a way of notifying a site that you’ve written about them in your blog. The receiving blog then usually renders this out as a link in the comments section of the post, allowing visitors to read the expanded discussion.

Watching the mod_security audit log was an eye opener, because I found that my site was being hit by a metric shitload of bogus pingback requests (the order of a couple every minute), all from different sources. None of these messages had made it as far as appearing on my site of course, seemingly they have been blocked by something in WordPress itself (probably Akismet), so I honestly didn’t realise that this was a thing.

ModSecurity was flagging them up because the body of the message was malformed XML, so was kicking them out (legitimate wordpress to wordpress pings were being accepted, at least when I tested it), and closed the connection with a 400 response. In every case the request had similar signatures; it was chunk encoded, it was always linking to a real site (in most cases some poor schmo’s pwned wiki, which didn’t mention the post that was pinging), and the User-Agent was always “PHP/5.2.10”, so we’re clearly dealing with a script kiddy.

One thing I noticed was that, although I was getting pingback spam from multiple sources, each IP would retry every couple of minutes. This meant that my web server was having to spool up to handle each request, even if the spam did not make it through. Negligible in the grand scheme of things, but irritating nonetheless.

Since I am a firm believer in both a strength in depth approach to security, and I like quiet logs, I wrote a fail2ban script to catch these messages. As before, because I’m operating behind a reverse proxy I’m keying off the squid logs (until I can work out how to change mod_security’s log to spit out X-Forwarded-For anyway).

After a couple of hours, this is what my munin graph looked like:

Holy crap.