Stop application(s) from connecting to internet

General Discussion
1

I have created a pihole based firewall qube named sys-pihole. I want to open a browser in that qube to access pihole web portal. Pretty much all browses make internet connection preemptively for valid reasons. But I don’t want the browser in the sys-pihole qube to make any internet connection.

How do I stop an application in a qube from connecting to internet?

1 Like
2

you could block all outgoing traffic of the sys-pihole qube to restrict to ports tcp 53 and udp 53, + DoH or DoT hosts if any

That way, your web browser will not be able to reach anything except the DNS servers.

There is no simple way I’m aware of to prevent a single program to use the network but localhost. Using a namespace, you can disable networking for a program, but you want to use firefox for checking pihole web-ui so it won’t work.

opensnitch could work but it’s quite heavy for the task

configuring a proxy in firefox to something that does not exists, and disable the proxy for reaching localhost (default setting) should work too, but it does not guarantee the web browser will not try networking without the proxy.

another solution would be to have a pihole-admin qube without network, that directly connect to pihole web interface using ConnectTCP qubes os RPC, but this is super heavy to setup (the first time). Although this design pattern is useful and can be reused many time if you have similar needs.

2 Likes
3

This is the only reliable solution to make sure the browser cannot access the internet the qubes way, using different domains. Note that if the server is vulnerable, it can be attacked by the browser qube to access the internet.

Here is the file contents you need to set it up. Check the .sls files on where they should go if you don’t want to use Salt.

Pi-hole qube:

Browser qube:

2 Likes
4

If the web browser in sys-pihole is Firefox (ESR), you can prevent it from making Internet connections by using a Firefox profile that works offline:

firefox -p

This command will open the Firefox profile prompt. From here, you can select any Firefox profile, then select the Work offline checkbox.

See also:

1 Like
5

for anyone interested the documentation of how to use ConnectTCP to connect to another qube is documented below. Personally, I think the qubes-rpc documentation page should link below document as that is the first place someone will look for information like below.

1 Like
6

Borrowing an idea from the excellent Wireguard Interworkings page, you can easily setup a different network namespace where by default, only the “lo” interface exists.

Behold:

user@disp2170:~$ sudo ip netns add isolated
user@disp2170:~$ sudo ip -n isolated link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
user@disp2170:~$ ping -c4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=12.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=13.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=15.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=14.3 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.786/14.050/15.226/0.874 ms
user@disp2170:~$ 
user@disp2170:~$ sudo -E ip netns exec isolated sudo -E -u \#$(id -u) -g \#$(id -g) ping -c4 8.8.8.8
ping: connect: Network is unreachable
user@disp2170:~$ 
user@disp2170:~$ #Replace "ping -c4 8.8.8.8" with "firefox" on the previous command...
user@disp2170:~$# ... and you will only be able to reach localhost
user@disp2170:~$

(the commands were run in a “debian-12”-based dvm)

You can easily script this, checking for the existence of the “isolated” namespace to avoid errors, along the lines of:


#!/bin/bash
[[ $(sudo ip netns list) =~ isolated ]] || sudo ip netns add isolated
sudo -E ip netns exec isolated sudo -E -u \#$(id -u) -g \#$(id -g) firefox
2 Likes
7

Maybe I should add this as a “community guide” :thinking:

2 Likes
8

Can someone provide more clarity on #3 (3. Binding to different qubes using RPC policies) in Firewall | Qubes OS

I want to have a browser qube, say vm-browser, connect to port 80 of two different qubes

vm-browser:10880 → vm-service-1:80
vm-browser:10890 → vm-serice-2:80

The documentation of #3 is confusing and does not explain clearly how to do it.

1 Like
9

As I read the documentation, I think the key is to have two different policies in /etc/qubes/policy.d/30-user-networking.policy:

qubes.ConnectTCP +80 vm-browser @default allow target=vm-service-1
qubes.ConnectTCP +81 vm-browser @default allow target=vm-service-2

If these are in place then, according to the documentation, qvm-connect-tcp ::8x should bind to port 80 on the target qube, as specified by x. I don’t see how specifying localhost:10880 or localhost:10890 would play a role. However, section #3, I admit is getting more confusing the more I read it… It’s not clear to me how the latter binds to port 80 in the destination qube.

Note: edited to update my initial, incorrect, reading.

1 Like
10

Maybe the following will shed some light…

Transcribing the documentation to your case, but in the spirit of replacing ports 444 and 445 with 80 and 81, gives the policies:

  qubes.ConnectTCP  *  vm-browser @default allow target=vm-service-1
  qubes.ConnectTCP +81 vm-browser @default allow target=vm-service-2

where the call:

  [user@vm-browser #]$ qvm-connect-tcp ::81

“will restrict the binding to only the corresponding TCP port of vm-service-2”, port 81, and “will still bind TCP port 80 of vm-service-1 to vm-browser but now, calling it with port 81”.

Reading the documentation in this light suggests that case 3, Binding to different qubes using RPC policies, does not apply to the same service (each listening on the same remote port) offered in two different qubes.

Still confusing is the final statement that seems to imply that qvm-connect-tcp ::81 will behave like qvm-connect-tcp 81::80 and target vm-service-1 as a port forward.

1 Like
11

the e.g. given in the documentation is little different from what I am looking for. In the documentation below setup is described

untrusted:10444 → my-tcp-service:444
untrusted:445 → my-tcp-service-bis:445

1 Like
12

Based on my reading, the documentation does not cover the case of directing traffic to the same service/port on two different qubes. So I’m not sure if it would be possible to achieve

at least with qvm-connect-tcp.

1 Like