[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

OS-generated network traffic

Does using Tor Browser in Whonix leave less traces than just running Tor Browser on the host? Running a whole virtual OS should create more network traffic than just Tor Browser. On top of that there’s always network traffic from the host. How can all non-Whonix traffic on the host be blocked when using Whonix?

What measures can be taken against VM OS-generated network traffic that has nothing to do with the purpose of any particular Whonix or Tor session? I’m aware of stream isolation, but can that cover everything? The OS can surely generate more network traffic streams than the number of circuits that stream isolation affords.

andwhatnot:

How can all non-Whonix traffic on the host be blocked when using Whonix?

Not at this point. With Qubes and Qubes-Whonix it’s close, looking
doable but not done. Development help needed.

https://github.com/QubesOS/qubes-issues/issues/1814

https://phabricator.whonix.org/T387

And testing…

Use a firewall on your host e.g. something like corridor or don’ t use your host at all for networking i.e. use bridged networking.

You can always disable the services which generate unwanted network traffic.

I didn’t think that’s also a problem with Qubes, where the host doesn’t even have networking AFAIK.

You make it sound like there’s a piece of software called corridor, but I haven’t found anything.

I guess you don’t mean configuring this in the virtualization software, where bridging is also available.

I’m not sure how that would be done. There are lots of services and I don’t have an overview of what they are, what they are doing or how to monitor if new ones may start.

The wiki can be difficult to navigate if your not familiar with it. You may want to stick with using the wiki search engine for a time.

https://whonix.org/wiki/Advanced_Security_Guide#Whonix-Gateway_Security

@Algernon Interesting. Can you point to a guide about this? Or give a quick idea of how this is done.

Depends on the OS you use. For a standard install of the average linux distro most relevant stuff I can think of is ntp, maybe automatic updates, systemd afaik does some name resolution using google dns. For windows there is certainly more to block.

There is a bridged option for virtualbox or kvm, the latter one also having macvtap. I was also thinking of PCI passthrough like qubes does which, to admit, is not really a bridge.

Hm but it doesn’t work on most laptops, no?

systemd afaik does some name resolution using google dns

Sounds big. Worth separate subject if true. Probably non-issue in Whonix.


?

I don’t see a reason why it shouldn’t.

Yeah unfortunately true. I think we got it though becuase this systemd service s disabled? I don’t know what Debian does but I know they always like privacy preserving defaults. Also why in the world did the systemd authors choose this???

Shouldn’t OS-generated network traffic (host or guest) be a major point of concern when using any kind of anonymity tool? It doesn’t seem very likely that a problem of such scope has never been approached, discussed or researched somewhere. Isn’t this part of the threat model not only of Whonix, but of Tor, etc?

Unsolicited network traffic should be a major point of concern when using any OS, period. This isn’t an issue that’s limited to Whonix users so any such traffic should be stopped upstream if possible. Lack of concern for this is why Whonix discourages using Windows or Ubuntu.

Here’s one example from this forum. If you see other OS-generated traffic, please be specific.

Not Tor. Tor’s job is to provide anonymous routing for your traffic, not to discriminate between the type of traffic that it routes.

Not Tor Browser either. Tor Browser’s job is to provide identical fingerprints to destination websites. What the OS does is beyond TBB’s scope.

These issues should only be addressed by Whonix if ignored upstream.

Seems that the vulnerability due to OS traffic would be potential tracking of hardware as it moves between locations. In most cases, this isn’t catastrophic because of the location anonymity that Tor provides. Can you be more specific about your threat model?

wrt systemd-resolved:

Debian has marked wontfix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658

Can’t state the issue any simpler than this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658#166

Baffling that the systemd maintainers don’t see any problem with the fallback config. Same opt-out of privacy invasion mentality coming to Debian.

AFAIK, systemd-resolved is disabled by default. Disabled on my Fedora templates but enabled in Whonix-13 on Qubes 3.2. Is it being used by anything?

1 Like

I see traffic fingerprinting as a major threat. Each OS and each configuration will I imagine generate a unique network traffic fingerprint. The attacker has to keep an eye on the servers an OS is likely to connect to and inspect the traffic. A good countermeasure example is onionizing software repositories because software updates make you identifiable.

@entr0py Scary

andwhatnot:

Shouldn’t OS-generated network traffic (host or guest) be a major point of concern when using any kind of anonymity tool? It doesn’t seem very likely that a problem of such scope has never been approached, discussed or researched somewhere. Isn’t this part of the threat model not only of Whonix, but of Tor, etc?

The closer you look, the more things you find. There is an army of
people working on tracking. Backed by companies and governments having
available trillions of money. The privacy community is small in comparison.

Whonix 13 systemd version does not have the fallback DNS feature.

Whonix 13 does not use systemd-resolved.

The fallback DNS wouldn’t work anyhow, because:
https://www.whonix.org/wiki/Tor#UDP

So minor concern for Whonix.

But indeed a frightening development in Debian. I don’t think enough
Debian developers have noticed this yet. It’s a wider policy discussion
for debian-devel and hopefully not just up to the systemd maintainers.

Whonix 14 tickets:

done and deployed:
Disable systemd DNS resolver feature
https://phabricator.whonix.org/T471

new (not really needed, just in case):
disable systemd FallbackDNS
https://phabricator.whonix.org/T793

1 Like

This conflict could be resolved by contacting Debian Technical Committee. It requires writing a well phrased message. Anyone up to write a draft?

1 Like