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

Long Wiki Edits Thread

Sorry, time poor at the minute. I’ll have a look shortly.

Anyhow, adw’s recent doc effort re: upgrading Fedora 26 to 27 templates makes me realize that we can start to address the whiner comments i.e. “too much text”, “too many warnings” etc.

Why don’t we for fun mirror Qube’s approach, and have a short section also, something like so:

(applies if you have unique content differing from the Qubes entry)

Quick Guide

Create the dvm which the DispVM will be based on.

[dom0]: qvm-create -P <pool_name> --template service-dvm --class DispVM --label red disp-sys-net
[dom0]: qvm-prefs service-dvm virt_mode hvm
[dom0]: qvm-prefs disp-sys-net provides_network true

Create the sys-net DispVM.

[dom0]: qvm-create -P <pool_name> --template service-dvm --class DispVM --label red disp-sys-net
[dom0]: qvm-prefs service-dvm virt_mode hvm
[dom0]: qvm-prefs disp-sys-net provides_network true
[dom0]: qvm-prefs net-disp netvm “”
[dom0]: qvm-pci footnote reason
[dom0]: qvm-pci attach --persistent net-disp : footnote reason
[dom0]: qvm-prefs disp-sys-net autostart true
[dom0]: qubes-prefs clockvm disp-sys-net footnote optional

etc…

Now put this in a pretty box, and everyone will be happy :wink:

2 Likes

I like that idea! Bare bones: install software-foo / configure software-foo

whiners re: there are two categories of whiners

  • i know what I’m doing so these warning or “notice boxes” don’t apply to me. ( there the ones who should be reading them)

  • i don’t understand how important this info really is (they think the magical properties of Whonix/Tor will keep them anonymous)

That information if there for a reason. If those whiners lived in a country where even thinking of free speech could get you thrown in prison they would be grateful for those warnings/text.

On another note, I went ahead and submitted that qubes-docs DispVM pull request. The instructions may be a little more verbose than they’re used to seeing. I have my fingers crossed.

2 Likes

Great stuff 0brand. If they accept it, we link to your stuff. If rejected, we create a page here as previously discussed.

1 Like

-> Fixed

-> Fixed

See below.

@Patrick

https://github.com/tasket/Qubes-VM-hardening

vm-boot-protect-root - Protects /home/user as above, automatic /rw executable deactivation, whitelisting, checksumming, deployment. Works with appVMs, netVMs, etc. that are template-based.

CAUTION: The -root option by default removes prior copies of /rw/config, /rw/usrlocal and /rw/bind-dirs. This can delete data!

Is the -root option safe for Whonix? This is why I didn’t recommend it in hardening list - not sure.

1 Like

Minor nits and rewording. Suggestion for introduction:

Create Custom sys-net, sys-firewall, and sys-usb DispVMs

Users have the option of creating customized DispVMs for the sys-net, sys-firewall and sys-usb VMs. In this configuration, a fresh VM instance is created each time a DispVM is launched. Functionality is near-identical to the default VMs created following a new Qubes’ installation, except the user benefits from a non-persistent filesystem.

Functionality is not limited, users can:

  • Set custom firewall rulesets and run Qubes VPN scripts. [ref]By making necessary changes to the dvm template.[/ref]
  • Set DispVMs to autostart at system boot.
  • Attach PCI devices with the --persistent option. [ref]Since both of the aforementioned configuration options are only required for the initial DispVM creation.[/ref]

Using DispVMs in this manner is ideal for untrusted qubes which require persistent PCI devices, such as USB VMs and NetVMs.

Note: Users who want customized VPN or firewall rulesets must create a seperate dvm for use by each DispVM. If dvm customization is not needed, then a single dvm is used as a template for all DispVMs.

(put note: stuff in an info box)

2 Likes

