QubesOS Options for Controlling Egress
Most of the computer security you know isn’t made for real people. Firewalls, intrusion detection, port scanners, and the like are tools for businesses, not you and me.
Our risk profile is closer to that of the employee. Our risks are less about attackers coming in and more about data going out. And at the risk of oversimplifying this usually this means phishing. Phishing as an entrypoint to capture credentials, install malware, or ransomware.
The standard practices are all still worthwhile for a regular computer user. And just because they’re the standard doesn’t make them easy, but I’ll remind you for review:
- Separate passwords for every site (this means using a password manager, and “No” a Microsoft Word document on your desktop doesn’t count)
- Multi-factor authentication on every site that offers it (ideally not SMS)
- Up to date web browser and OS
Unfortunately reviewing the above list – these don’t do much against phishing. The story goes – you get a convincing email, click on a link, and put in your credentials (and sometimes a 2nd factor). And then you get an email demanding payment to get your account back. (or worse)
What you really need are compartments that are limited to pre-defined web sites. If you had that, the phishing email link wouldn’t have loaded and you’d have another chance to check the URL and realize it was suspicious.
To skip ahead and build a practical solution read my post Qubes Web Browser Proxies.
Context + Methods Considered
If we are to create different ‘compartments’ for web browsing where do we do it?
Here is the sequence of network operations that happen when you go to your banks’ website:
- DNS - Lookup the bank’s website in the domain name service (DNS) to get
an IP address. This request usually goes to your home router and onwards
to DNS servers run by your Internet service provider or straight to a DNS
resolver like Google Public DNS (
- TCP - The web browser will begin a TCP connection with the IP of the website – let’s simplify and assume this is HTTPS (due to pre-seed, HSTS, browser plugins, URL, etc.)
- TLS - The web browser will use a TLS library but with it’s own bundled certificate authorities to verify the claim that the bank’s website is who it claims to be
Option 0: Filtering using the Qubes Firewall
This is the built-in method given by Qubes and it looks like filtering by DNS but it is really filtering by IP addresses. You may allowlist DNS names in the Qubes firewall UI but they are resolved to IP addresses and put into the firewall rules. Your connections to the given DNS name will work so long as the IP address for a DNS name doesn’t change too frequently.
Unfortunately, all of the big websites are doing different kinds of load balancing
via DNS that makes this an unreasonable restriction. When your web browser
makes a DNS request for
foobaz.google.com it may get a different IP than when
the Qubes firewall rule was created. The result is that when your web browser
reaches out to the IP it reasonably thinks is
connection will be blocked.
I tried a work-around for Gmail by using Google’s published IP address ranges in the Qubes firewall. Unfortunately I found that Google, and likely others, who are big enough to publish their IP ranges are also big enough to host caches served directly from ISP networks, which are not in their public IP ranges. These cache sites cause connection failures that look the same as above but appear only from certain networks, since their purpose is to improve latency are based on where you are connecting from.
This method is more aptly named “Option 0: Filtering the Network”. Using it on the ‘wrong’ websites leads to an extremely unstable and frustrating Internet experience. I gave up on using the Qubes firewall to filter web traffic in 2016 and cannot recommend it for that purpose.
Option 1: Filtering using DNS
DNS based filtering is simple and powerful. You can easily make your entire home network route queries for advertising or malware domains into a black hole. But for making web browser compartments DNS filtering doesn’t work.
DNS filtering makes it easy to specify who you don’t want to talk to (denylist) but not the only sites you do want to talk to (allowlist). This is backwards for our purposes, we want to create compartments that block the entire Internet except a handful of sites. We need an allowlist, not a denylist, which we can’t make easily with DNS filtering.
Option 2: Filter during the TCP connection setup
Proxies are the standard in filtering Internet traffic of managed computers. They can be transparent or explicit to the users of them but the purpose is the same – to restrict and monitor network access.
By running a proxy in the VM providing network access to our web browsing VM we can restrict access to everything but our banking, or whatever, websites.
- Qubes firewall rules become very simple and don’t need to be changed (hardly ever)
- Restricted web browsing VMs are offline with no Internet access except via the proxy
- Enforcement of your web browsing policy is occurring in a different VM from the one running your web browser
- No random ‘black holes’ from mismatched DNS/IP rules
- You have to occasionally update the allowed domains for your bank as they change their website. This means using the ‘Developer Tools’ in your web browser to figure out what was blocked and selectively enable things until the site works again
- Requires running an extra Qubes VM for every set of filters you would like to apply. This means about 400MB of memory will be tied up for each proxy VM.
- If you use Chromium or Google Chrome, setting a proxy is annoying and requires modifying the shortcut to change the command-line. And this shortcut editting will have to happen at VM start-up or after every web browser package update
Option 3: Filter certificate authorities
I never tried this method but thought about it. The idea would be to remove all certificate authorities from your browser’s bundle that are not in a chain to validate the websites used in a compartment (e.g. your bank’s).
Maintenance is a big problem for this method – determining which TLS connections you should trust, doctoring the CA bundle, fighting with the web browser over you doctoring the CA bundle. Plus, I don’t really want to know when my bank decides to change their certificate authority.
Another issue especially for the Qubes security model – the certificate authority bundle exists inside the web browser VM. If the web browser gets infected it can change the certificates it trusts and remove the filter altogether.
Option 4: Filter resources in the web browser
This it the domain of browser plugins like uBlock Origin, Privacy Badger, HTTPS Everywhere, and others.
I don’t think these are a great option to filter doing non-bank things in a bank web browser. However I highly recommend these for other VMs where web browsing is more open (versus compartments going to the same 5-10 websites repeatedly).
Setting up uBlock Origin aggresively will be a likely future post.
Opinions expressed on this site are my own.