So, the other week I told you about the improvements to my access logging tool, which will now keep a user by user track of account activity.

This tool also makes a call to a GeoIP lookup hook, but until now remained unanswered. So, I wrote a quick tool that implements this GeoIP lookup hook using PHP’s built in geoip functions.

Once installed and configured (and the appropriate GeoIP database set up), this plugin will respond to any geoip/lookup event requests by looking up ['ip' => '....'] and returning the a country.

If installed along side LoginSyslog, you should start seeing the country listed along side the IP address!

» Visit the project on Github...

Just a quick one…. I noticed in my webserver logs, a whole bunch of directory walk “script kiddie” exploit attempts to various wordpress sites on my server, attempting to retrieve my wordpress configuration file: wp-config.php.

A directory walk attack is where someone will attempt to use a download feature of some plugin or other in attempt to trick it to retrieve a different file, by passing ../ before the file name. E.g.

None of these exploits was successful, since this is an obvious approach which should be sanitised out of inputs, but part of having a secure system is the concept of strength in depth and every programmer makes mistakes.

So, I knocked together a quick modsecurity rule:

Which seems to shut this one exploit down. HTH :)


On the Indiewebcamp wiki, there’s a page discussing HTTPS, the support for which is strongly recommended. As I’ve mentioned previously, at this stage all non-encrypted communication forms (including traditional port 80 HTTP) should be considered deprecated and dangerous.

Indieweb compatible sites are encouraged to get a higher level as possible, and thanks to some prodding, I’ve finally moved both this blog and my feed over to HTTPS only, with HSTS and forward secrecy.

This got me thinking, perhaps it would be worth adding a “Level 7″ (or perhaps Level 6.5) to this, and to suggest that Indieweb sites should also be made available as .onion hidden services on Tor?


  • Anonymity. Would go a large way towards protecting communication metadata (who know’s whom), which is a goal we should move towards in a world of endemic selector based surveillance.
  • Encryption. Traffic within the tor network is end to end encrypted, and there is some discussion of whether this renders HTTPS unnecessary.


  • Tor has nothing to do with HTTPS, although it is encrypted. However, the HTTPS levels page seemed a good place to put the suggestion.
  • Could be seen as endorsing one service. Tor is Free software and is pretty much the only game in town when it comes to anonymity networks, but does that constitute a silo? Probably not, but is a point for discussion.
  • No certificates for .onion. There are currently no certificate providers available for .onion domains. But, this may not be a problem.

Anyway, just mooting this as a point for discussion.