nusenu.relayor

ansible-relayor

Dies ist eine Ansible-Rolle für Tor-Relay-Betreiber. Eine Einführung in relayor finden Sie hier.

E-Mail-Support: relayor-support AT riseup.net

Der Hauptfokus dieser Rolle liegt darauf, so viele Schritte wie möglich für einen Tor-Relay-Betreiber zu automatisieren, einschließlich Schlüsselverwaltung (OfflineMasterKey). Das Bereitstellen eines neuen Tor-Servers ist so einfach wie das Hinzufügen eines neuen Hosts zum Inventar; keine weitere manuelle Konfiguration ist erforderlich.

Diese Rolle verwaltet nur Tor-Instanzen entsprechend den aktuellen Einstellungen und Variablen. Wenn Sie nach einem vollständigen Playbook-Durchlauf die Konfiguration ändern, um die Anzahl der Tor-Instanzen zu reduzieren, zum Beispiel durch Reduzierung des Werts von tor_maxPublicIPs, wird diese Rolle die zuvor konfigurierten Tor-Instanzen nicht von Ihrem Server entfernen. Tor-Instanzen auf einem Server werden durch die Kombination ihrer IPv4- und ORPort-Nummer identifiziert. Ändern Sie den ORPort (mit der Variable tor_ports) nach der ursprünglichen Bereitstellung, bedeutet dies im Wesentlichen, neue Tor-Instanzen zu erstellen (nicht sie zu ändern). Deshalb sollte das Ändern der tor_ports-Variable nach der ursprünglichen Bereitstellung vermieden werden.

Das Aktualisieren des Tor-Pakets (eine wichtige Aufgabe beim Betrieb eines Relays) gehört nicht zum Scope dieser Ansible-Rolle. Wir empfehlen Ihnen, automatische Updates zu aktivieren, um Ihr Relay gut gewartet zu halten, falls Ihr Betriebssystem dies unterstützt. Der Tor-Relay-Leitfaden enthält Anweisungen, wie automatische Software-Updates für Debian/Ubuntu und FreeBSD aktiviert werden können.

Diese Ansible-Rolle zielt nicht darauf ab, Tor-Brücken zu unterstützen.

Hauptvorteile für einen Tor-Relay-Betreiber

• Automatisierung - keine manuellen Setup-Aufgaben mehr
• Sicherheit: Offline Ed25519 Master-Schlüssel werden auf dem Ansible-Host generiert und sind niemals dem Relay ausgesetzt
• Einfache Erneuerung von Ed25519-Signierungsschlüsseln (standardmäßig 30 Tage gültig - konfigurierbar)
• Sicherheit: Abgrenzung: jede Tor-Instanz wird mit einem eigenen Benutzer ausgeführt
• Nutzt automatisch IPv6-IP-Adressen (wenn verfügbar)
• Automatische Generierung von Tor-Instanzen (standardmäßig zwei - konfigurierbar)
• Aktiviert standardmäßig die Sandbox-Funktion von Tor auf Debian-basierten Systemen
• Einfach zwischen Alpha/Nicht-alpha-Versionen wählen (nur Debian/Ubuntu/FreeBSD)
• Einfaches Wiederherstellen einer Relay-Konfiguration (der Ansible-Host wird sofort zu einem Backup-Standort für alle Schlüssel)
• Einfach zwischen Exit-Relay/Nicht-Exit-Relay-Modus wechseln mit einem einzigen booleschen Wert
• Automatische Bereitstellung einer HTML-Seite zur Exit-Benachrichtigung über Tors DirPort (nur bei Exits)
• Automatische Verwaltung von MyFamily
• Prometheus-Integration (bei Aktivierung)
  • Automatische Generierung der Nginx-Proxy-Konfiguration zum Schutz von Tors MetricsPort (hinter Basis-Authentifizierung / HTTPS)
  • Automatische Generierung der Prometheus-Scrape-Konfiguration für MetricsPort
  • Automatische Generierung der Scrape-Konfiguration für den Blackbox-Exporter zur Überwachung der Erreichbarkeit von ORPorts und DirPorts
  • Bereitstellung von Prometheus-Alarmregeln für Tor

Installation

Diese Ansible-Rolle ist auf Galaxy verfügbar: https://galaxy.ansible.com/nusenu/relayor/

ansible-galaxy install nusenu.relayor

Anforderungen

Anforderungen an die Steuerungsmaschine

• Führen Sie diese Rolle nicht mit become: yes aus
• Tor >= 0.4.8
• Python-Netaddr-Paket muss installiert sein
• erforderliche Befehle: sort, uniq, wc, cut, sed, xargs
• OpenSSL >= 1.0.0
• Ansible >= 2.16.4
• Bash unter /bin/bash

Anforderungen an verwaltete Knoten

• Ein Nicht-Root-Benutzer mit Sudo-Rechten
• Python
• Statische IPv4-Adresse(n)
  • wir können mehrere öffentliche IPs verwenden
  • wenn Sie keine öffentliche IP haben, verwenden wir eine private IP (und gehen von NAT aus)
