Password storage can be a sensitive business, but no matter whether you're using PHPCredlocker or KeePassX, dedicated hardware is best. The more isolated your password storage solution, the less likely it is that unauthorised access can be obtained.
Of course, dedicated hardware can quickly become expensive. Whilst it might be ideal in terms of security, who can afford to Colo a server just to store their passwords? A VPS is a trade-off - anyone with access to the hypervisor could potentially grab your encryption keys from memory (or the back-end storage).
To try and reduce the cost, whilst maintaining the security ideal of having dedicated hardware, I set out to get PHPCredlocker running on a Raspberry Pi.
This documentation details how to build the system, a Raspberry Pi Model B+ was used, but the B should be fine too
One of the (minor) drawbacks of the Raspberry Pi is the lack of a hardware clock. Normally, you'd work around this by configuring a good pool of NTP servers to connect to. What do you do though, if you can't guarantee there will be an Internet connection available when needed?
The solution is obvious, so obvious that many have already done it - use the time provided by a cheap GPS dongle. The gpsd daemon helpfully pushes the time to Shared Memory Segments (SHM) so it's a simple adjustment to the NTP configuration file to have NTPD pull the time from the dongle.
Except, it seems on Raspbian, it isn't quite so simple. You've followed all the instructions (simple as they are) but are still seeing an entry like this
# ntpq -p
remote refid st t when poll reach delay offset jitter
SHM(0) .GPS. 0 l - 16 0 0.000 0.000 0.001
No matter what you try, reach stays at 0.
Frustrating, and there's very little to give you a guide. This post will tell you what the issue is, as well as how to go about finding it should it re-occur
Although changing the OS on a Raspberry Pi is quick and easy (especially if you have a spare SD card), there are times when you might want to test a system first, or simply tinker without needing a spare Pi.
This documentation details how to use Qemu to run a RaspberryPi image.
I used to run a nice pfSense box as my router, unfortunately power bills being what they are, I reverted back to using a BTHomeHub. Unfortunately, the BTHomeHub isn't particularly good - the Wifi signal sucks, it's DNS server seems to daydream and it occasionally forgets that it should be assigning some devices the same IP every time (or more precisely, will give their IP away if they are not currently present).
We could, of course, replace the HomeHub with something a bit more up market, but where's the fun in that? In this post, we'll be starting down the route of using a Raspberry Pi to usurp some of the power the BTHomeHub currently holds over the LAN. Eventually, the HH will be acting as nothing but a dumb internet gateway, doing a little bit of NAT and not much else.
In Part One, we configured our RaspberryPi to act as a Wireless access point and bridged the wireless and wired interfaces so that WLAN client's were easily accessible from the LAN.
As part of that setup, we configured a DHCP server, however we haven't yet made it the DHCP server for the LAN - our tired old BTHomeHub is still the authoritative server for the network.
In this part, we'll be reconfiguring our DHCP server so that it takes responsibility for the entire LAN, configuring DNS services, and making our Pi the LANs central NTP (Network Time Protocol) Server
Step by step, we'll be configuring our Raspberry Pi to take over nearly all of the duties performed by the BTHomeHub.
In Part One we configured a RaspberryPi to act as a Wireless Access point, providing DHCP services to wireless clients. In Part Two we then configured our Pi to provide DHCP, DNS and NTP services to the entire LAN.
In this part, we'll be taking some more responsibility away from the BTHomeHub, as well as configuring a few conveniences, such as Remote administration and useful utilities, including
- Wake On Lan
- Network Troubleshooting Tools
- Dynamic DNS Update Client (No-Ip.com)
Usurping the BTHomeHub with a Raspberry Pi: Part 4 - Using a VPN to Tunnel Connections to Specific IPs
Content Filtering is becoming increasingly popular amongst Politicians, ISPs and generally clueless do-gooders. The problem is, whatever you think of their motives, it's generally poorly implemented and interferes with the end-users browsing experience, even when it's not supposed to (the image to the right appeared with filtering off! - click to enlarge).
As we've been Usurping the BTHomeHub with a Raspberry Pi, we're going to take a brief break to implement some useful functionality that the HomeHub didn't provide.
In this Part, we're going to configure our Raspberry Pi to connect to an OpenVPN server and route some of our traffic over the tunnel - depending on the destination IP (i.e. Split tunnelling). This will allow us to easily bypass the troublesome content filtering, whilst not un-necessarily introducing any latency to any connection that is (for the time being at least) unaffected by the filters.
Note: We'll be manually specifying the connections that are routed via VPN, so that we can 'whitelist' mistakes such as the EFF and Wikipedia, whilst still being 'protected' against other filtered pages.
Unless otherwise stated, all commands need to be run as root
In Part 4 we configured our Raspberry Pi router to maintain a number of OpenVPN tunnels and to route through them selectively. Now we'll look at the steps needed to allow connection to our LAN via OpenVPN. Although helpful, as the HomeHub doesn't provide VPN connectivity, this stage doesn't really count as Usurping the BTHomeHub.
The steps are almost completely identical to those performed when Installing Open VPN on Debian. We're going to have to NAT connections though, as the HomeHub is a little stupid and we can't add static routes to it (so if we're connected to the VPN and accessing the Internet, it won't know where to route the response packets).
What we'll do, though, is only NAT if the connection isn't to something on the LAN.