security

Docker, Arch Linux, and User Namespaces

Docker, Arch Linux, and User Namespaces

I recently tried to run Jess Frazelle's Chrome Docker image, she explains how to do that here. Whilst there is a little bit of understanding needed with what's going on (such as passing X11 through from the host to the container), it's pretty simple.

However, Chrome seemed to break for me every time. At first I couldn't work it out, but help in this Issue Thread showed that the lack of User Namespacing in my kernel was the problem.

The stock Arch Linux Kernel for some reason doesn't seem to have User Namespacing built in. Chrome needs this. The reason Chrome needs this is that the sandboxing security feature needs to utilise namespacing segregation to isolate web page processes. The idea being if they can't interact with anything outside the container, it minimises risk to the other processes on the system.

Unfortunately to enable User Namespacing, you have to enable the feature in a kernel config file and rebuild your Kernel. This isn't an easy process but the Arch Build System can help.

To test you've got User Namespacing enabled successfully, check zgrep CONFIG_USER_NS /proc/config.gz it should return CONFIG_USER_NS=y. Anything else means it is not enabled.

My config.gz for Kernel 4.2.5-1 is here

The image below shows I've got Chrome running in Docker fine now. You can also tell from Archey that I'm running the custom kernel.

Picture of Chrome Running

Utilising OpenVPN and a Firewall to create an Intranet with private services

This post will explain how I’ve effectively created an intranet using my Digital Ocean Droplet, OpenVPN, and UFW. I’ve assumed that you’re technically capable and already have a good understand of routing, firewalls, sockets, services etc.

The first thing you’ll of course need is a server – be it a VM, Raspberry Pi, or VPS. If you do go the VPS route I recommend checking out Digital Ocean.

OpenVPN

Once you’ve got the server you’ll need to setup and configure OpenVPN. I won’t explain how to do that as it’s a relatively long process, but the best guide is probably here on the Arch Wiki. However once you understand it, it’s easy to make configuration changes in the future. In the OpenVPN settings you’ll need to enable ‘client-to-client’ communication, specify ‘tun’ for a tunnel device type (as we want a routed IP tunnel) and at various places in the config specify the IP range you want to use. I used 10.8.0.0/16 as that is a private range and not externally routable (any gateway/border router should drop the packets). In addition I found that using TCP as opposed to UDP was a better choice for the VPN, my phone does do some random reconnects sometimes when packets get out of order, but I’ve found that when browsing the web YouTube and GIFs are far more reliable. You can switch OpenVPN to TCP by changing the proto udp directive to proto tcp.

Remember you’ll also need to setup IPv4 forwarding using NAT (explained in the guide linked above). Of all the steps, this is probably the most confusing even though once you understand what’s going on, it’s easy. Be patient.

UFW

Once you’ve got OpenVPN working and setup the way you like, the next thing to do is begin to tighten things down. Install Uncomplicated Firewall (UFW) and lock down everything except SSH and OpenVPN or you’ll lock yourself out (you’re probably using port 22 and 1194, both TCP). You can do this by setting UFW’s default policy to be ‘deny’ – this means you have to explicitly open ports. The best quick-reference guide I’ve found is here on the Ubuntu Community Page for UFW, for more advanced tweaking, take a look at Arch’s Wiki page for UFW.

All we need to do for now is have UFW online and running in the background, ready to restrict access to services later on…

Creating the ‘Intranet’ and configuring services

Now comes the part of locking down applications so that they are only accessible from our new Intranet – the intranet consists of OpenVPN clients and conveniently they will only ever be on the 10.8.0.0/16 range. This is the key to creating an Intranet, as we can configure services to allow authenticated OpenVPN clients, but ignore public users visiting our web server. I’ve done this in two layers for added protection. I use the firewall to stop randomers using the ports of my private services by restricting access to only the 10.8.0.0/16 range. The other layer is achieved by configuring the service itself to only offer its services on a 10.8.0.0/16 range. The reason for this dual-layer protection is if I incorrectly configure either the Firewall or the service, the firewall protects the service, or the service protects itself.

For example, let’s imagine that I am running an NTP server on it’s regular port 123/udp, but only want the OpenVPN clients to be able to use it. Remembering that the OpenVPN server should be 10.8.0.1, I configure UFW:

ufw allow from 10.8.0.0/16 to 10.8.0.1 port 123 proto udp

Then I add the other layer of protection in NTPd’s config file –

VPN Interfaces interface ignore wildcard interface listen 10.8.0.1 interface listen 127.0.0.1

Different services allow you to configure them to restrict communications from certain ranges in different ways, but there is almost always a way of doing it. For example sshd_config has this:

ListenAddress 10.8.0.1

Job Done – add more services!

Now you’ve got the framework in place for an intranet you can add additional services. For example I run a DNS server, this is so that I can view which websites my phone and tablet are contacting in the background when I’m not using them. There were  a few tracker sites, so I decided to use the DNS server to route sites like doubleclick.net to 127.0.0.1 and black-hole the traffic. It is important to note that if you want to use your own DNS server, you must change the DNS route push in OpenVPN to look similar to: *push “dhcp-option DNS 10.8.0.1”. *

The methods of locking the service down are the same as above – *create a firewall rule, and instruct the service to only accept connections from a specific IP range. *I run a deluge web manager on a specific port restrict access to that. You could run server-monitoring web pages like Zabbix, email access services, whatever you want.