• systemd (alle Linux-basierten Systeme)

Anforderungen an den Prometheus-Server (nur wenn Sie die Prometheus-Funktionen dieser Rolle nutzen)

• promtool muss auf dem Prometheus-Server installiert und im PATH des Root-Benutzers vorhanden sein

Unterstützte Betriebssysteme

• Debian 12
• OpenBSD 7.4
• FreeBSD 14.1
• Ubuntu 22.04

Unterstützte Tor-Versionen

• Tor >= 0.4.8.x

Beispiel-Playbook

Ein minimales Playbook, das ansible-relayor verwendet, um Nicht-Exit-Relays einzurichten, könnte so aussehen:

---

- hosts: relays
  vars:
    tor_ContactInfo: [email protected]
  roles:
    - nusenu.relayor

Weitere Beispiele finden Sie im Verzeichnis playbook-examples.

Geänderte Torrc-Standardeinstellungen

Diese Rolle ändert die Standardwerte der folgenden torrc-Optionen, um standardmäßig sicherere Optionen zu verwenden, kann jedoch weiterhin ausdrücklich über tor_config konfiguriert werden:

• NoExec 0 -> 1
• Sandbox 0 -> 1 (nur auf Debian)

Rollenvariablen

Alle hier genannten Variablen sind optional.

• tor_ContactInfo Zeichenfolge

  • Legt das Kontaktinfo-Feld des Relays fest.
  • Diese Einstellung ist obligatorisch.
  • Betreiber werden ermutigt, die Spezifikation für das Teilen von Kontaktinformationen zu verwenden, um nützliche Kontaktinformationen zu veröffentlichen.

• tor_signingkeylifetime_days ganze Zahl

  • Alle von relayor erstellten Tor-Instanzen laufen im OfflineMasterKey-Modus
  • Diese Einstellung definiert die Lebensdauer von Ed25519-Signierungsschlüsseln in Tagen
  • Indirekt definiert wie oft Sie Ihr Ansible-Playbook ausführen müssen, um sicherzustellen, dass Ihre Relay-Schlüssel nicht ablaufen
  • Eine Tor-Instanz im OfflineMasterKey-Modus wird automatisch gestoppt, wenn sein Schlüssel/Zertifikat abläuft, daher ist dies eine entscheidende Einstellung!
  • Niedrigere Werte (z. B. 7) sind aus Sicherheitsgründen besser, erfordern jedoch häufigere Playbook-Durchläufe
  • Standard: 30

• tor_config Dictionary

  • Dieses Dictionary enthält torrc-Einstellungen und deren Werte. Für verfügbare Optionen siehe den Abschnitt 'SERVER OPTIONEN' im Handbuch von Tor.
  • Jede Einstellung kann nur einmal gesetzt werden (unabhängig davon, was in der man-Seite von Tor angegeben ist)
  • Dieses Dictionary kann verwendet werden, um beliebige torrc-Optionen festzulegen, jedoch NICHT die folgenden: OfflineMasterKey, RunAsDaemon, Log, SocksPort, OutboundBindAddress, User, DataDirectory, ORPort, OutboundBindAddress, DirPort, SyslogIdentityTag, PidFile, MetricsPort, MetricsPortPolicy, ControlSocket, CookieAuthentication, Nickname, ExitRelay, IPv6Exit, ExitPolicy, RelayBandwidthRate, RelayBandwidthBurst, SigningKeyLifetime

• tor_ports Dictionary

  • Diese Variable ermöglicht es Ihnen,
    • Tor's ORPort und DirPort auszuwählen
    • zu entscheiden, wie viele Tor-Instanzen Sie pro IP-Adresse ausführen möchten (standardmäßig 2) - stellen Sie sicher, dass Sie nicht mehr ausführen, als pro IP-Adresse erlaubt sind
  • Deaktivieren Sie DirPorts, indem Sie sie auf 0 setzen
  • HINWEIS: Wählen Sie ORPorts weise und ändern Sie sie niemals wieder, zumindest nicht die bereits bereitgestellten. Das Hinzufügen weiterer ohne Änderungen an bereits Bereitgestellten ist in Ordnung.
  • Tors 'Auto'-Funktion wird NICHT unterstützt.
  • Standard:
    • Instanz 1: ORPort 9000, DirPort 9001
    • Instanz 2: ORPort 9100, DirPort 9101

• tor_offline_masterkey_dir Ordnerpfad

  • Standard: ~/.tor/offlinemasterkeys
  • Legt den Speicherort fest, an dem auf der Ansible-Steuerungsmaschine Relay-Schlüssel (Ed25519 und RSA) gespeichert werden.
  • Innerhalb dieses Ordners erstellt Ansible einen Unterordner für jede Tor-Instanz.
  • Siehe die Dokumentation, wenn Sie Instanzen auf einen neuen Server migrieren möchten.
  • Hinweis: Fummeln Sie nicht manuell an Dateinamen/Inhalten in diesen Tor DataDirs herum.

