Για αρκετά χρόνια τώρα, χαίρομαι να τρέχω και να συντηρώ τουλάχιστον δύο Tor relays: ένα Bridge κι ένα Guard/Middle relay. Παραδοσιακά, τα relays τα είχα σε Linux servers. Στην προσπάθειά μου όμως να συμβάλλω στην ποικιλομορφία του Tor network, τα relays πλέον τα έχω σε OpenBSD servers.

Στο community site του Tor project υπάρχει άριστη τεκμηρίωση για την εγκατάσταση και τη ρύθμιση όλων των ειδών relays, σε διάφορα λειτουργικά συστήματα, του OpenBSD συμπεριλαμβανομένου.

Προσωπικά, με βολεύει να έχω συγκεντρωμένες και ορισμένες σημειώσεις για τη ρύθμιση και την ορθή λειτουργία Bridge/Guard/Middle relay σε OpenBSD. Αν σχεδιάζετε να συνεισφέρετε στο δίκτυο ανωνυμίας του Tor, ίσως βρείτε τις σημειώσεις αυτές χρήσιμες.

Bridge relay

Μετά την προσθήκη του πακέτου με τον Tor daemon, για το Bridge relay δεν αγγίζω καν το προκαθορισμένο αρχείο ρυθμίσεων (/etc/tor/torrc). Αντίθετα, δημιουργώ το νέο αρχείο /etc/tor/torrc_relayname, με περιεχόμενο που μοιάζει με το ακόλουθο:

RunAsDaemon 1
User _tor

SocksPort 0
BridgeRelay 1

ORPort THE_OR_PORT
ExtORPort auto

Nickname relayname
ContactInfo someone@alias.email

ServerTransportPlugin obfs4 exec /usr/local/bin/lyrebird
ServerTransportListenAddr obfs4 0.0.0.0:THE_STL_PORT

DataDirectory /var/tor/relayname
Log notice file /var/log/tor/relayname.log

• Το ORPort καλό είναι να μην έχει την προκαθορισμένη τιμή, που είναι η 9001. Αυτή είναι συσχετισμένη με το Tor project, έτσι servers με το port 9001 ανοικτό συχνά καταλήγουν σε block lists.

• Το ExtORPort χρησιμεύει για την τοπική επικοινωνία μεταξύ Tor daemon και obfuscator (το Ext είναι από το “Extended”, όχι από το “External”). Το ExtORPort πάντα είναι auto.

• Το port για το ServerTransportListenAddr πρέπει να ‘ναι διαφορετικό από το ORPort και να μην είναι το 9001.

• Ο σύγχρονος obfuscator για ένα Tor bridge είναι πλέον το lyrebird (fork του obfs4proxy). Στο OpenBSD 7.9, το lyrebird παρέχεται από το ομώνυμο (ενημερωμένο) πακέτο.

• Τα THE_OR_PORT και THE_STL_PORT πρέπει να ‘ναι προσβάσιμα από το internet.

• Το relayname δεν είναι κρίσιμο για την προστασία της ανωνυμίας του Bridge operator. Εμφανίζεται ωστόσο σε δημόσια προσβάσιμες υπηρεσίες, όπως αυτή του Tor Metrics. Κάποιος, ίσως θα μπορούσε να το συσχετίσει με την αληθινή ταυτότητα του operator.

• Τον κατάλογο /var/log/tor, με ιδιοκτησιακό καθεστώς _tor:wheel, τον δημιουργώ χειροκίνητα.

• Η παρουσία της διεύθυνσης email someone@alias.email είναι προαιρετική, για την περίπτωση που κάποιος από το Tor project χρειαστεί να επικοινωνήσει με τον operator του Bridge relay. Η διεύθυνση αυτή προτείνεται να είναι κάποιο alias.

Guard/Middle relay

Όπως και με την περίπτωση του Bridge relay, έτσι και για το Guard/Middle relay δεν αγγίζω το προκαθορισμένο αρχείο ρυθμίσεων του Tor daemon (/etc/tor/torrc). Αντίθετα, δημιουργώ δίπλα του το αρχείο /etc/tor/torrc_relayname, με περιεχόμενο όπως το ακόλουθο:

RunAsDaemon 1
User _tor

SocksPort 0
ExitRelay 0

ORPort THE_OR_PORT IPv4Only

Nickname relayname
ContactInfo someone@alias.email

DataDirectory /var/tor/relayname
Log notice file /var/log/tor/relayname.log

• Η προκαθορισμένη τιμή για το ORPort είναι η 443. Δεν υπάρχει λόγος για χρήση κάποιου άλλου port.

• Το THE_OR_PORT πρέπει να είναι προσβάσιμο από το internet.

• Η οδηγία IPv4Only είναι προαιρετική. Σε servers χωρίς δημόσια διεύθυνση IPv6, φροντίζω να την προσθέτω. Διαφορετικά, το log file του relay daemon (/var/log/tor/relayname.log) γεμίζει με μηνύματα σαν αυτό: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address.

• Το relayname δεν είναι κρίσιμο για την προστασία της ανωνυμίας του Guard/Middle operator. Εμφανίζεται ωστόσο σε δημόσια προσβάσιμες υπηρεσίες, όπως αυτή του Tor Metrics. Κάποιος, ίσως θα μπορούσε να το συσχετίσει με την αληθινή ταυτότητα του operator.

• Τον κατάλογο /var/log/tor, με ιδιοκτησιακό καθεστώς _tor:wheel, τον δημιουργώ χειροκίνητα.

