search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
539 stars 48 forks source link

document how to route all traffic over Tor / how to disable Qubes default clearnet traffic #7586

Open adrelanos opened 2 years ago

adrelanos commented 2 years ago

The problem you're addressing

For users that desire advanced anonymity, there should be no clearnet traffic while performing activities via Tor that require privacy.

This is because when the user's internet connection breaks down (usual internet service provider (ISP) issues, network coverage issues, WiFi issues, hardware issues, power loss, ...) then both all clearnet and Tor connections break down at the same time. A passive advanced adversary could correlate anonymous and non-anonymous connections. An active advanced adversary (such as ISP level) could even briefly on purpose disconnect a few users at a time and thereby narrow down which users would loose a clearnet/Tor connection at the same time.

That a user is connected anonymously and non-anonymously to the same server is likely nowadays due to internet centralization with very popular services such as Google Analytics almost everywhere, Cloudflare and Amazon AWS data centers to name a few omnipresent points of centralization.

This is also documented here: https://www.whonix.org/wiki/DoNot#Use_Clearnet_and_Tor_at_the_Same_Time

The solution you'd like

User documentation on how to disable all Qubes clearnet default traffic. Let's start with this first before considering automation (such as Qubes salt, some button in a GUI, or what else.

The value to a user, and who that user might be

An advanced anonymity feature defeating some attacks by advanced adversaries.

related

feature request

This is a feature request for Qubes core. The ones who might now best are probably the Qubes developers.

Could you please list all the places in which Qubes generates default clearnet traffic? Once known, I could document how to disable these. A few coming to mind:

tzwcfq commented 2 years ago

What else?

Default qubes.UpdatesProxy policy for TemplateVMs is using sys-net: /etc/qubes/policy.d/90-default.policy

# HTTP proxy for downloading updates
# Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=sys-whonix
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy  *   @tag:whonix-updatevm    @default    allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy  *   @tag:whonix-updatevm    @anyvm  deny
# Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy  *   @type:TemplateVM        @default    allow target=sys-net
qubes.UpdatesProxy  *   @anyvm                  @anyvm  deny

Also need to check dom0 update qube: qubes-prefs updatevm

DemiMarie commented 2 years ago

For users that desire advanced anonymity, there should be no clearnet traffic while performing activities via Tor that require privacy.

Does that apply to e.g. DHCP traffic? There isn’t much that can be done about that.

Otherwise, ensuring that nothing can talk to sys-net via qrexec and that all network traffic goes through sys-whonix should suffice.

tzwcfq commented 2 years ago

Qubes network time synchronization running in sys-net

Wouldn't it cause a problem for some users if he select sys-whonix as a clockvm and user will have wrong RTC time from hwclock due to BIOS reset or some hardware RTC fault or user will boot in Windows and his RTC will be changed from UTC to local timezone? sys-whonix won't be able to connect to Tor if you don't have accurate clock: 7/8/2015 6:49:43 AM.695 [WARN] Our clock is 1 hours, 10 minutes behind the time published in the consensus network status document (2015-07-08 08:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Maybe there's a need to make a notification of this warning for user so that he would pay attention to the problem with his system time and fix it manually.

adrelanos commented 2 years ago

For users that desire advanced anonymity, there should be no clearnet traffic while performing activities via Tor that require privacy.

Does that apply to e.g. DHCP traffic?

If the DHCP traffic:

Since DHCP "usually" (afaik) does not leak to the internet / ISP and stays within the user's LAN, that should be OK.

But some ISPs are actually LAN based and then there would be DHCP leaking to the ISP. This isn't popular. But these users would be at a disadvantage.

Otherwise, ensuring that nothing can talk to sys-net via qrexec and that all network traffic goes through sys-whonix should suffice.

That's useful.

https://github.com/QubesOS/qubes-issues/issues/1814 was an issue until a while ago but it's the kind of categories to look for. Or Qubes network time synchronization running in sys-net. The question is, if sys-firewall or sys-net generates any other clearnet traffic by itself.

adrelanos commented 2 years ago

Qubes network time synchronization running in sys-net

Wouldn't it cause a problem for some users if he select sys-whonix as a clockvm

That is: https://phabricator.whonix.org/T387

sys-whonix won't be able to connect to Tor if you don't have accurate clock: 7/8/2015 6:49:43 AM.695 [WARN] Our clock is 1 hours, 10 minutes behind the time published in the consensus network status document (2015-07-08 08:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!

For a few releases now, sdwdate can fix slow clocks including very slow clocks (such as clock being set to year 1980). More details here: https://www.whonix.org/wiki/Dev/TimeSync#Clock_Fixing

But this is getting off-topic here. Please open a separate discussion for sdwdate if required.

Maybe there's a need to make a notification of this warning for user so that he would pay attention to the problem with his system time and fix it manually.

That is: https://www.kicksecure.com/wiki/Sdwdate-gui

feffiboujike commented 1 year ago

I have had success by adding firewall rules to every non-Whonix VM that prevents outgoing traffic.

sudo nft add chain ip filter OUTPUT '{ policy drop; }' sudo nft add rule ip filter OUTPUT oifname "lo" counter accept sudo nft add rule ip filter OUTPUT counter drop

sudo nft add chain ip6 filter OUTPUT '{ policy drop; }' sudo nft add rule ip6 filter OUTPUT oifname "lo" counter accept sudo nft add rule ip6 filter OUTPUT counter drop

I have not seen any leaks when I apply these rules before connecting to any network.

Is there anything preventing this from being a temporary solution to this problem until the Qubes developers get around to examining it properly? It would be very easy to make a script that turns this on/off.

DemiMarie commented 1 year ago

@feffiboujike Not that I can think of, though you can simplify things. In particular you can use inet instead of handling IPv4 and IPv6 separately, the counter drop can be omitted, and the rest can be handled in a single transaction.

adrelanos commented 1 year ago

For issue tracking purposes: Please add the Whonix tag.

DemiMarie commented 1 year ago

I am not sure how much this helps, tbh.

Tor does not protect against traffic confirmation attacks. It is still possible to correlate outgoing traffic from the user’s machine to traffic at a particular server and therefore determine if the user is connecting to that server. This attack cannot be prevented without either paying a large latency penalty (mixnets) or by sending a constant amount of traffic even if most of it is wasted.

adrelanos commented 1 year ago

That's a more difficult attack that requires a stronger adversary.

If this task was solved, then at least the mentioned omnipresent points of centralization could not mount this attack anymore.

A traffic confirmation attack is in a different category than than a user connected to $cdn_server both anonymously and non-anonymously that can witness that both connections stopped at the very same time.