QubesOS Options for Controlling Egress

2022-06-14
Reading Time: ~7 minute(s)

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.

Sure, you can run intrusion detection and capture network flows on your laptop. But the kinds of things network security attempts to prevent aren’t the risks that regular computer users have. Most of us don’t run services facing the Internet, we don’t take untrusted input from strangers (minus javascript), and don’t offer our modest home Internet connections as a service.

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:

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:

  1. 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 (8.8.8.8).
  2. 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.)
  3. 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
  4. Application - The web browser will then use the HTTP protocol over the established TLS connection request the initial resource requested (usually HTML). And the first resource will specify other resources to fetch to load the site (javascript, CSS, images, etc)

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 foobaz.google.com the 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.

Benefits:

Downsides:

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.


./danielwilcox.uk

Opinions expressed on this site are my own.