[qubes-users] detect tcp/ip connections of executables due to qubes firewall restrictions

Pete · May 6, 2021, 9:21pm

Hi!

Due to the current implementation/design of qubes firewall, it's hard to use domain names for firewall rules, because of "static" DNS resolution:

github.com/QubesOS/qubes-issues

Idea: dynamic firewall

opened 01:34AM - 08 Aug 19 UTC

Rudd-O

C: core P: default T: enhancement

The Qubes firewall is an amazing piece of technology integration. That said, it… happens to be the case that many services these days change how traffic is routed to them using DNS, rendering it almost impossible to block based on DNS. For example: I boot up a VM that will run an app, which connects to `mxs-services.whatsapp.net` on port 443. If I configure this on the Qubes firewall, it will work... for the next thirty minutes or so. Then the DNS response changes -- the app requeries the DNS records, it receives a completely different set of DNS responses (most likely in a very different subnet), the Qubes firewall begins replying to TCP SYNs with `ICMP admin prohibited`, and the app simply stops working correctly. Endgame. The alternatives are to continually add new netblocks to the firewall configuration as they are discovered by manual inspection using a `tcpdump` terminal, or to completely abrogate security and open the machine up to leaks by allowing any and all traffic to the destination ports (most services these days just use port 443). Here's what I would like to see: * A service (associated to a firewall VM setting, and defaulting to **off**) that snoops on outbound DNS requests and incoming DNS replies from AppVMs attached to the firewall VM it's running on. * This service maintains an up-to-date cache of (host name -> IP addresses) sets. * This service also communicates with the Qubes firewall running on the machine. * Whenever the cache for a host name known to the Qubes firewall changes, it asks for the Qubes firewall to reset its rules * Alternatively, more correct and less racy, but harder: the service alters the firewall configuration by (1) crawling it, (2) deduces the host names from the IPs listed on it and expired versions of its cache, then (3) generates a new firewall configuration with the new non-expired IPs substituting the old expired IPs (4) applies the firewall configuration. * The service runs properly hardened, dropping any and all privileges it does not need. * The service is written in a memory-safe language like Rust. This would immensely improve the user experience of the Qubes firewall compared to the current system. It also has potential uses in split-DNS scenarios where a corporate user may or may not be logged into a corporate network some of the time, so the firewall really does need to respond to changes in network configuration. ## Ideas for extension Once the basics are in place, it should be possible to make the DNS firewall behave interactively. Imagine an incremental improvement whereby an AppVM not currently authorized to connect to `host.name.org` attempts to first resolve the address, then receives the response (duly-cached by the service I'm proposing). Now, the service sends its first TCP SYN. In principle, the service can detect this and present an "Outbound connection attempt prompt" (how best to wire this interactive protocol into the Qubes qrexec framework is left unspecified here), and then the user of the machine can say "Yes / No / Yes, always", upon which the firewall makes the policy decision of ignoring further TCP SYNs or allowing the connection to be established by adding the necessary rules and letting the AppVM retry the TCP SYN. The AppVM would not know this has happened -- the only side effect is that the connection will take longer to be finished due to exponential backoff. ## Pitfalls I have not yet considered if the service should independently snoop each VIF to separate how it'd change firewall rules (seems more secure that way). It might end up being necessary anyway, since it's important for such a service to maintain a per-VM high watermark of in-flight (not yet deemed complete) DNS requests, else the service be DDoSable by a misbehaving VM. ## Project management This seems worthy of at least a bit of funding. I believe I can pony up some. We can negotiate based on the effort estimated to get here. (If any of this could be implemented as a Mirage unikernel instead, or possibly a Unikraft unikernel -- which means it's not gonna be limited to OCAML -- so that it became a substitute for the standard Linux firewall VM offering of Qubes, I'd be even *more* interested in this project.)

To find out the "connection wishes/tries" of an executable, what's the recommendation to use them for firewall rules?
1. Let's assume all network access except DNS is restricted from a AppVM. How can I find out which domains/IPs which executable is trying to use/connect to?
2. What are you're best practices to find out all IPs for a domain to white list them?

Best, P

mailinglist_bot · May 10, 2021, 6:57pm

liked2@gmx.de:

Hi!

Due to the current implementation/design of qubes firewall, it's hard to use domain names for firewall rules, because of "static" DNS resolution:
Idea: dynamic firewall · Issue #5225 · QubesOS/qubes-issues · GitHub

To find out the "connection wishes/tries" of an executable, what's the recommendation to use them for firewall rules?
1. Let's assume all network access except DNS is restricted from a AppVM. How can I find out which domains/IPs which executable is trying to use/connect to?
2. What are you're best practices to find out all IPs for a domain to white list them?

Best, P

1. netstat -pan, and/or tcpdump from somewhere networking isn't blocked. Might have to watch DNS requests to see what it's attempting to resolve. Don't know of a way to do it with networking disabled.
2. Check the vendor's documentation/KB.

slcoleman · May 11, 2021, 3:37pm

At one point in the past I was running Boinc and Thunderbird in network restricted AppVMs. The sys-firewall was set to the default deny mode so that I could prevent connections to anywhere except the specific servers I gave it permissions to. I had a python script that ran tcpdump in a pipe and read the output and then auto-generated the qubes firewall commands needed to open the firewall, but I manually chose which addtesses to actually allow.

When the firewall blocks a packet it sends a specific ICMP packet back to the AppVM containing the address/port that was blocked. I simply filtered for and read those packets from tcpdump and printed the appropriate ‘add’ command to stout in a terminal so I could then copy/paste that command to another terminal window to add the address/port once I investigated why the requesting program might have needed that connection. It would be trivial to add a gui with a click-to-add button.

This could likely be done on the internal interface in sys-firewall (untested) or in the AppVM (where you could also check which process was using that port number, e.g. netstat -pan) depending on the trust level in your AppVM. One could put this in a batch learning mode to collect all these commands during a test run and then add them to the sys-firewall permanently once verified.

As for performance, you only need to monitor it periodically if the app stops working, like when they shift to some other round-robbin server. You could easilly run it as a cron job at night to see what connections had been tried while you were not there. There is however limitations on the number of rules you can add so you might need to change individual addresses into network blocks once you start having those resource limiting issues. Thunderbird for instance tried to check for plug-ins at lots of different addresses.