vanguards
vanguards uses the Stem Tor control port library to connect to a Tor control port. It has three defense subsystems: Vanguards, Rendguard, and Bandguards. All three subsystems apply to both service-side and client-side onion service activity, but NOT to any client traffic that exits the Tor network to the normal Internet.
This is not an endorsement. I don’t have much knowledge about it. This is just me experimenting, making vanguards work on Debian buster.
Open file /etc/tor/vanguards.conf with root rights.
lxsudo mousepad /etc/tor/vanguards.conf
Comment out control_ip = 127.0.0.1 i.e. make that
#control_ip = 127.0.0.1
Change control_socket = to:
control_socket = /var/run/tor/control
Restart vanguards.
sudo systemctl restart vanguards
vanguards should probably use Tor control socket by default so it would work out of the box. Probably worth a bug report against Debian.
Nice. CC’ing our documentation brigade @0brand @torjunkie
Too early for documentation. Don’t even know where to install. Gateway or workstation.
Todo research:
Tor version deb.torproject.org (Whonix uses) vs packages.debian.org vanguards version mismatch?
Sane for installation by default?
Vanguards available from deb.torproject.org?
When we know where to set it up, sure - no probs.
@Patrick My guess is on the GW?
Yes.
This looks easy to add by default. Doesn’t look very error prone and would be a good enhancement.
No.
Asked.
OK got mix vanguards from packages.debian.org with Tor from deb.torproject.org repository?
https://lists.torproject.org/pipermail/tor-dev/2020-January/014118.html
enable vanguards systemd unit file by default
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975
According to Mike Perry we should stick to the defaults as far as layer 2 guards are concerned and not enable circ_max_megabytes because it will silently interfere with file transfers essentially breaking them.
https://lists.torproject.org/pipermail/tor-dev/2020-January/014134.html
A user ticket on Github shows you must anticipate the number of bytes to transfer beforehand with circ_max_megabytes. This is impractical.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975#10
Hi,
This is a deliberate choice that we have made, as there is no reason to
use vanguards unless onion services are being hosted. If vanguards gets
installed accidentally then it can have confusing effects for users. It
is better to explicitly enable it.Thanks,
Iain.
This is a deliberate choice that we have made, as there is no reason to use vanguards unless onion services are being hosted.
Is that so?
If vanguards gets installed accidentally then it can have confusing effects for users. It is better to explicitly enable it.
Strange because the usual Debian way is to start services by default.
They have no idea it protects clients too…
It doesn’t affect users unless explicitly enabled in torrc.
Any authoritative, quoteable references for that? Then I could tell them and get this fixed in Debian. Thereby no workaround on the Whonix level required anymore in future.
I don’t think so. Just needs ControlSocket which is default in Debian nowadays too. The only other issue which doesn’t make this work out of the box on Debian is this vanuards config file change:
Yes here:
The add-on uses our Control Port Protocol and the corresponding Stem Library to defend against these attacks. The hope is that it will we will be able to study the performance and functionality of this feature and gather feedback before we deploy these changes in Tor for all onion services and clients.
We believe that the most serious threat that v3 onion services currently face is guard discovery . A guard discovery attack enables an adversary to determine the guard node(s) that are in use by a Tor client and/or Tor onion service.
Awesome! Added to bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975#15