WebHookWebmention, as well as the legacy Pingback, provide a way of notifying a third party site that you have made some reference to something on their site. So, for example if I reference somebody elses blogpost in mine, that blog will be notified and my reference may appear as a comment on the post (unless they’re blogging on a passive aggressive silo like Google+ or Facebook, or their blog uses Disqus, which is, in many ways I won’t go into now, the suck).

Pingbacks, and increasingly Webmention, are supported by most major web frameworks and blogging platforms, but adding them to a home rolled platform can be a little bit of a faff, especially if these platforms are build on static HTML.

So, inspired by Pingback.me written by Aaron Parecki, I wrote a bit of middleware that can be installed on a web server with minimal fuss, and can provide pingback/webmention services to other sites.

The reason I didn’t use Pingback.me was that I needed something quickly, I had reasons why I didn’t want to install an entire Ruby stack, and I needed the webhook functionality for a couple of projects (including some funky node.js dataset regeneration to tackle some scalability challenges, but that’s a different story).

Setup

One of the main requirements for pingback2hook was ease of setup, which I hope I’ve achieved.

  1. Start by checking out the source code from the github repo here, and place this on your web server.
  2. You’ll need to have PHP 5.3 running with mod-rewrite, and also CouchDB (to store pings), which on Debian systems, should be a fairly straightforward setup.

    apt-get install apache2 libapache2-mod-php5 couchdb; a2enmod rewrite

  3. If you’re running pingback2hook on its own subdomain, you should be up and running, but if you’re installing to a subdirectory of your site you’ll need to modify the RewriteBase in .htaccess.

Enabling pingback and webmentions on your site

Once you’ve got the software up and running somewhere, you can then start enabling pingback support in your sites. This is a two step process:

  1. On the pingback2hook server, define an endpoint for your site in a .ini file. This file will define the endpoint label, a secret key for communicating with the API, and zero or more webhook endpoints to ping. E.g.

    [mysite]
    secret = "flkjlskjefsliduji4es4iutsiud"

    ; Zero or more webhook endpoints
    webhooks[] = "http://updates.mysite.com"
    webhooks[] = "http://data.mysite.com"

  2. On your website, declare the necessary hooks in your metadata, either by headers:

    // Webmention
    header('Link: <http://pingback2hook.myserver.com/webmention/myendpoint/>; rel="http://webmention.org/"');

    // Pingback
    header('X-Pingback: http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc');

    And/or in the header metadata…

    <html>
        <head>
            <link href="http://pingback2hook.myserver.com/webmention/myendpoint/" rel="http://webmention.org/" />
            <link rel="pingback" href="http://pingback2hook.myserver.com/pingback/myendpoint/xmlrpc" />
    
            ...
    
        </head>
    
        ...
    
    </html>

Once set up, you will get an entry in the database for every pingback or webmention a given permalink receives. If you’ve defined some webhooks, these will be pinged in turn with the JSON content of the ping.

Viewing your pingbacks

To view your pingbacks you can either make a direct query of the couch database (default: pingback2hook), or make use of the API.

Currently, you can query the API via its endpoint at https://pingback2hook.myserver.com/api/myendpoint/command.format, passing any required parameters on the GET line.

At the time of writing only one command is supported, but I’ll add more as I have need to:

Command Parameters Details
latest.json|jsonp target_url, limit (optional), offset (optional) Retrieve the latest pings or webmentions for a given permalink url.

To make the query, you need to authenticate yourself. This is done very simply by passing the ‘secret’ for the endpoint in your request header as X-PINGBACK2HOOK-SECRET: mysecret. This is very basic security, and your code is being sent in the clear, so it goes without saying that you should ONLY make queries to the API via HTTPS!

Have a play, and let me know what you think!

» Visit the project on Github…

IFTTT (short for If This Then That) is a very powerful service that one can use to hook a number of different cloud services together in cool ways, and it’s a service I make a fair amount of use of.

Like many of us who make use of cloud services, the Snowden revelations, that the US and UK intelligence communities had hooks into all the major cloud services (or perhaps a better word would be “confirmations”, since many of us suspected this was going on for a while), have given me pause to re-evaluate the services I use and trust.

So then, what of IFTTT?

With all the hooks it has into other services, it does seem to represent the ultimate in back doors. Out of necessity of function, the permissions granted for each service are quite wide ranging, and we only have it on faith that they won’t be abused. Ok, so it’s not as bad as them knowing my password, since I can click a button and revoke access at any time, but until then IFTTT have full access.

As a US company, and through no fault of their own, IFTTT are compromised when it comes to security, since they’re all backdoored by the patriot act. I suspect that if they haven’t been forced to share access to accounts, it’s only because they are still relatively small fish (when compared to the likes of Google) and are only really used by the technical subset of internet users. But as they grow, it’s only a matter of time before they appear on someone’s radar.

In addition, their business model has always been a little bit of a head scratcher. I suspect the whole service came about from a “wouldn’t it be cool if…” kind of conversation, rather than a set agenda to make money (quite right too), but servers don’t pay for themselves, and I do wonder how long it will be before In-Q-Tel come calling.

Of course, it may be moot, since most of the services that IFTTT connects to are also US based, and for that matter, other countries are almost certainly forcing backdoors into their cloud services too.

Still, it’s got me pondering self hosted alternatives… any nice #indieweb projects out there?

exim-blue-ldFollowing on from last week’s w00tw00t block, here’s another quick fail2ban rule, this time to handle some Exim DOS/mail bombing problems.

I already use Fail2Ban to block unauthorised users who attempt to use my mail server as a relay to send spam, and this works very well. Recently, I’ve started seeing messages like this one start to appear in my exim logs:

2013-05-21 01:01:52 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:01:53 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:01:58 Connection from [2.38.90.63] refused: too many connections: 2 Time(s)
2013-05-21 01:01:59 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:02:00 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:02:11 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)

In each case, the IP address originates from somewhere I’d not expect to receive email from, so it looks like some spammers are trying to mail bomb/DOS me.

In jail.local

[exim-dos]
enabled = true
filter = exim-dos
port = all
logpath = /var/log/exim*/mainlog
maxretry = 1
bantime = 3600

In filter.d/exim-dos.conf

# Fail2Ban Exim DOS configuration file.
# Checks for DOS/Flooding attempts.
#
# Author: Marcus Povey
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P[\w\-.^_]+)
# Values: TEXT
#
failregex = \[\] .*refused: too many connections

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =

Some potential gotchas

You may notice that I’ve set the bantime to quite a low value, this is because this rule has the potential of some false positives or collateral damage in certain situations.

Most likely you’ll get the too many connections error when some naughty fellow starts mailbombing you, but sometimes connections will be refused for legitimate users while an attack is in progress, which would result in the good guys being banned as well as the bad.

Setting bantime to something relatively short (one hour in my example) should limit fallout, since legitimate email servers will retry later, while most script kiddies will have moved on.

» Visit the project on Github…