https://www.whonix.org/wiki/Tor_Browser#Bypass_Tor_Censorship is very good to have. Nits:

  • Bypass Tor Censorship is too ambiguous. I made the same mistake recently in a forum discussion. Not sure it can be clarified though. There is censorship at ISP level and at destination level. That could use some clarification throughout the wiki. Users usually don’t know if they can’t reach a website if it’s their ISP or destination censoring. Even if they are using Tor.
  • needs a reference from https://www.whonix.org/wiki/Tunnels/Introduction
  • needs a reference from https://www.whonix.org/wiki/Surfing_Posting_Blogging
1 Like

torjunkie:

See below.

@Patrick

https://github.com/tasket/Qubes-VM-hardening

vm-boot-protect-root - Protects /home/user as above, automatic /rw executable deactivation, whitelisting, checksumming, deployment. Works with appVMs, netVMs, etc. that are template-based.

CAUTION: The -root option by default removes prior copies of /rw/config, /rw/usrlocal and /rw/bind-dirs. This can delete data!

Is the -root option safe for Whonix? This is why I didn’t recommend it in hardening list - not sure.

When setting the -root option up:

Says prior copies. Does not always remove. Only at setup time. This is
how I understand the description. Under that assumption:

  • Whonix (and any non-Whonix VM) generally: loose your data - have a
    backup and restore or create a new VM and migrate there?
  • for new Whonix-Gateway VMs: shouldn’t matter - should be ok - TODO:
    can you check if Tor data (entry guards) in /var/lib/tor will persist
    reboots? (Just add an extra empty text file there.) I guess so. But
    should be tested.
  • for existing Whonix-Gateway VMs: these would loose their Tor entry
    guards - recommend restore

Not trivial. Needs some time. But should be ok to have on advanced
security guide.

1 Like

OK - will do a test.

We should link this Qubes command line cheat sheet somewhere, since it is very handy.

https://github.com/Jeeppler/qubes-cheatsheet/blob/master/qubes-cheatsheet.md

1 Like

https://phabricator.whonix.org/tag/user_documentation/

I attempted to create an “entry guard technical” and “entry guard non-technical” but it didn’t look good (duplicating information). I settled on adding some info on “traffic analysis” in the introduction hoping users would better understand Tor/entry guards are only a imperfect/partial solution. I’m not even sure if the introduction should be edited at all since its almost verbatim from the Tor wiki?

There are minor edits in other areas but not worth posting here since the entire entry guard chapter would need to be posted along with them. Plus they’re not very important edits.

If any changes are needed please let me know!

The only edit here are to the first paragraph of the wiki/Tor#Entry_Guards

Persistent Tor Entry Guards Introducion

Current practical, low-latency, anonymity designs like Tor fail when the adversary can see both ends of the communication channel. (edits start) If an adversary does not control Tor relays, but is able to monitored both ends of the network, a technique called traffic analysis could be used to glean enough information to profile a user. The term traffic analysis is used to described a multitude of different methodologies which can be used to analyze network traffic patterns. Be that as it may, all of those methods fall into one of two categories.

passive traffic analysis - an adversary will extract features from a data stream on one end of the network and then look for those same features on the other side of the network.

active traffic analysis - the adversary alters the timings of packets on one end the the network according to a specific pattern and looks for that pattern on the other side of the network.

Both of the above methods can be used on cleartext as well as ciphertext (encrypted) traffic, and with a greater number of packets observed, the the greater likelihood that information can be extracted from the network traffic which in turn could then be used to profile a user. To put these dangers into better perspective; (edits end) suppose an adversary controls or watches the Tor relay that a user chooses to enter the network, and also controls or watches the website visited. In this example, the research community is unaware of any practical, low-latency design that can reliably prevent the attacker from correlating volume and timing information on both ends.