• tor_nickname Zeichenfolge

  • Definiert den Nickname, den Tor-Instanzen verwenden werden
  • Alle Tor-Instanzen auf einem Host erhalten den gleichen Nickname
  • Um den Hostnamen als Nickname zu verwenden, setzen Sie ihn auf {{ ansible_hostname }}
  • Nicht-alphanumerische Zeichen werden automatisch entfernt und Nicknames, die länger als 19 Zeichen sind, werden gekürzt, um den Anforderungen an Tors Nicknamen gerecht zu werden
  • tor_nicknamefile überschreibt diese Einstellung
  • Standard: keiner

• tor_nicknamefile Dateipfad

  • Dies ist eine einfache, durch Kommas getrennte CSV-Datei, die auf der Ansible-Steuerungsmaschine gespeichert ist und Nicknames angibt
  • Erste Spalte: Instanz-Identifikator (inventory_hostname-ip_orport)
  • Zweite Spalte: Nickname
  • Eine Instanz pro Zeile
  • Alle Instanzen MÜSSEN in der CSV-Datei enthalten sein
  • Nicht-alphanumerische Zeichen werden automatisch entfernt und Nicknames, die länger als 19 Zeichen sind, werden gekürzt, um den Anforderungen an Tors Nicknamen gerecht zu werden
  • Standard: nicht gesetzt

• tor_gen_ciiss_proof_files boolean

  • Generieren Sie die rsa-fingerprint.txt und ed25519-master-pubkey.txt Nachweisdateien auf der Steuerungsmaschine zur Veröffentlichung gemäß der Kontaktinfo-Spezifikation
  • Standardpfade sind: ~/.tor/rsa-fingerprint.txt und ~/.tor/ed25519-master-pubkey.txt
  • Die Dateien werden überschrieben, wenn sie existieren
  • Der Standort des Ausgabeverzeichnisses kann mit der Variable tor_ciiss_proof_folder konfiguriert werden
  • Der Dateiname ist fest codiert auf den in der Spezifikation erforderlichen und kann nicht konfiguriert werden
  • Standard: Falsch

• tor_ciiss_proof_folder Ordnerpfad

  • Legt den Ausgabeordner für generierte Nachweisdateien fest
  • Standard: ~/.tor

• tor_LogLevel Zeichenfolge

  • Legt Tors LogLevel fest
  • Standard: notice

• tor_alpha boolean

  • Auf True setzen, wenn Sie Tor Alpha-Versionen verwenden möchten.
  • Hinweis: Diese Einstellung gewährleistet nicht, dass eine installierte Tor-Version auf die Alpha-Version aktualisiert wird.
  • Diese Einstellung wird nur auf Debian/Ubuntu/FreeBSD unterstützt (auf anderen Plattformen ignoriert).
  • Standard: Falsch

• tor_nightly_builds boolean

  • Auf True setzen, wenn Sie das Nightly-Build-Repo von deb.torproject.org verwenden möchten.
  • Nightly Builds folgen dem Haupt-Branch von Tor.
  • Nur auf Debian und Ubuntu unterstützt (auf anderen Plattformen ignoriert).
  • Standard: Falsch

• tor_ExitRelay boolean

  • Sie müssen dies auf True setzen, wenn Sie das Verlassen für alle oder einige Tor-Instanzen auf einem Server aktivieren möchten.
  • Wenn diese Variable nicht wahr ist, wird dies ein Non-Exit-Relay sein.
  • Wenn Sie einen gemischten Server (Exit- und Non-Exit-Tor-Instanzen) betreiben möchten, verwenden Sie tor_ExitRelaySetting_file zur per-Instanz-Konfiguration zusätzlich zu dieser Variablen.
  • Standard: Falsch

• tor_ExitRelaySetting_file Dateipfad

  • Dies ist eine einfache, durch Kommas getrennte CSV-Datei, die auf der Ansible-Steuerungsmaschine gespeichert ist und das ExitRelay torrc-Setting für jede Tor-Instanz definiert (statt serverweit)
  • Erste Spalte: Instanz-Identifikator (inventory_hostname-ip_orport)
  • Zweite Spalte: "exit" für Exit-Tor-Instanzen, jeder andere Wert (einschließlich leer) für Non-Exit-Tor-Instanzen
  • Diese Variable wird ignoriert, wenn tor_ExitRelay falsch ist.

• tor_RelayBandwidthRate_file Dateipfad

  • Dies ist eine einfache, durch Kommas getrennte CSV-Datei, die auf der Ansible-Steuerungsmaschine gespeichert ist und das RelayBandwidthRate torrc-Setting für jede Tor-Instanz definiert (statt serverweit)
  • Erste Spalte: Instanz-Identifikator (inventory_hostname-ip_orport)
  • Zweite Spalte: Wert wie von RelayBandwidthRate akzeptiert (siehe tor manpage)

