vanguards - Additional protections for Tor Onion Services

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.

1 Like

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?

1 Like

When we know where to set it up, sure - no probs.

2 Likes

@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


1 Like
1 Like

enable vanguards systemd unit file by default
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975

1 Like
1 Like
1 Like

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.

1 Like

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.

1 Like

They have no idea it protects clients too…
It doesn’t affect users unless explicitly enabled in torrc.

1 Like

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:

1 Like

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.

1 Like

Awesome! Added to bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948975#15

1 Like