Mitigating this threat requires consideration of the Tor network topology. Suppose the attacker controls, or can observe, C relays from a pool of N total relays. If a user selects a new entry and exit relay each time the Tor network is used, the attacker can correlate all traffic sent with a probability of (c/n)2. For most users, profiling is as hazardous as being traced all the time. Simply put, users want to repeat activities without the attacker noticing, but being noticed once by the attacker is as detrimental as being noticed more frequently. Mathematically speaking, choosing many random entry and exit points to the network prevents the user from escaping profiling by this kind of attacker with end-to-end capabilities.

0brand:

Do you think given the questions by the users, pointing the user to the
Tor page (and assuming the user is reading it), do you think it would
answer the user’s questions?

If not, should content be reorganized? Improving headlines? Any headline
that would suite well as a deeplink the user could be given for the
question(s) being asked?

I’m not even sure if the introduction should be edited at all since its almost verbatim from the Tor wiki?

Probably not much.

Mathematically speaking, choosing many random entry and exit points to the network prevents the user from escaping profiling by this kind of attacker with end-to-end capabilities.

That one seems weird. Could lead to users taking wrong choices. In
theory it may be true if the amount of traffic transmitted is so low,
that math doesn’t work. But far from any practical implementation let
alone something the user could do by using “always non-persistent Tor
entry guards” or so.

Let’s replace that sentence by [...].

1 Like

FYI - last released version and a possibly next testers-only VirtualBox version - for changelog tracking:

https://github.com/Whonix/Whonix/compare/14.0.0.6.9-developers-only...whonix:14.0.0.7.3-developers-only

1 Like

Regarding Tor technical information:

IMO, it’s best if our wiki presents only a general, simplified overview and links to the details as provided by TPO. That prevents loss in translation and also reduces maintenance burden. For example, entry guard policy will soon be updated again: https://github.com/torproject/torspec/blob/master/proposals/291-two-guard-nodes.txt

3 Likes

I was so focused (obsessed) with trying to find a solution for the probability equations in a way readers could understand that I lost sight of what I was supposed to be doing. 4 days wasted trying to make sense of all those research papers. I don’t think I even learned anything in the process. I knew shortly after posting the proposed wiki changes that I needed to try again.

When I read over the entry guards chapter again I can see what needs to be done now.

Sound good to me.

I appreciate your help on this!

2 Likes

These outstanding documentation items don’t look like much fun at all, but many are necessary.

Personally I want to do more clean up editing work as a current priority, as there is sloppy English, broken links / redirects, outdated info, irrational chapter structures, huge blocks of text, or multiple other irritations on numerous pages on the main ToC. Maybe this appiles to 50% of pages or more (but I am a harsh critic).

If Whonix doesn’t look shiny in the documentation, then it detracts significantly from the product in the user’s mind. No getting around that.

0brand is good with technical stuff, so I’d love to see our new mod tackle some new stuff / instructions / templates if he/she is keen? :slight_smile: I’m happy to do new content edits in combo with clean up work, edit others work etc. but I’m focusing on cleanup work currently.

2 Likes

Actually I find much of the phabricator outstanding docs interesting. Keep in mind that I’m the least experienced out of everyone. When I edit/write chapters I do quite a bit of reading and research to make sure I have a solid understanding of the content. This is the part I enjoy the most and what I learn also carries over when a user asks a question. Instead of parroting what is in the wiki. I can answer their question thoroughly.

This difference is –

knowing what to say (I just repeat what is in the wiki chapter)
vs
saying what i know (i have a better understanding on a subject than what is written in the wiki and I use that knowledge to answer the question. Plus add link to wiki chapter)

What it comes down to is editing the current chapters helps with my education. Plus, I enjoy it. So its a win-win all around. :slight_smile:

On the other hand I’d be just as happy with new content edits. I’m sure the wiki could use an update of sorts. We wouldn’t have to try very hard to think of some ideas. hmmm I know! How about a chapter on one_time_pads :yum:

What to do? Editing current chapters or new chapters is fine with me. (and fun for me!). Let me know what you need help with and I’ll get started on it as soon as I finish with my prior commitments. I don’t like to leave things unfinished.

