I’ve blogged about putting together a WireGuard server using OpenBSD a couple of years back. The main purpose of the server was to ensure a slightly more secure connection when I was on hotel WiFi. Of course thanks to the pandemic, I have barely travelled in the past couple of years so the server was mostly dormant. In fact, I kept VM turned off for most of the time. The VPN server was set up on OpenBSD 6.6, which was the last release that supported user mode WireGuard and didn’t have an in-kernel implementation. It was finally time to change that as part of an upgrade to OpenBSD 7.0.

In part 2, I reconfigured my WireGuard VPN to use an Unbound DNS server on the VPN server rather than rely on a third party server I had used for the original quick and dirty configuration. It was important for me to set up a validating DNS server, which I did in that part.

In this part, I’m extending the existing configuration to include some basic block lists for known ad and tracking servers. As I’m mainly trying to use the VPN while on the road, I want to ensure that anything I end up doing using the VPN is as secure as I can make it with reasonable effort. That makes tracking and preventing malicious ads the next step. That said, I’m not planning to go for a full Pi-Hole like setup. Initially, I am trying to do is integrate one known good blocklists into the Unbound configuration and automate the process. I can get fancy with a more Pi-Hole like setup later if I want to.

In the first part, I described how I set up the basic OpenBSD WireGuard VPN server. I also hinted that I wanted to set up my own validating, filtering DNS server. With a little bit of spare time during the holidays I decided now was a good time as any.

Making sure the VPN server uses the local Unbound DNS resolver first

Before I set up Unbound itself, I need to make sure that the VPN server’s resolv.conf points at its local DNS server first.

In my previous post, I mentioned that I somehow ended up with a corrupted filesystem on the WireGuard server I had set up earlier this year. That iteration of my VPN server was built on Linux as I expected I would get better performance using the kernel-based WireGuard implementation. It had taken me a while to set it up right, and I didn’t get the impression that the performance was so much better anyway. Keep in mind that I mostly use my VPN server from hotel WiFi and we all know how “good” that tends to be performance wise.

While I’ve done a fair bit of Linux admin work, I didn’t fancy re-doing the whole setup again. I also hadn’t scripted it up using Ansible or similar. I tend to prefer BSD anyway, and most of my personal servers run some flavour of BSD Unix. As I didn’t want to spend too much time securing this server, I used OpenBSD as it is a little more secure out of the box compared to FreeBSD. I also hadn’t experimented with OpenBSD for a while so I was curious to see the more recent improvements.

As an IT consultant, I travel a lot. I mean, a lot. Part of the pleasure is having to deal with day-to-day online life on open, potentially free-for-all hotel and conference WiFi. In other words, the type of networks you really want to do your online banking, ecommerce and other potentially sensitive operations on. After seeing one too many ads for VPN services on bad late night TV I finally decided I needed to do something about it. Ideally I intended to this on the cheap and learn something in the process. I also didn’t want to spend the whole weekend trying to set it up, which is how WireGuard entered the picture. I only really needed to protect my most sensitive device - my personal travel laptop.

As I’m already a customer at Vultr (affiliate link) I decided to just spin up another of their tiny instances and set it up as my WireGuard VPN server. Note that I’m not setting up a VPN service for the whole family, all my friends and some additional people, all I’m trying to do is secure some of my online communications a little bit more.

I also decided to document this experiment, both for my own reference and in the hope that it will be useful for someone else. Readers will need to have some experience setting up and administering Linux server. Come on in and follow along!

I recently blogged about Google and Samsung starting to offer regular security patches for their Android devices.

Over on ars technica, Ron Amadeo has an interesting article describing why the current Android ecosystem is not conducive to the quick and widespread distribution of security fixes and why this needs to change, urgently.

At this point in time it seems that in order to be halfway secure, one has to basically root the phone and run well-tested and well supported distribution like CyanogenMod. While I - and presumably most, if not all, readers of this blog - certainly have the technical know how and abilities to root a phone, that’s a poor approach to security because most people either will not or cannot root their phones.

Some security researchers from UCSD showed a proof of concept exploit via one of the dongles that appears to be also used by car insurance companies to monitor your driving “to give you discounts for good driving”. I’m not really a fully paid up subscriber of the tin foil hat brigade but stuff like this makes me glad that I’m still opting for the old-fashioned way of paying for car insurance. Of course the fact that over half our fleet is too old to be OBD-II compliant may have some bearing on that as well…

tl;dr - avast’s web shield functionality appears to insert itself into SSL connections using a self signed trusted root certificate and a simple kind of man-in-the middle “attack” on SSL. I would recommend you turn off web shield’s https scanning or choose another virus scanner.

I read about this on a blog post that was linked from Hacker News where someone claimed that Avast’s virus scanner for Mac OS inserts itself into SSL-encrypted connections using a self-signed certificate. A quick check on a Windows machine in my household confirmed that this was also true for Windows: