When it comes to your security and privacy, it is always better to build your own. Like a chef cooking a meal. Good or bad, at least you know what you put in. Here’s our bittorrent recipe, deep-fried edition.

Ingredients

One browser… I guess you’ve seen this picture before. Only Downloads directory is real, and some miscellaneous configurations files.



The bittorrent client is similar: only Downloads . Make sure you save the files in this directory, otherwise you lose them when you close the client.

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!

But the big deal when talking bittorrent is the good old Domain Name Server (DNS). Here is a DNS trace left behind by a bittorrent client, information you cannot justify if they start asking questions. The fix is to encrypt the DNS traffic. We use our own DNS over HTTPS proxy server, available as a separate package.

Cooking Like a Pro

If you are a Debian/Ubuntu user, grab the latest Firejail Security Sandbox and Firejail DoH Proxy (FDNS) .deb archives from here and here. Arch and Fedora people already have the latest Firejail version available in the package manager, and FDNS is a simple ./configure && make && sudo make install .

$ sudo apt-get install firejail_xyz.deb

$ sudo apt-get install fdns_xyz.deb

Once everything is installed, start the proxy:

$ sudo fdns --daemonize

The proxy chooses a random server from a large list. All servers are non-censoring and non-logging, the vast majority non-corporate. Speed doesn’t seem to be an issue, but we do a very simple geolocation based on your computer’s timezone setting. We don’t send any packets to geolocation services. 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 DNS security. In FDNS we put in place a DNS firewall. It “understands” the DNS protocol and it can detect whether harmful traffic is being sneaked into your system. We also apply an adblock filter. Not only it reduces the DNS traffic, but it also eliminates a lot of trackers, malware, and bitcoin miners.

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:

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.

Note: iodine is mostly used to bypass captive portals in hotels, airports etc. Don’t run it behind FDNS, it will slow down your browsing considerably.

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.

And finally CNAME cloaking. Online advertising companies started using cloaking in order to trick web browsers into thinking they are serving first-party advertising instead of third-party. It could even track Tor users. It can be blocked at DNS level by a proxy such as FDNS, or by a real DNS server. In Firefox use uBlock Origin. Mozilla Firefox runs its own stub DNS resolver and exposes the info necessary to shut them down.

Bon appétit!