BTW entry_guards chapter is (for the most part) a perfect example of…

broken links / redirects, outdated info, irrational chapter structures, huge blocks of text, or multiple other irritations


One more thing. I took a look at https://qubes-os.org/doc/whonix/ and i was thinking it could be improved. Since everyone is under time restraints. I wanted to officially volunteer as the unofficial Qubes/doc/whonix maintainer (aka doc pull requester).

If there is anything that needs to be added to the page (now and future) let me know. Perhaps links to some of the generalized chapters on security? Non-Whonix users may be interested in these as well.

https://whonix.org/wiki/Computer_Security_Education

https://whonix.org/wiki/Security_Guide

https://whonix.org/wiki/Advanced_Security_Guide

https://whonix.org/wiki/System_Hardening_Checklist

A possibility there is also Whonix wiki instructions that could be added to Qubes/doc/?

2 Likes

0brand:

Actually I find much of the phabricator outstanding docs interesting.

:slight_smile:

Keep in mind that I’m the least experienced out of everyone. When I edit/write chapters I do quite a bit of reading and research to make sure I have a solid understanding of the content. This is the part I enjoy the most and what I learn also carries over when a user asks a question. Instead of parroting what is in the wiki. I can answer their question thoroughly.

Very good!

What to do? Editing current chapters or new chapters is fine with me. (and fun for me!). Let me know what you need help with and I’ll get started on it as soon as I finish with my prior commitments.

As for priority wishes, I’d wish I’d had this one:

Wiki search fallback suggestion

Otherwise it’s hard to define priorities.

One more thing. I took a look at https://qubes-os.org/doc/whonix/ and i was thinking it could be improved.> Since everyone is under time restraints. I wanted to officially
volunteer as the unofficial Qubes/doc/whonix maintainer (aka doc pull
requester).

Yay!

A possibility there is also Whonix wiki instructions that could be added to Qubes/doc/?

I am personally discouraged to contribute to Qubes docs since doing so
is too cumbersome for me.

Hi 0brand,

That would be great if you would take on that Qubes role. And also if you like any of those phabricator items, then go for it! :slight_smile:

Anyhow, re priorities, it would be helpful if you wanted to have a crack at those 2 templates HulaHoop and Patrick wanted + whatever else you think is a priority.

These are my proposed changes for Tor#Entry_Guards

These edit go across two templates

https://whonix.org/wiki/Tor#Entry_Guards

https://whonix.org/wiki/Template:Persistent_Tor_Entry_Guards_Introduction

Please let me know if any changes are needed

Introduction

Note: Text Box taken from Tor project describing entry guards is not posted. It will have one minor edit as per Patrick.

Many well known enhanced anonymity designs such as Tor, Whonix, Tor Browser Bundles (TBB) all use persistent guards. This is attributable to community based research initiatives which have shown the use of persistent Tor entry guards benefit security and lowers the probability of an adversary profiling a user. For this reason, allowing the Tor client to rotate entry guards through natural churn is the correct choice for most users. At the time this chapter was written, the Tor client selects three guard nodes, but defers to a primary guard whenever possible. Guards have a primary lifetime of 120 days.

Warning: In some situations it is safer to not use the usual guard relay!

Guard Fingerprinting

While users are encouraged to allow guard rotation through natural churn, there are some corner cases in which an adversary could fingerprint the entry guards and de-anonymize a user. This maybe be possible if:

  • the same entry guards are used across various physical locations and access points.

  • the same entry guards are used after permanently moving to a different physical location.

Consider the following scenario. While at their home address a user connects to Tor using a laptop. Soon afterwards, that same user attends a prominent event or protest in a nearby city. At that location, the user decides to anonymously blog about what transpired using the same laptop. The fact that the Tor client is using the same entry guard normally correlated with the user’s home address is problematic. Network adversaries would have a high certainty that the “anonymous” posts from the city location are related to the same person who connected to that specific guard relay from their home. The relative uncommonness of Tor usage exacerbates the potential for de-anonymization.

Several options are available to mitigate the risk of guard fingerprinting across various physical locations. These options allow the original entry guards are used when back at the home address.

  • Clone Whonix-Gateway (sys-whonix) with New Entry Guards

  • Regenerate Tor State File after Saving Current Tor State

  • Configure Tor to use Alternate Bridges

  • If moving to a new location permanently, create Fresh Tor Entry Guards by Regenerating the Tor State File

The risk of this attack is less severe now that upstream (The Tor Project) has changed its guard parameters to decrease the de-anonymization risk.

This adversary technique is similar to tracking users via MAC addresses. Therefore, for users facing this threat in their personal circumstances, MAC address randomization is also recommended.

Forum discussion:
[…]persistent-tor-entry-guard-relays-can-make-you-trackable-across-different-physical-locations/2090

Manual Rotation of Tor Guards

Security and Performance Related Issues

On occasion, users may be tempted to create a new Whonix-Gateway : sys-whonix on account of:

  • Bootstrapping is slow or regularly fails.
  • Tor logs show warnings suggesting evidence of route manipulation attacks or other oddities.
  • Logs reveal attempted attacks on Whonix or Tor processes, for example in AppArmor logs.
  • Current Tor performance is very slow or unreliable due to collapsing circuits or other factors.
  • The user is concerned about the amount of Tor data that could be revealed if the Whonix-Gateway is infected, particularly after a long period of use.
  • A change in the Tor guard selection which has resulted in poor throughput due to capacity issues.

Creating a new Whonix-Gateway or sys-whonix will likely lead to a new set of Tor entry guards, which is proven to degrade anonymity. Voluntary guard rotation via a new Whonix-Gateway is more dangerous than allowing “natural churn” as chosen by the Tor application for several reasons:

  • It increases the likelihood of a compromised or malicious Tor guard being selected, leading to a corresponding rise in the chance of a successful correlation attack if the adversary runs Tor exit relays in the network.
  • The user is more likely to traverse a given set of Internet infrastructure links that are under the adversary’s control, such as Autonomous Systems (ASes) or Internet Exchange Points (IXPs).
  • Every change of Tor guards acts like a fingerprinting mechanism, since other users are less likely to pick the same set. If the adversary is able to enumerate a user’s Tor guards, and later observes someone with the same set, the chance is high the two observations stem from the same person.

For these reasons the Tor Project has changed its design and reduced the number of primary guard nodes to 3, and increased the set period for guard rotation. The user should also contemplate the possibility their current poor Tor performance is an attempt by an advanced adversary to cause frustration, leading to a manual change in Tor guards:

We should also consider whether an adversary can induce congestion or resource exhaustion to cause a target user to switch away from her guard. Such an attack could work very nicely coupled with the guard enumeration attacks discussed above.

In one sense, users should welcome slow entry guards, since “honeypot” operators on the Tor network are unlikely to have constrained bandwidth which might chase away intended targets. This thinking aligns with intelligence disclosures which deem all Tor users to be persons of interest to state-level adversaries.

Warning: Users considering using disposable Whonix-Gateway ProxyVMs in Qubes R4 are warned that this technique poses an even greater anonymity risk than described above; new Tor guards are created during each distinct Whonix session.

Under certain circumstances, users will feel compelled to proceed despite the anonymity risks. In this instance, it may be safer to first try:

  • One of the fallback primary entry guards.
  • A configured bridge.
  • Possibly combine tunnels with Tor.
  • Creating a fresh Whonix-Gateway (sys-whonix), and copying across the Tor state file.

The user can also persist with poor performance and wait for normal guard rotation. Users should note that regenerating the Tor state file poses the same anonymity risks as outlined in this section.

Mitigate the Threat of Guard Fingerprinting

If guard fingerprinting over different locations is a concern. There are several options that may be used to mitigate this threat. These option include using bridges, temporarily rotating guards or cloning Whonix-Gateway with new guards. However, the decision to rotate entry guards should not be taken lightly even if on a temporary basis. Users should weigh the risk posed by rotating guards as mentioned in the previous chapter against the threat posed by fingerprinting. In some cases, the decision to not rotate entry guards may be the better choice. In any event, this decision should be made on a case by case basis considering all the benefits and risks for each possible choice.

Clone Whonix-Gateway (sys-whonix) with New Entry Guards

Users can clone a current Whonix-Gateway (sys-whonix) VM and regenerate the Tor state file. Once the VM is cloned, care must be taken to ensure the original is not unintentionally used for the anonymous activities. It light of this, users may wish to disable networking in the original Whonix-Gateway until back at the home address.

Warning: Users should not clone the Whonix-Gateway (sys-whonix) with new guards at the home address. If the Tor client connected through the home network, the new guards could be correlated to the home address.

  • Create a clone of the Whonix-Gateway (sys-whonix) and name it Whonix-Gateway-temp VM (sys-whonix-temp VM).
  • Virtualbox: follow [these instructions] to create a VM snapshot.
  • Qubes-Whonix: Right-click on sys-whonix-> Clone VM
  • Regenerate the Tor State File.

Regenerate Tor State After Saving the Tor State Folder

Non-Qubes-Whonix only!

Prior to arriving at the remote location. The user moves the Whonix-Gateway Tor state folder to the $HOME directory then regenerates the Tor state file.

1. In Whonix-Gateway konsole, stop Tor.

sudo systemctl stop tor@default

2. In Whonix-Gateway konsole, remove the temporary Tor state folder

sudo rm -r /var/lib/tor

3. Restore the Tor state folder

sudo mv ~/tor /var/lib

4. Restart Tor

sudo systemctl restart tor@default

Prior to arriving back at the home location, the Tor state folder is restored back to its original settings.

1. In Whonix-Gateway konsole, Stop Tor

sudo systemctl stop tor@default

2. In Whonix-Gateway konsole, move the Tor state folder to the $HOME directory

sudo mv /var/lib/tor ~/

3. In Whonix-Gateway konsole, restart Tor

sudo systemctl restart tor@default

Alternating Bridges

If bridges are already in use, alternate bridges are recommended for different locations. If bridges are not used, consideration should be given to using entry guards in your primary location and relying on alternate bridges in different locations.

Complete the following steps on Whonix-Gateway Qubes-Whonixsys-whonix.

1. Disable_Tor

2. Configure Tor to use bridges. Refer to the Bridges documentation.

3. Enable Tor using whonixsetup / whonix-setup-wizard at the new location.

4. Before leaving this location, disable Tor and add a different bridge address if traveling to a different area. To revert to the usual guard nodes used at home, remove the torrc bridge settings before enabling the network, or rollback to a VM snapshot created at home.

Copy Tor Configuration files and Settings to Another sys-whonix Instance

No changes in this chapter. Next chapter has edits in steps 1 and 5


Configure Non-Persistent Entry Guards

# These instructions work to configure sys-whonix to use non-persistent entry guard but some functionality changes.

Example:

[ user@host:~]$ arm

“permission denied”

[ user@host:~]$ sudo arm

arm starts and is functional

## Also instructions state “For Whonix 12 or earlier”. Am I missing something?

1. If using Whonix 12 or earlier, adjust whonixcheck settings.

2. […]
3. […]
4. […]
5. Before leaving this location, shutdown the Whonix-Gateway (sys-whonix) VM. When the new location is reached, new entry guards will be used when the VM is started. To revert to the usual guard nodes at home, remove the torrc setting before enabling the network, or rollback to a VM snapshot that was previously created.

2 Likes

Good work 0brand. I’ll have a look and post any suggestions.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]