Firejail BitTorrent Sandboxing Guide

It is always better to build your own security and privacy perimeter. Like a chef preparing a meal, at least you are aware of what you are putting in. Here is our BitTorrent recipe, deep-fried edition.

Ingredients

The browser – I believe you’ve seen this picture before. Only Downloads folder is real, and some other configuration files.

Mozilla Firefox – sandboxed home directory

The bittorrent client – only Downloads. Make sure you save the files in this folder, or else they will disappear when you close the program.

Transmission-Qt – sandboxed home directory

Note: in general, network-facing applications in Firejail have a downloads-only home directory. We also make the home directory non-executable, and if AppArmor is running on your system we deploy our own profile and enforce it. The only rule is ALWAYS SAVE FILES IN DOWNLOADS!

However, the most important thing when talking about bittorrent, is the good old Domain Name Server. Here is a DNS trace left behind by a bittorrent client. You can’t explain this information if someone starts asking questions. The way to fix it is to encrypt the DNS traffic. We use our own DNS over HTTPS proxy server, available as a separate Firajail package.

DNS BitTorrent trace

 

Cooking Like a Pro

If you use Debian or Ubuntu, you can get the newest Firejail Security Sandbox and Firejail DoH Proxy (FDNS) .deb archives from here and here. Once everything is installed, start the proxy:

$ sudo fdns --daemonize

The proxy picks a random server from our large list. All servers are non-censoring and non-logging, the vast majority non-corporate. The speed doesn’t seem to be a problem, but we do a very simple geolocation based on your computer’s timezone setting. To track the DNS traffic, as a regular user run fdns --monitor.

Time to start the browser and the bittorrent client:

$ firejail --dns=127.1.1.1 firefox &
$ firejail --dns=127.1.1.1 transmission-qt &


Firejail allows each sandbox to have its own DNS configuration. In this case we use the loopback address 127.1.1.1 where FDNS listens by default. All the DNS traffic from the two independent sandboxes goes through the proxy. The proxy will encrypt it and hopefully will bypass the censorship going on ISP network.

 

Food Safety and Sanitation

Sandbox security has been described in various other places. I’ll talk instead about keeping your DNS safe. In FDNS we put in place a DNS firewall. It “understands” the DNS protocol and can tell if harmful traffic is being sent to your system. We also use a filter to stop ads. It reduces DNS traffic and gets rid of lot of trackers, malware, and bitcoin miners.

DNS ad traffic

Bootnet Command and Control. It is estimated 90% of malware uses DNS for C&C. Once installed, the malware issues a number of DNS queries to retrieve instructions from the central server. Most of them use DNS TXT or NULL records, although other records have been seen in the wild. In our DNS firewall we drop all DNS requests other than A (IPv4 address) and AAAA (IPv6 address). These records should be enough to run a regular Linux or Windows desktop, while cleaning up most bootnet C&C traffic.

This is a dns2tcp client (sudo apt-get install dns2tcp) trying to connect to a remote server using TXT records:

DNS malware Command&Control traffic

Note: No technology available today will stop a C&C channel based on A or AAAA records. Although the channel has a very low throughput, it is actively being used for DNS tunneling and data exfiltration by highly creative and sufficiently motivated individuals. Probably a lot of state actors too.

Speaking of tunneling, the picture below is an Iodine client (sudo apt-get install iodine) looking for the remote server using various DNS record types. It will finally connect using A records, all other records being dropped by FDNS.

iodine DNS tunneling utility

Note: iodine is mostly used to bypass captive portals in hotels, airports etc.

DNS rebinding attacks. We parse the incoming responses and look at the returned IP addresses. And we drop local network addresses, although this particular example could be a misconfigured DNS server.

DNS Rebinding attack

And finally CNAME cloaking. Online advertising companies started using cloaking in order to trick web browsers into thinking they are serving first-party advertising. It could even track Tor users. This can be blocked at DNS level by a proxy such as FDNS, or by a real DNS server.

CNAME cloaking used for tracking and advertising

Bon appetite!