• Η παρουσία της διεύθυνσης email someone@alias.email είναι προαιρετική, για την περίπτωση που κάποιος από το Tor project χρειαστεί να επικοινωνήσει με τον operator του Bridge relay. Η διεύθυνση αυτή προτείνεται να είναι κάποιο alias.

File descriptors

Για λόγους ασφαλείας, το OpenBSD έχει ένα σχετικά χαμηλό άνω όριο για το πλήθος των file descriptors, τα οποία μια οποιαδήποτε διεργασία επιτρέπεται να έχει ανοικτά. Βέβαια το συγκεκριμένο άνω όριο είναι δυνατόν ν’ αλλάξει. Και για ένα Tor relay, το οποίο ανοίγει συνδέσεις με κάθε άλλο Tor relay, το όριο αυτό πρέπει ν’ αλλάξει.

Η αλλαγή επιτυγχάνεται με την προσθήκη μιας νέας κλάσης login στο αρχείο /etc/login.conf, η οποία στο ακόλουθο παράδειγμα ονομάζεται tor:

tor:\
	:openfiles-max=32768:\
	:tc=daemon:

Για τις διεργασίες της κλάσης tor, λοιπόν, το άνω όριο καθορίζεται από την παράμετρο openfiles-max και είναι 32768.

Μέτρο σύγκρισης: για τις διεργασίες της κλάσης default, η παράμετρος openfiles-max είναι 1024.

Μετά τις προσθήκες στο /etc/login.conf, λοιπόν, εντάσσω τον (προϋπάρχοντα) χρήστη _tor στην κλάση tor:

# doas usermod -L tor _tor

Μετά από οποιαδήποτε αλλαγή στο /etc/login.conf, προτείνεται να διατηρείται ενήμερη η εκδοχή DB των περιεχομένων του αρχείου:

# doas cap_mkdb /etc/login.conf

Υπάρχει κι ένα διαφορετικό άνω όριο για τον αριθμό των ανοικτών file descriptors, το οποίο αφορά σε όλες τις διεργασίες του συστήματος αθροιστικά. Πρόκειται για την παράμετρο kern.maxfiles, η οποία ορίζεται στο αρχείο /etc/sysctl.conf:

kern.maxfiles=49152

Μέτρο σύγκρισης: σε μια νέα εγκατάσταση του OpenBSD, η παράμετρος kern.maxfiles είναι 7030.

Προκειμένου να ληφθεί άμεσα υπόψη η νέα τιμή της kern.maxfiles χωρίς επανεκκίνηση του συστήματος, πληκτρολογώ:

# doas sysctl kern.maxfiles=49152
kern.maxfiles: 7030 -> 49152

Firewalling

Αρκετοί cloud providers παρέχουν εργαλεία για την εύκολη και γρήγορη δημιουργία cloud firewalls, τα οποία μπαίνουν μπροστά από έναν ή περισσότερους servers.

Πρόκειται, ομολογουμένως, για τεράστια ευκολία. Όμως ειδικά για OpenBSD servers τείνω να μην ασχολούμαι καν με cloud firewall, και προτιμώ να στρέφομαι στο PF firewall του OpenBSD.

Παραθέτω το /etc/pf.conf από έναν OpenBSD server με Bridge relay…

set skip on lo
set block-policy drop

block all

pass out all keep state

pass in on vio0 proto tcp to port 22 keep state
pass in on vio0 proto tcp to port 40443 keep state
pass in on vio0 proto tcp to port 49001 keep state

…καθώς και το (απλούστερο) /etc/pf.conf από έναν OpenBSD server με Guard/Middle relay:

set skip on lo
set block-policy drop

block all

pass out all keep state

pass in on vio0 proto tcp to port 22 keep state
pass in on vio0 proto tcp to port 443 keep state

Αρχείο εκκίνησης

Αφού δεν πειράζω το προκαθορισμένο αρχείο ρυθμίσεων του Tor daemon, κι αντίθετα φτιάχνω το /etc/tor/torrc_relayname, έτσι φτιάχνω και το νέο script εκκίνησης, το /etc/rc.d/tor_relayname, για τον νέο Bridge/Guard/Middle relay daemon:

#!/bin/ksh

daemon="/usr/local/bin/tor -f /etc/tor/torrc_relayname"
daemon_timeout=60

. /etc/rc.d/rc.subr

rc_stop_signal=INT

rc_configtest() {
  ${daemon} ${daemon_flags} --verify-config
}

rc_cmd $1

Το /etc/rc.d/tor_relayname είναι σχεδόν ίδιο με το προϋπάρχον /etc/rc.d/tor: η μόνη τους διαφορά είναι ότι, στο πρώτο, ο relay daemon καλείται λαμβάνοντας υπόψη το /etc/tor/torrc_relayname.

Κατά τα άλλα, ενεργοποιώ τον relay daemon πληκτρολογώντας rcctl enable tor_relayname, ενώ τον ξεκινώ με rcctl start tor_relayname.

Μετακομίσεις

Όταν για οποιονδήποτε λόγο χρειάζεται να μετακομίσω ένα Tor relay σε νέο cloud server, η ταυτότητα του relay θέλω να διατηρείται.

Για το σκοπό αυτό, μεταφέρω στον νέο server τον υποκατάλογο DataDirectory/keys του παλιού server. Ειδικά για την περίπτωση Bridge relay, μεταφέρω στον νέο server και τον υποκατάλογο DataDirectory/pt_state.

Γενικά, είναι πολύ πιο εύκολο να μεταφέρω όλο το περιεχόμενο από το DataDirectory του παλιού server, στο DataDirectory του νέου server. Το ιδιοκτησιακό καθεστώς των αρχείων και υποκαταλόγων του DataDirectory είναι _tor:_tor.