• tor_RelayBandwidthBurst_file Dateipfad

  • Dies ist eine einfache, durch Kommas getrennte CSV-Datei, die auf der Ansible-Steuerungsmaschine gespeichert ist und das RelayBandwidthBurst torrc-Setting für jede Tor-Instanz definiert (statt serverweit)
  • Erste Spalte: Instanz-Identifikator (inventory_hostname-ip_orport)
  • Zweite Spalte: Wert wie von RelayBandwidthBurst akzeptiert (siehe tor manpage)

• tor_ExitNoticePage boolean

  • Gibt an, ob wir die standardmäßige Tor-Exit-Benachrichtigung HTML-Seite auf dem DirPort anzeigen
  • Nur relevant, wenn wir ein Exit-Relay sind
  • Standard: Wahr

• tor_exit_notice_file Dateipfad

  • Pfad zu einer HTML-Datei auf der Steuerungsmaschine, die Sie anstelle der standardmäßigen tor-exit-notice.html anzeigen möchten, die vom Tor-Projekt bereitgestellt wird
  • Nur relevant, wenn wir ein Exit-Relay sind und wenn tor_ExitNoticePage wahr ist.

• tor_AbuseEmailAddress E-Mail-Adresse

  • Wenn gesetzt, wird diese E-Mail-Adresse auf der Tor-Exit-Benachrichtigung HTML-Seite veröffentlicht, die auf dem DirPort veröffentlich wird.
  • Es wird empfohlen, dies festzulegen, wenn Sie einen Exit betreiben.
  • Nur relevant, wenn wir ein Exit-Relay sind.
  • Hinweis: Wenn Sie Ihre eigene benutzerdefinierte Tor-Exit-Benachrichtigungsvorlage verwenden, wird diese Variable ignoriert, wenn Sie sie nicht in Ihre Vorlage aufnehmen.
  • Standard: nicht gesetzt.

• tor_ExitPolicy Array

  • Geben Sie Ihre benutzerdefinierte Exit-Richtlinie an.
  • Nur relevant, wenn tor_ExitRelay wahr ist.
  • Siehe defaults/main.yml für ein Beispiel, wie man es festlegt.
  • Standard: reduzierte Exit-Policy (https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy)

• tor_ExitPolicy_file Dateipfad

  • Dies ist eine einfache, durch Semikolons getrennte CSV-Datei, die auf der Ansible-Steuerungsmaschine gespeichert ist und das ExitPolicy torrc-Setting für jede Tor-Instanz definiert (statt serverweit)
  • Erste Spalte: Instanz-Identifikator (inventory_hostname-ip_orport)
  • Zweite Spalte: Wert wie von ExitPolicy akzeptiert (siehe tor manpage)
  • Beispielinhalt: "myrelay-192.168.1.1_443;reject *:25,reject *:123"
  • Nur relevant, wenn tor_ExitRelay wahr ist.
  • Dies kann mit der Einstellung tor_ExitPolicy kombiniert werden und wird sie überschreiben (diese ist spezifischer).
  • Nur Tor-Instanzen, für die Sie eine bestimmte Exit-Richtlinie festlegen möchten, sind erforderlich. (andere können weggelassen werden)
  • Standard: nicht gesetzt.

• tor_maxPublicIPs ganze Zahl

  • Begrenzung der Anzahl öffentlicher IPs, die wir verwenden werden, um Instanzen auf einem einzelnen Host zu generieren.
  • Indirekt wird die Anzahl der Instanzen, die wir pro Host generieren, begrenzt.
  • Standard: 1

• tor_IPv6 boolean

  • Erkennt automatisch, ob Sie IPv6-IP-Adressen haben, und aktiviert entsprechend einen IPv6 ORPort.
  • Sie können sich abmelden, indem Sie es auf falsch setzen.
  • Standard: Wahr

• tor_IPv6Exit boolean

  • Aktiviert IPv6-Ausgangsverkehr
  • Nur relevant, wenn tor_ExitRelay und tor_IPv6 wahr sind und wir eine IPv6-Adresse haben
  • Standard: Wahr (im Gegensatz zu Tors Standard)

• tor_enableMetricsPort boolean

  • Wenn wahr, aktivieren Sie Tors MetricsPort auf der localhost-IP-Adresse 127.0.0.1 und erlauben Sie derselben IP den Zugriff darauf (MetricsPortPolicy).
  • Dies ist eine Relayor-Beta-Funktion und wird in Zukunft geändert, um die sicherere Unix-Socket-Option zu verwenden, sobald diese verfügbar ist.
  • Das Aktivieren dieser Einstellung deaktiviert automatisch OverloadStatistics, wenn dies nicht ausdrücklich aktiviert ist (damit Tor die Daten nicht an die Verzeichnisbehörden veröffentlicht, da wir MetricsPort lokal verwenden).
  • Standard: Falsch

• tor_prometheus_host Hostname

  • Diese Variable ist nur relevant, wenn tor_enableMetricsPort oder tor_blackbox_exporter_host eingestellt ist.
  • Wenn Sie die Prometheus-Integration von relayor aktivieren möchten, müssen Sie diese Variable auf Ihren Prometheus-Host setzen.
  • Sie definiert, auf welchem Host Ansible die Konfiguration für das Scrapen von Tors MetricsPort generieren sollte.
  • Dieser Host muss in der Ansible-Inventardatei verfügbar sein.
  • Standard: undefiniert (keine Scrape-Config wird generiert)

• tor_prometheus_confd_folder Ordnerpfad

  • Nur relevant, wenn Sie Prometheus verwenden möchten.
  • Dieser Ordner muss auf dem tor_prometheus_host existieren.
  • Relayor platziert Prometheus-Scrape-Konfigurationen in diesem Ordner.
  • Der Abschnitt zur globalen Konfiguration von Prometheus muss in diesem Ordner unter dem Namen 1_prometheus.yml vorhanden sein.
  • Wir fügen alle Dateien in diesem Ordner in lexikographischer Reihenfolge zu einer einzigen prometheus.yml-Ausgabedatei zusammen, da Prometheus im Standard nicht conf.d-Stil-Ordner unterstützt.
  • Standard: /etc/prometheus/conf.d

• tor_prometheus_config_file Dateipfad

  • Nur relevant, wenn Sie Prometheus verwenden möchten.
  • Diese Variable definiert den Pfad der globalen Konfigurationsdatei von Prometheus auf dem tor_prometheus_host.
  • Wir sichern die Datei im selben Ordner, bevor wir eine neue generieren.
  • Diese Datei enthält sensible Daten, da sie Anmeldeinformationen für Tors MetricsPort enthält.
  • Dateibesitzer: root, Gruppe: tor_prometheus_group, Berechtigungen: 0640
  • Standard: /etc/prometheus/prometheus.yml

• tor_MetricsPort_offset ganze Zahl

  • Definiert den TCP MetricsPort, der für die erste auf einem Host ausgeführte Tor-Instanz verwendet wird.
  • Zusätzliche Tor-Instanzen verwenden eine fortlaufende Portnummer 33301, 33302...
  • Wenn Sie N-Instanzen auf einem Host ausführen, müssen die nächsten N-1 Ports nach diesem Port auf 127.0.0.1 unbenutzt sein, damit Tor sie für MetricsPort verwenden kann.
  • Standard: 33300

• tor_prometheus_scrape_file Dateiname

  • Nur relevant, wenn tor_prometheus_host definiert ist und tor_enableMetricsPort oder tor_blackbox_exporter_host festgelegt ist.
  • Definiert den Dateinamen für die per-Server scrape_config-Dateien auf dem Prometheus-Server im Ordner tor_prometheus_confd_folder.
  • Der Dateiname MUSS host-spezifisch sein; jeder Host hat seine eigene Scrape-Config-Datei auf dem Prometheus-Server, um die CLI-Option --limit des Ansible-Playbooks zu unterstützen.
  • Je nach tor_enableMetricsPort und tor_blackbox_exporter_host enthalten die Scrape-Config-Dateien Scrape-Jobs für den Tor MetricsPort (hinter einem Reverse-Proxy für TLS/Basis-Authentifizierung) und/oder Scrape-Jobs für ORPort/DirPort-TCP-Proben über den Blackbox-Exporter.
  • Der Dateiinhalt ist sensibel (enthält Scrape-Anmeldeinformationen) und erhält diese Dateiberechtigungen: 0640 (Eigentümer: root, Gruppe: tor_prometheus_group).
  • Die generierten Scrape-Config-Dateien werden automatisch mit einigen nützlichen Prometheus-Labels erstellt, abhängig von Ihren torrc-Einstellungen; siehe den Abschnitt „Prometheus-Labels“ in diesem README.
  • Standard: tor_{{ ansible_fqdn }}.yml

• tor_prometheus_group Zeichenfolge

  • Nur relevant, wenn Sie Prometheus verwenden möchten.
  • Definiert den Gruppennamen, der für Prometheus-Dateiberechtigungen verwendet wird (prometheus.yml, Scrape-Config-Dateien, Regeldatei für Alarme).
  • Standard: prometheus

• tor_prom_labels Dictionary

  • Beliebige Anzahl von Prometheus-Label-Wert-Paaren
  • Kann auf Serverebene, nicht auf Instanzebene festgelegt werden
  • Für ein Beispiel siehe defaults/main.yml
  • Standard: leeres Dictionary

• tor_blackbox_exporter_host hostname:port

  • Wenn gesetzt, fügt relayor die notwendige Prometheus-Scrape-Config für Blackbox-Exporter-TCP-Überprüfungen in die Datei ein, die durch tor_prometheus_scrape_file definiert wird.
  • Überwacht alle Relay-ORPorts und, wenn eingestellt, DirPorts über IPv4 und IPv6 (wenn aktiviert) mit einer TCP-Verbindungsprüfung.
  • Diese Funktion wird nicht auf Relays hinter NAT unterstützt.
  • Definiert, wo Prometheus den Blackbox-Exporter findet. Er kann auch auf dem Prometheus-Server selbst betrieben werden, in diesem Fall wäre es 127.0.0.1:9115.
  • Der Host wird in der resultierenden Prometheus-Scrape-Config aufgeführt.
  • Blackbox-Exporter muss ein einfaches tcp_probe-Modul namens "tcp_connect" konfiguriert haben.
  • Relayor installiert oder konfiguriert den Blackbox-Exporter nicht.
  • Standard: undefiniert.

• tor_blackbox_exporter_scheme Zeichenfolge

  • Definiert das Protokoll, das Prometheus zum Verbinden mit dem Blackbox-Exporter verwendet (http oder https).
  • Standard: http

• tor_blackbox_exporter_username Zeichenfolge

  • Nur relevant, wenn tor_blackbox_exporter_host festgelegt ist.
  • Ermöglicht es Ihnen, den Benutzernamen zu definieren, wenn Ihr Blackbox-Exporter eine HTTP-Basis-Authentifizierung erfordert.
  • Wenn Sie keinen Benutzernamen angeben, werden die Scrape-Config keine HTTP-Basis-Authentifizierungsanmeldeinformationen enthalten.
  • Standard: undefiniert (keine HTTP-Basis-Authentifizierung)

• tor_blackbox_exporter_password Zeichenfolge

  • Nur relevant, wenn tor_blackbox_exporter_host festgelegt ist.
  • Ermöglicht es Ihnen, den Benutzernamen zu definieren, wenn Ihr Blackbox-Exporter eine HTTP-Basis-Authentifizierung erfordert.
  • Der Standard generiert eine 20 Zeichen lange Zufallszeichenfolge mit dem Ansible-Passwort-Lookup.
  • Standard: "{{ lookup('password', '~/.tor/prometheus/blackbox_exporter_password') }}"

• tor_metricsport_nginx_config_file Dateipfad

  • Diese Variable ist nur relevant, wenn tor_enableMetricsPort wahr ist und tor_prometheus_host festgelegt ist.
  • Sie definiert den Dateipfad, in dem die Nginx-Proxy-Konfiguration für MetricsPort auf dem Relay gespeichert wird.
  • Diese Datei muss in Ihrer Webserver-Konfiguration auf dem Relay enthalten sein, damit MetricsPort für remote Prometheus-Scraping zugänglich ist.
  • Der Ordner muss bereits auf dem Server vorhanden sein (relayor erstellt ihn nicht).
  • Standard: /etc/nginx/promexporters/tor_metricsports_relayor.conf

• tor_gen_prometheus_alert_rules boolean

  • Nur relevant, wenn tor_enableMetricsPort aktiviert ist.
  • Auf True setzen, wenn Sie Prometheus-Alarmregeln auf dem Prometheus-Server (tor_prometheus_host) generieren möchten.
  • Der Speicherort der Datei wird durch tor_prometheus_rules_file definiert.
  • Standard: falsch (es werden keine Regeln generiert).

• tor_prometheus_rules_file Dateipfad

  • Nur relevant, wenn tor_gen_prometheus_alert_rules True ist.
  • Definiert, wo auf dem Prometheus-Server (tor_prometheus_host) relayor die Regeln-Datei generiert (der Ordner muss vorhanden sein).
  • Die Datei muss sich im Ordner befinden, der in Ihrer Prometheus-Konfiguration (rule_files) enthalten ist, und muss normalerweise mit .rules enden.
  • Relayor liefert ein Standardset von Alarmregeln und Sie können zusätzlich Ihre eigenen Alarmregeln hinzufügen (über tor_prometheus_custom_alert_rules).
  • Dateibesitzer/gruppe: root, Dateiberechtigungen: 0644
  • Standard: /etc/prometheus/rules/ansible-relayor.rules

• tor_prometheus_alert_rules Dictionary

  • Definiert die Prometheus-Alarmregeln.
  • Regeln werden automatisch mit promtool validiert.
  • Siehe defaults/main.yml für die Standardregeln.

• tor_prometheus_custom_alert_rules Dictionary

  • Wenn Sie Ihre benutzerdefinierten Regeln hinzufügen möchten, fügen Sie sie zu diesem Dictionary hinzu. Es erwartet das gleiche Format wie tor_prometheus_alert_rules.
  • In diesem Dictionary definierte Regeln werden ebenfalls in tor_prometheus_rules_file geschrieben.
  • Dies ermöglicht es Ihnen, neue Regeln, die von neuen Relayor-Versionen geliefert werden, zu verwenden und gleichzeitig Ihre benutzerdefinierten Regeln zu behalten.
  • Regeln werden automatisch mit promtool validiert.
  • Standard: undefiniert.

• tor_gen_metricsport_htpasswd boolean

  • Diese Variable ist nur relevant, wenn tor_enableMetricsPort wahr ist.
  • Wenn diese Variable auf True gesetzt wird, erstellen wir die htpasswd-Datei, die von einem Webserver auf dem Relay zum Schutz von Tors MetricsPort mit HTTP-Basis-Authentifizierung verwendet werden kann.
  • Die Datei wird von root besessen und ist für die Gruppe des Webservers (www-data/www - abhängig vom Betriebssystem) lesbar.
  • Wir installieren nicht den Webserver; verwenden Sie dafür eine andere Rolle.
  • Das Passwort wird automatisch generiert und ist 20 Zeichen lang (jede Server erhält ein anderes Passwort).
  • Der Pfad zur Datei auf dem Relay wird durch tor_metricsport_htpasswd_file definiert.
  • Das Klartext-Passwort wird auf der Ansible-Steuerungsmaschine in einer Datei gespeichert (siehe tor_prometheus_scrape_password_folder).
  • Standard: Wahr

• tor_metricsport_htpasswd_file Dateipfad

  • Nur relevant, wenn tor_enableMetricsPort und tor_gen_metricsport_htpasswd auf wahr gesetzt sind.
  • Definiert den Dateipfad zur htpasswd-Datei (die Benutzernamen und Passwort-Hash enthält) auf dem Relay.
  • Standard: /etc/nginx/tor_metricsport_htpasswd

• tor_prometheus_scrape_password_folder Ordnerpfad

  • Nur relevant, wenn tor_enableMetricsPort wahr ist.
  • Ansible generiert automatisch ein einmaliges und zufälliges 20-Zeichen-Passwort pro Host (nicht pro Tor-Instanz), um den MetricsPort über nginx (HTTP-Authentifizierung) zu schützen.
  • Diese Variable definiert den Ordner, in dem Ansible die Passwörter im Klartext speichert (Passwort-Lookup).
  • Die Dateinamen in diesem Ordner entsprechen dem Hostnamen (inventory_hostname) und können nicht konfiguriert werden.
  • Die Variable muss einen abschließenden / enthalten.
  • Standard: ~/.tor/prometheus/scrape-passwords/

• tor_prometheus_scrape_port ganze Zahl

  • Definiert, welcher Zielport verwendet wird, um das Scrape-Ziel (MetricsPort) über nginx zu erreichen.
  • Standard: 443

• tor_enableControlSocket boolean

  • Wenn wahr, wird für jede Tor-Instanz eine ControlSocket-Datei erstellt (d.h. um für nyx verwendet zu werden).
  • Die Zugangskontrolle stützt sich auf Dateisystemberechtigungen.
  • Um einem Benutzer Zugriff auf eine bestimmte Tor-Instanz zu gewähren, müssen Sie den Benutzer zur Hauptgruppe der Tor-Instanz hinzufügen.
  • Der Pfad zu den Socket-Dateien ist /var/run/tor-instances/instance-id/control.
  • Diese Einstellung betrifft alle Instanzen auf einem gegebenen Server.
  • Eine per-Instanz-Konfiguration wird nicht unterstützt.
  • Standard: Falsch

• tor_freebsd_somaxconn ganze Zahl

  • Konfigurieren Sie kern.ipc.somaxconn auf FreeBSD.
  • Standardmäßig erhöhen wir diesen Wert auf mindestens 1024.
  • Wenn der Wert höher als das ist, berühren wir ihn nicht.

• tor_freebsd_nmbclusters ganze Zahl

  • Konfigurieren Sie kern.ipc.nmbclusters auf FreeBSD.
  • Standardmäßig erhöhen wir diesen Wert auf mindestens 30000.
  • Wenn der Wert höher als das ist, berühren wir ihn nicht.

• tor_package_state Zeichenfolge

  • Geben Sie an, welchen Paketstatus das Tor-Paket haben sollte.
  • Mögliche Werte: present, latest (nicht auf BSD unterstützt).
  • Hinweis: Die Repository-Metadaten werden nicht aktualisiert, sodass das Setzen auf latest keine Garantien bietet, ob es tatsächlich die neueste Version ist.
  • Standard: present

• tor_binary Zeichenfolge

  • Name des Tor-Binary auf der Steuerungsmaschine, das zur Generierung der Offline-Schlüssel verwendet wird.
  • Wenn das Tor-Binary auf Ihrer Steuerungsmaschine nicht „tor“ heißt, müssen Sie den Standard ändern (zum Beispiel bei Whonix-Arbeitsplätzen).
  • Standard: tor

Prometheus-Labels

Wenn tor_enableMetricsPort aktiviert ist, fügen wir auch die folgenden Prometheus-Labels hinzu:

• id: Identifiziert die Tor-Instanz durch IP_ORPort. Beispielwert: 198.51.100.10_9000
• relaytype: Wert ist entweder "exit" oder "nonexit", abhängig von tor_ExitRelay
• tor_nickname: Wenn Nicknames definiert sind (tor_nicknamefile oder tor_nickname), wird dieses Label hinzugefügt
• service: "torrelay"

Sie können zusätzliche Prometheus-Labels mit tor_prom_labels hinzufügen.

Verfügbare Rollentags

Die Verwendung von Ansible-Tags ist optional, bietet jedoch die Möglichkeit, die Ausführung von Playbooks zu beschleunigen, wenn Sie viele Server verwalten.

Es gibt OS-spezifische Tags:

• debian (einschließlich ubuntu)
• freebsd
• openbsd

Aufgabenorientierte Tags:

• renewkey - kümmert sich nur um die Erneuerung von online Ed25519-Schlüsseln (geht davon aus, dass Tor-Instanzen bereits vollständig konfiguriert und in Betrieb sind)
• install - installiert Tor, startet oder aktiviert es jedoch nicht
• createdir - erstellt (leere) Verzeichnisse nur auf der Ansible-Hostmaschine, nützlich für die Migration
• promconfig - regeneriert Prometheus-bezogene Konfigurationen (Scrape-Konfiguration, Blackbox-Exporter, Nginx)
• reconfigure - regeneriert Konfigurationsdateien (Tor und promconfig) und lädt Tor neu (erfordert zuvor konfigurierte Tor-Instanzen)

Wenn Sie also eine große Familie haben und einen OpenBSD-Host hinzufügen möchten, machen Sie typischerweise zwei Schritte:

1. Installieren Sie den neuen Server, indem Sie nur gegen den neuen Server (-l) und nur das OS-spezifische Tag (openbsd) ausführen.

   ansible-playbook yourplaybook.yml -l newserver --tags openbsd

2. Dann konfigurieren Sie alle Server (MyFamily) erneut, indem Sie das Tag 'reconfigure' gegen alle Server ausführen.

   ansible-playbook yourplaybook.yml --tags reconfigure

Sicherheitsüberlegungen

Diese Ansible-Rolle nutzt die OfflineMasterKey-Funktion von Tor, ohne dass manuelle Konfiguration erforderlich ist.

Die Offline-Master-Schlüsselfunktion zeigt nur einen temporären Signierschlüssel für das Relay an (standardmäßig 30 Tage gültig). Dies ermöglicht eine Wiederherstellung von einem vollständigen Serverkompromiss, ohne den Ruf eines Relays zu verlieren (keine Notwendigkeit, einen neuen dauerhaften Master-Schlüssel von Grund auf neu zu starten).

Jede Tor-Instanz wird mit einem eigenen Systembenutzer ausgeführt. Ein Benutzer pro Instanz hat nur Zugriff auf seine eigenen (temporären) Schlüssel, nicht auf die anderer Instanzen. Wir vertrauen nicht vollständig auf jedes Tor-Relay, das wir betreiben (wir versuchen, Eingabebenutzerdaten zu validieren, wenn wir Relay-Daten auf dem Ansible-Host oder einem anderen Relay verwenden).

Seien Sie sich bewusst, dass die Ansible-Steuerungsmaschine ALL Ihre Relay-Schlüssel (RSA und Ed25519) speichert - ergreifen Sie entsprechende Sicherheitsmaßnahmen.

Wenn Sie die Prometheus-Integration verwenden, speichert die Ansible-Steuerungsmaschine auch alle Ihre Prometheus-Scrape-Anmeldeinformationen unter ~/.tor/prometheus/. Das Rotieren dieser Anmeldeinformationen ist jedoch sehr einfach: Sie können diesen Ordner einfach entfernen und das Ansible-Playbook erneut ausführen.

Jeder Tor-Server-Host erhält sein eigenes Set von Prometheus-Anmeldeinformationen, sodass ein kompromittierter Host nicht zulässt, dass sie alle anderen Hosts abfragen.

Integrationstests

Diese Ansible-Rolle kommt mit einer .kitchen.yml-Datei, die verwendet werden kann, um relayor - mit unterschiedlichen Konfigurationen - gegen Vagrant-VMs zu testen. Sie wird hauptsächlich für Entwicklungs-/Integrationstests verwendet (um Rückschläge zu erkennen),
aber Sie können sie auch verwenden, um sich in einer solchen lokalen Testumgebung mit relayor vertraut zu machen. Diese Tor-Relays werden das Netzwerk nicht betreten, da sie nur zu Testzwecken erstellt werden.

Die Küche lädt Vagrant-Boxen von Vagrant Cloud herunter, um Test-VMs zu erstellen.

Um zu beginnen, installieren Sie die erforderlichen Gem-Pakete:

gem install test-kitchen kitchen-ansiblepush kitchen-vagrant

Listen Sie die verfügbaren Testinstanzen mit kitchen list auf.

Dann können Sie alle Tests ausführen oder nur bestimmte Instanzen auswählen, zum Beispiel: kitchen test t-guard-debian-10.

Bitte beachten Sie, dass Sie zum Ausführen von Tests auch Vagrant und VirtualBox benötigen.

Ursprünge

https://github.com/david415/ansible-tor (seitdem erheblich geändert)