The Art of Running a Tor Bridge or Relay

enhancing your contribution with sysadmin fu

Format of the workshop

  • Presentation, and then "ask us anything".
  • Add relevant questions whenever in the chat.
  • The focus is on the sysadmin part, not on configuring tor:
  • Nothing much on the application
  • Nothing much on pluggable transports

Basics

Volunteers running nodes (relays or bridges) isn't an optional feature. It's critical!

The health and safety of the entire Tor network relies on volunteers running nodes!

Who are you?

  • Run public internet services before?
  • The Internet is a viciously hostile environment
  • Tor is a target
  • Do you have the resources, time, skillset?
  • Do not "set and forget"
  • Maybe pool together resources?
  • Student group? Affinity group? Hackerspace?

WARNING, again

  • A Tor node is a valuable target to a variety of adversaries.
  • Presentations about "breaking Tor" appear everywhere from DefCons to NSA slides revealed by Snowden.
  • A broken Tor endangers lives.
  • Maybe donate instead?

Expectations for relay operators

Some highlights

  • Don't look at, or modify, network traffic.
  • Don't proxy your relay exit traffic through a VPN or other proxies.
  • Good operational security (OPSEC).

Some highlights

  • Remember that running a relay is an act of transparency (even though being a Tor user is an act of privacy), because the way to strengthen trust in relays is by having a stronger community.
  • Be sure to set your ContactInfo to a working email address in case we need to reach you.

What is a bad relay?

  • A bad relay is one that either doesn't work properly or tampers with our users' connections with maliciousness or misconfiguration:
  • Tampering with exit traffic in any way (including dropping accepted connections)
  • Running HSDirs that harvest and probe .onion addresses

What is a bad relay?

Too many choices

  • Bridge or public relay?
  • An Exit?
  • Where?
  • Residential connections?
  • Colocation facility with bare metal?
  • Virtualize provider (VPS, cloud)
  • Operating system: what you're most comfortable running

More on where and providers

Diversity

  • IP addresses/ASs: locations on the internet
  • Providers: beyond the Hetzners, over the Digital Oceans
  • Operating systems: a lot of Linux. yes, more BSDs, but...
  • Hardware platforms: likely too much x86/Intel
  • aarch64, MIPS, RISC-V

Operating System: Part I

  • Not a shared system, not for multiple purposes
  • Tight install: limit packages, update OS before doing anything: "reductive security"
  • Tor data directory /var/lib/tor,/var/db/tor,/var/tor: separate partition,slice ~500-750M
  • Regular patching cadence: automate:
  • Get on relevant OS security announce list
  • Base operating system
  • Packages... especially Tor

Operating System: Part II

  • SSHD
  • ed25519 keys with passwords protected
  • Limit access
  • Brute force noise: firewall, fail2ban
  • Time: not transactional database, but it matters
  • ntp daemon, not @daily rdate
  • chronyd (for Fedora)
  • UTC makes correlating events easier

Other OS considerations

  • @daily
  • firewalling
  • full-disk encryption
  • DNS configuration, especially for Exits

torrc

  • 259 lines torrc.sample (!):
Nickname    myNiceRelay  # Edit this
ContactInfo your@e-mail  # please avoid obfuscation
ORPort      9001
ExitRelay   0
SocksPort   0

MyFamily

Log notice ${your-distinct-log}

Fuller experience

  • nyx
  • Configuration Management
  • Ansible
  • Puppet

After Day0

After Day0

${DATADIR}/stats

  • optimizing
  • sysctl tweaks
  • more resources?
  • Tor package on your operating system
  • Changelog
  • tracking, contributing

Questions? Comments? Into the chat!

torproject.org