[tor-relays] Re: Call for more Snowflake proxies!

[forest-relay-contact--- via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello.

This is the workaround I came up with, so I wrote a simple guide. It
assumes you are running Debian stable with two IPv4 addresses, one of
which has never been used to relay Tor traffic, and are using nftables
for your firewall. The iptables version should be just as simple.

Add the following postrouting chain to your nftables config, changing
the secondary IPv4 and interface name to whatever you have:

  chain postrouting {
      type nat hook postrouting priority srcnat; policy accept;
      skuid snowflake oif eth0 ip saddr 203.0.113.9 snat to 203.0.113.9
  }

In order to get a not-so-outdated version on Debian stable without using
bloated Docker or compiling from source, you can install the package in
testing. It doesn't require many dependencies since it's a largely self-
contained Go application, so there are no issues with dependency hell.
Put the following in /etc/apt/preferences.d/no-default-testing.pref:

  Package: *
  Pin: release a=testing
  Pin-Priority: -1

Then create /etc/apt/sources.list.d/testing.list and put in:

  deb https://deb.debian.org/debian testing main

Now you will have access to the Debian testing repository, but it won't
try to update your entire system to testing. Update the apt repositories
and install snowflake-proxy from testing. You have to mask the service
during installation so that it won't automatically start:

  adduser --system --group snowflake
  systemctl mask snowflake-proxy.service
  apt update
  apt install snowflake-proxy/testing
  systemctl unmask snowflake-proxy.service

By default, the systemd unit will try to use a dynamic user. You can
disable that so that it uses a real user in order for nftables to work.
I also add a bit of hardening and block IPv6 so that the proxy doesn't
try to use the same IPv6 subnet that you use to relay traffic. Edit the
service file with "systemctl edit snowflake-proxy.service" and add:

  [Service]
  User=snowflake
  KeyringMode=private
  LockPersonality=yes
  DevicePolicy=closed
  ProtectSystem=strict
  ProtectHome=yes
  ProtectClock=yes
  ProtectKernelLogs=yes
  ProtectKernelModules=yes
  ProtectKernelTunables=yes
  RestrictAddressFamilies=AF_INET
  MemoryDenyWriteExecute=yes
  SystemCallFilter=@system-service # this can be tighter
  AppArmorProfile=snowflake_proxy  # so can this

Now create a trivial AppArmor profile for extra security:

  #include <tunables/global>

  profile snowflake_proxy {
    #include <abstractions/base>
    #include <abstractions/openssl>
    #include <abstractions/nameservice>

    /usr/bin/snowflake-proxy mr,
  }

And finally, apply the changes and start the proxy:

  systemctl daemon-reload
  systemctl reload apparmor.service nftables.service
  systemctl enable --now snowflake-proxy.service

If everything went right, you should be running a hardened and fairly
up-to-date snowflake proxy on your Debian Tor relay, without using the
same IP address that you use to relay Tor traffic.

Regards,
forest
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaYaDUQAKCRAw+TRLM+X4
xl2MAP0d9uVIO/rS2JtZsJE8zWh5HiVGhxuaVqsAXvf8UMBeFwEA4OUunTcQEalc
P/XJoa+6YxHuUDVZNHUcDdO2cr0ODgI=
=dSMO
-----END PGP SIGNATURE-----
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx