MITM (Man in the middle?) as a service

This post was written by PI Technologist Ed Geraghty.

Another design decision we took early on when starting to build profiles for ThornSec was based on the fact that the majority of services people wish to use are browser-based (DAV, ownCloud, etherpad, etc).

NGOs are particularly vulnerable to attacks, and fixing the problem is even harder for them. Tech knowledge is expensive, not easy to find, and until recently was not considered in funding models. Defence and day-to-day management requires multi-disciplinary teams, which can increase costs exponentially.

In order to try to reduce load on our Virtual Machines, make our network config simpler, and implement some safety around all these web-based things, we build a reverse-proxy/load-balancer, which should be used between your router and the back-end service. The configuration of this proxy is pretty simple, and all network rules are done invisibly to the user.

Using a proxy in this way allows us to abstract several more difficult problems away from the back-end service. We use it to upgrade all requests to SSL, and as SSL termination — yes, this means that there is one machine which holds all of the cert private keys, but we don’t see any greater threat in this than pushing the certs out to all end points (and it also makes it easier to maintain). By DNATing all traffic at the router, we ensure that any traffic on ports {80,443} cannot go directly to the back-end server unless it’s originating from the proxy — and even then, it can only talk to it on port 80.

Given that all http traffic should be going through this proxy, which we use as our SSL terminator, at this point we can do caching, as well as SQLi/XSS/etc mitigations. Theoretically, this should give us protection against exploits against the back-ends themselves (basically, it’s a Web Application Firewall). It also allows us to simply and invisibly add SSL even to services which don’t support it out of the box, as all traffic which goes to the end service is done on port 80.

Given that our network is fully routed, by putting this proxy in this way, we stop the network really having to care about where the back-end “physically” resides. Whether it’s on the same HyperVisor or even the same network becomes moot to the end user.

Certification, Certification, Certification.

We are fully aware that offering DHCP leases based upon MAC addresses is far from ideal, stopping only the most casual intruders who have physical access to our network. By putting all web services behind a proxy of this nature, we are able to put stricter access controls and authentication in front of services which otherwise don’t offer it by using certificates. Having a central point means simplification of our network model, and having our own client certs allows us to have strict control over who can access what. The functionality of this is currently in the testing phase and should be pushed up to GitHub within the next month or two.

The only realistic way for this to work is getting your users to issue CSRs, and some organisations might balk at the idea of having to train their users. However, a religious decision we made around ThornSec was that we want our users to feel empowered by their network, and to understand they’re as much a part of the security as any other component. We want them to understand, even if just at a very basic level, how encryption and certificates work to keep them safe and that encryption is not just about securing the data, but also about ensuring provenance: that the services you’re using are what you think they are, and that you can prove to the server you are allowed to talk to it.

But this is also a protection mechanism for our users. Through being able to provision services such as ownCloud in a sustainable way, we are trying to get to the stage where little to nothing of any importance is actually stored on our users’ machines, at least not solely, nor necessarily. We can easily revoke certificates if a user has their laptop stolen, and this will immediately revoke any permissions that certificate had across any of our infrastructure. This is increasingly important in the age of BYOD.