How to give no clue when connecting Qubes to network?

[stealth-qubes]

@dpr

Please keep us posted on how it is going for you.

Here we go…

@stealth-qubes

IPv6 broadcasts
Disable IPV6 with sysctl in the template of disp-sys-net

I tried to use those 3 commands:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

in the /rw/config/rc.local of the sys-usb-dvm template of my disp-sys-usb VM where I put a wifi USB dongle.

Didn’t work: When my usb dongle connected to a wifi network, I got an IPv6 address for the interface (ip a command) and saw IPv6 trafic on wireshark.

I created a stealh.sh script in my sys-usb-dvm template that I can run on my disp-sys-usb VM before connecting to a wifi network. First lines of stealh.sh are:

# Disable IPv6
sudo ip6tables -I OUTPUT 1 -j DROP
sudo ip6tables -I FORWARD 1 -j DROP

The FORWARD rule ensures there is no traffic that can be forwarded from downstream VMs.

Looks like it works fine this time!

@stealth-qubes

NTP traffic

Didn’t investigate more for the moment.

@icequbes1

What issues did you have?

The clocks on (some of? all of? don’t remember exactly!) my VMs were completely off. Particularly troublesome on my mail VM and on my Signal VM…

@icequbes1

It should be as simple as setting your ClockVM to an AppVM with the clocksync service enabled.

From memory, I think that’s what I did.

@icequbes1

Is a minimal template in use?

Definitely not!

@stealth-qubes

Use qvm-firewall in dom0 for disp-sys-net

@icequbes1

I’m not sure it works like that. qubes-firewall for a VM is enforced on the NetVM (or ProxyVM) of that VM.

Exactly so! By the way, may I take this opportunity, @icequbes1, to thank you for all the good info you put in this forum in general and in this thread in particular. I found it when experiencing with my ideas.

@icequbes1

You’d have to make additional iptables/nft changes in sys-net via user firewall rules to block outgoing traffic from sys-net.

Exactly what I did. Consequently, the next lines of stealth.sh are:

# Allow traffic through [VPN Provider Redacted]
sudo iptables -I FORWARD 3 -j ACCEPT -p udp --dport [Port of 1st VPN Server Redacted]  -d [IP of 1st VPN Server Redacted]  
sudo iptables -I FORWARD 4 -j ACCEPT -p udp --dport [Port of 2nd VPN Server Redacted]  -d [IP of 2nd VPN Server Redacted]  
etc.
sudo iptables -I FORWARD 3+n  -j DROP

I inserted rules in the FORWARD chain from number 3 on since I wanted to preserve the 2 already existing rules:

1. state INVALID and
2. ctstate RELATED,ESTABLISHED

NB: n is the number of VPN server of your VPN provider.

Rule “3+n” drops anything from downstream VMs that does not have a VPN server as a destination.

Finally:

sudo iptables -P OUTPUT DROP

since no trafic should originate from this machine, since it would be unencrypted.

@icequbes1

Use an UpdateVM where Tor or a VPN is upstream and don’t worry about it.

I’m not sure to have ever fully understood the details of the templates updates in Qubes. I know the templates are updated through a VM defined on /etc/qubes-rpc/policy/qubes.UpdatesProxy and that this VM runs a qubes-updates-proxy service.

Nevertheless, when not using my stealth.sh script, I see HTTP traffic on wireshark originating from the VM connected to wifi that very looks like update traffic. Moreover, Qubes suggests me to update some of my templates only after I open an AppVM using that template.

My conclusion is that it is the dispVMs or appVMs that trigger the updates of their templates after reaching to their repositories. The templates then use the qubes-updates-proxy running on the VM defined in /etc/qubes-rpc/policy/qubes.UpdatesProxy to update themselves.

I’d love if someone could confirm this. Thanks in advance!

If this is confirmed, then using an UpdateVM where Tor or a VPN is upstream is not enough (because of the HTTP traffic originating from the VM connected to wifi triggering the update process). Or do I miss something?

@icequbes1

The other is DHCP as the client host name will be ‘sys-net’. Rename sys-net to something else

That (or clone it to use it as the stealth VM) is indeed the easiest because…

@icequbes1

or use random hostname generation if DHCP is used

… I gave a (quick) try to that script without success.

@stealth-qubes

my Tor guard

It looks like that sys-whonix needs to reach many servers when starting. It’s impossible (or demands much more energy than I’m willing to put) to whitelist all the Tor nodes. My workaround is to send sys-whonix through my VPN provider when using my stealth.sh script.

On another topic, I saw (Q Menu → sys-whonix → Tor Control Panel → Utilities tab → onion circuits ) that all my connections to the Tor network flow through 2 or 3 guards (entry points in the Tor network) and that some of them change from one day to another. Question: How is it possible to not have only one Tor guard?? Thanks is advance!!

@icequbes1

use user-specified iptables rules to whitelist only the stuff you expect.

I see we came to the same conclusion!