So, building on what I did before with lights and switches as well as the stuff I’ve been hacking together with my Home.API, I thought I’d build something that may actually be of practical use. So, here’s a device that will tell you, before you walk out the door, whether all your doors and windows are shut, and for bonus points, tell you when they were opened and closed.

As you can see from the video, my local Homebase didn’t have all the bits, so you’ll have to use your imagination a little. The “Real” version would use simple magnet + reed switch burglar alarm fittings connected with bell wire to the terminals on your Piface. An indicator panel connected on the PiFace’s output panel should sit somewhere visible by your front door.

The software, again written in python, is very simple. It loops through all 8 input connectors and turns on or off the corresponding light when it reads a switch open and closed, when it detects a change it writes some output to the terminal and writes a message to the system auth log. This last feature is made even more useful if you configure the Raspberry pi to send its logs to a central server, as I have previously written about.

The next obvious thing to do is to interface this system with the Home API, which would be straight forward to implement (and I will implement when I get a moment!)

Here’s the circuit:

Click on the circuit to see a larger image…

securitysystem

…and here’s the code:

Enjoy!

6a0120a85dcdae970b016301e98de2970d-800wi One of the good things to come out of the recent revelations that the NSA have been doing what we always supposed that they might be doing, as well as our lot pushing ahead with ill conceived plans to do the same, is that it has made the public at large much more aware of the need to protect themselves online. It has also acted as a spur for many of us in the tech community to pick up our game a little, and to work to better protect ourselves and others online by redoubling our efforts to finally stamp out cleartext communication protocols.

The humble email, sent for the most part in the clear and readable to everyone, is one of the last legacy unencrypted technologies still in common use. These days HTTPS can be being switched on for just about everything, and it is considered the height of irresponsibility in the tech community to still use telnet or ftp.

Technologies for securing email have been around for decades, but haven’t seen widespread adoption. PGP is the canonical example, however s/mime, which does the same job and is often forgotten about, may be more practical for most people, for two main reasons: 1) most mail clients have native support, including native support in iOS, 2) it does a much better job at key exchange, in the most part handling it transparently (as long as you have the “sign email” option turned).

Setting it up is still far from a one click “make my email secure” button, but once set up it is transparent and easy to use, so there is very little reason not to do it if you’re reasonably tech savvy (or know someone who is who can help you). Even if you use one of the NSA’s free webmail services (gmail et al), providing you don’t use the webmail interface to read your email, you can still set this up.

What this won’t do

Even if your email is encrypted, there are a number of gotchas which you should be aware of…

  • It relies on both parties switching on encryption – this is an age old issue.
  • Subject lines are never encrypted.
  • The spooks and other ne’er do wellers can still see who you contacted and when, leaving you vulnerable to being caught by the inevitable guilt by association fallacy that such mass surveillance programs are guaranteed to produce.

Setting up S/MIME

  1. Obtain a signing certificate: Unlike PGP, which relies on self generated keys and a web of trust to establish authenticity, S/MIME relies on signed certificates in the same way as HTTPS does. These are in many cases free to obtain. I currently sign my emails with a Comodo certificate obtained via their handy online form.
  2. Collect your certificate: Next, you need to collect your certificate, this is done via your web browser, and is possibly the most confusing step. You must visit a link, and your browser will generate and install a certificate into itself. What this means is that once you’ve clicked on the link, you should get a message along the lines of “Certificate from xxxx installed”, but you won’t be able to directly use it in your email client. You must also use the same browser on the same computer throughout the whole signup and retrieval process, which caught me out.
  3. Export your certificate: In order to be able to use your new certificate to sign and encrypt email, you must first export it as a certificate file. From your browser, visit your advanced settings and export the certificate. In chrome, this is under Settings -> Advanced -> Manage certificates. Save it somewhere safe, give it a password you’re going to remember.
  4. Import the certificate into your mail client: Here’s how on thunderbird, OSX/ios, outlook.

If you’re tech savvy, this isn’t too painful a process, and once it’s done its done (at least until the certificate expires). If you’re not, then I think it is up to those who are to help. Stamping out unencrypted communication protocols can be considered a civic responsibility in tech circles.

Hand holding is a start, however I see absolutely no reason whatsoever that this process can’t be made into a nice click button wizard. For the most part, S/MIME is natively supported in all modern mail clients, so is it not high time that the setup process was made a good deal simpler? Why on earth is this not all done by the setup wizard?

As a community, lets make a pledge to make this better and to stamp out clear text communication protocols once and for all, making security an invisible process for everybody. What do you say?

Fail2Ban is a simple, but powerful, open source intrusion detection and prevention system which can run on most POSIX compliant operating systems. It works by monitoring various system logs for signs of intrusion attempts (failed logins etc), and on finding them, executes a preconfigured action.

Typically, this action is to block further access attempts from the remote host, using local firewall rules.

Out of the box, Fail2Ban comes configured to monitor SSH for signs of intrusion. However, since it works by monitoring log files, Fail2Ban can be configured to monitor many other services. I figured it would be pretty cool if you could also use it to protect Elgg sites as well.

Elgg already has a per user account lockout on login, however it is not without its limitations. It is pretty basic, and while it protects against access to specific accounts, it does not protect against dictionary attacks against multiple or non-existent accounts. Using Fail2Ban, you can protect against multiple access attempts from the same IP address easily, and the cut them off at the network level, frustrating the attack.

Installing Fail2Ban

The first step to getting this all working is to install Fail2Ban.

This is covered in detail elsewhere, but on Debian/Ubuntu it was a simple matter of pulling it from the apt repo:

sudo apt-get install fail2ban

Out of the box Fail2Ban will block using IPTables, but if you use shorewall, as I do, you’ll need to modify the actions to use that.

Getting Elgg to log access

It is an omission (quite possibly on my part), but the default Elgg login action does not explicitly log login attempts and login errors. While it is quite probable that you could hack together some regexp to parse the apache error logs, these are often quite noisy, highly changeable, often stored in odd locations, and, more often than not, are turned off in production environments.

I thought I’d make things a little easier on myself, and so I wrote a tiny Elgg plugin which overrides the default login action and outputs explicit error messages to the system auth.log, on both success and failure.

Once installed, you should begin to see logging messages start to appear in your server’s auth log (usually /var/log/auth.log) along the lines of this:

Mar 22 18:24:43 web elgg(web.example.com)[16483]: Authentication failure for fakeuser from 111.222.333.444
Mar 22 18:25:05 web elgg(web.example.com)[16483]: Accepted password for admin from 111.222.333.444

Again, to keep things simple, and to avoid getting a regular expression headache, I kept the authentication messages similar to those used by the SSH filter.

Monitoring the log with Fail2Ban

Finally, you need to configure fail2ban to look out for the Elgg messages in the auth.log.

  • Copy the elgg.conf into your fail2ban filters directory, on Debian this is in /etc/fail2ban/filters.d/
  • Create a jail.local in /etc/fail2ban/ if you have not already done so, and then create a rule, along the lines of the following:

    [elgg]
    enabled = true
    filter = elgg
    logpath = /var/log/auth.log
    port = all

Restart Fail2Ban, and you should be up and running! To test, attempt to log in (using a machine on a different machine if at all possible) and try a few failed logins.

A future enhancement of this that you could consider, especially if running in a production environment, is to modify the block action to redirect queries from the offender’s IP to a place-holder page explaining why they have been banned. This could probably be done quite easily using a REDIRECT rule, although I’ve not tried it yet.

Anyway, code, as always, is on github. Have a play!

» Visit the project on Github…