Tor Relay Setup

From DevSummit
Revision as of 21:47, 22 November 2016 by Jucsanch (talk | contribs) (Created page with "== Use case for an entry node== * why run an entry node for your friends? ** b/c the entry node is the only node that knows the origin of a request that passes through a tor...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Use case for an entry node

  • why run an entry node for your friends?
    • b/c the entry node is the only node that knows the origin of a request that passes through a tor circuit
    • if an attacker controls a lot of entry and exit nodes, they can run correlation attacks to connect entry packets to exit packets and defeat anonymity
    • if you control the entry node, you mitigate the possibility of attacker correlating entry and exit
    • (and running an exit node is hard)

Implementation Pointers

  • don't do it on a VPS
    • security posture only as strong as its weakest link, smaller the system, the less likely a weaker link
  • if you control your own hardware, the attack surface is smaller (eliminates a ton of uncertainties: what's generating entropy, what's in actual packets, where is machine?)
  • use your favorite OS
    • debian dominates the space (which creates monoculture)
    • consider Open BSD, but work with whatever you're most comfortable with
    • use sshd with a password, use ed5519 (NOT RSA), change keys on regular basis
    • don't run *anything* else on it (not apache, note nginx, etc...)
    • restrict sshd access by ip address
    • remove config support for bluetooth, wifi, mysql, *anything* not tor
    • use a host-based firewall and network-based firewall
    • know your os enough to harden it, block all other possible uses
    • if running server on mac, might need to use MacPorts
  • which release?
    • alpha & stable
    • if you can't update a lot (eg: incorporating into a product), use stable
    • if you can look at it weekly and care about resiliency against emerging attacks, run alpha
  • config file (`.torrc`)
    • many are 1500-ish lines long: don't worry if you feel intimidated by it. that's natural!!! don't give up!!!!
    • tor has *fantastic* documentation: tor website manual, `man tor`, the config file has extensive commenting
    • you only need 5 lines to set up a working relay
    • for a sample config see `torbsd.github.io`(~ 300 lines long, configures a bunch of logging and has a bunch of comments)
    • minimally: need (1) socks port 0 (for talking to localhost), (2) or port 9001 (for onion routing over TCP)
    • can block exit traffic easily
    • can enable stats easily:
      • 2-digit ISO country codes for who is using service and how many
      • ie: for entry and bridge usage
    • and look at them in `var/db/tor` or `var/tor`
  • hardware
    • doesn't need to be that beefy
    • minimally: 2gb of ram, dual core w/ 2ghz processing power
    • look at pcegnines.ch (alix boards are good and $100)
  • host it on a physical box in a data center -> how to shop for data center?
    • look for dedicated colocation hosting
    • give you a box & a console login
    • rackspace: $100/month
    • NYII is good in NYC
    • if you can get cheap colo space in canada, it's maybe worth it...

Gotchas

  • some risks
    • if you run a public node, your ip might get blocked by some sites (banks, hulu)
    • don't run public relay node at home, safe to run a bridge at home
      • worth running a bridge from home, use extra
    • ideal sites: universities, big software companies w/ social mission
  • if you're running an entry relay for friends, make it public (diversifies traffic)
  • some troubleshooting
    • cloudflare blocks tor (or captcha filters it), you can turn this off, many sites don't
  • consensus weight
    • the higher "consensus weight", the more a node will get used
    • how do get consensus weight? reliablity, availability over time
  • failure mode to avoid
    • under-resourced ngo's offer to be providers, mess it up, endganger people
    • also: it's impersonal: relies on people trusting an organization, when they could isntead place trust in a pre-existing social trust network of friends, family, etc..

Context & Training

  • if running a bridge and want to give someone access:
    • give someone IP, name, & fingerprint, *NOT* just the IP
  • if running a relay: TRAIN PEOPLE!!!
    • have a dedicated box that's dedicated to running tor (maybe has tails installed)
  • how to talk about it:
    • mailing lists, irc channel, tor exchange site
    • tor helpdesks by country
    • tor talk
    • access now


Getting Help

  • is there an information commons for rules of thumb?
    • things like good colos, good ISPs, config files, etc...
    • answer: no.
    • this is largely handled informally ATM, email G.!
  • lots of sites to look at shape of network
    • atlas.torproject.org has good statistics
    • torstatus.__(?)