nusenu.relayor

ansible-relayor

Ceci est un rôle Ansible pour les opérateurs de relais Tor.
Une introduction à Relayor peut être trouvée ici.

Support par e-mail : relayor-support AT riseup.net

L'objectif principal de ce rôle est d'automatiser autant d'étapes que possible pour un opérateur de relais Tor, y compris la gestion des clés (OfflineMasterKey).
Déployer un nouveau serveur Tor est aussi simple que d'ajouter un nouvel hôte à l'inventaire, aucune configuration manuelle supplémentaire n'est requise.

Ce rôle ne gère que les instances Tor selon les paramètres et variables actuels.
Si vous modifiez la configuration après un exécution complète du playbook, par exemple en réduisant le nombre d'instances Tor avec tor_maxPublicIPs, ce rôle ne supprimera pas les instances Tor précédemment configurées sur votre serveur. Les instances Tor sur un serveur sont identifiées par leur combinaison IPv4 et ORPort.
Modifier l'ORPort (en utilisant la variable tor_ports) après le déploiement initial signifie en fait créer de nouvelles instances Tor (et non pas les modifier). C'est pourquoi il est recommandé d'éviter de changer la variable tor_ports après le déploiement initial.

Maintenir le paquet Tor à jour (une tâche importante pour un relais) n'est pas dans le périmètre de ce rôle Ansible.
Nous vous conseillons d'activer les mises à jour automatiques pour garder votre relais bien entretenu, si votre OS le supporte.
Le Guide du Relais Tor contient des instructions sur la manière d'activer les mises à jour logicielles automatiques pour Debian/Ubuntu et FreeBSD.

Ce rôle Ansible n'a pas vocation à supporter les ponts Tor.

Principaux avantages pour un opérateur de relais Tor

• automatisation - plus de tâches de configuration manuelles
• sécurité : clés maîtresses Ed25519 hors ligne générées sur l'hôte Ansible et jamais exposées au relais
• facilité de renouvellement de la clé de signature Ed25519 (valide par défaut pendant 30 jours - configurable)
• sécurité : compartimentation : chaque instance Tor est exécutée avec un utilisateur distinct
• utilisation automatique des adresses IPv6 (si disponibles)
• génération automatique d'instances Tor (deux par défaut - configurable)
• active la fonction Sandbox de Tor par défaut sur les systèmes basés sur Debian
• choix facile entre les versions alpha et non-alpha (uniquement pour Debian/Ubuntu/FreeBSD)
• restauration facile d'une configuration de relais (l'hôte Ansible devient un emplacement de sauvegarde pour toutes les clés dès le départ)
• choix facile entre le mode relais de sortie et de non-sortie avec un seul booléen
• déploiement automatique d'une page HTML de notification de sortie Tor via le DirPort de Tor (uniquement pour les sorties)
• gestion automatique de MyFamily
• intégration Prometheus (si activée)
  • génération automatique de la configuration du proxy inverse nginx pour protéger le MetricsPort de Tor (derrière une authentification de base / HTTPS)
  • génération automatique de la configuration de collecte pour MetricsPort
  • génération automatique de la configuration de collecte du blackbox-exporter pour surveiller la connectivité des ORPorts et DirPorts
  • expédition des règles d'alerte Prometheus pour Tor

Installation

Ce rôle Ansible est disponible sur Galaxy : https://galaxy.ansible.com/nusenu/relayor/

ansible-galaxy install nusenu.relayor

Exigences

Exigences pour la Machine de Contrôle

• ne pas exécuter ce rôle avec become: yes
• Tor >= 0.4.8
• le paquet python-netaddr doit être installé
• commandes requises : sort, uniq, wc, cut, sed, xargs
• openssl >= 1.0.0
• ansible >= 2.16.4
• bash sous /bin/bash

Exigences pour le Nœud Géré

• un utilisateur non-root avec des permissions sudo
• python
• adresse(s) IPv4 statique(s)
  • nous pouvons utiliser plusieurs IP publiques
  • si vous n'avez pas d'IP publique, nous utiliserons une seule IP privée (en supposant NAT)
• systemd (tous les systèmes basés sur Linux)

Exigences pour le Serveur Prometheus (uniquement si vous utilisez les fonctionnalités Prometheus de ce rôle)

• promtool doit être installé sur le serveur Prometheus et dans le PATH de l'utilisateur root

Systèmes d'Exploitation Supportés

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

Versions de Tor Supportées

• Tor >= 0.4.8.x

Exemple de Playbook

Un playbook minimal utilisant ansible-relayor pour configurer des relais non-sortants pourrait ressembler à ceci :

---

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

Pour plus d'exemples, consultez le dossier des exemples de playbook.

Modifications des paramètres par défaut de torrc

Ce rôle modifie les valeurs par défaut des options suivantes dans torrc pour utiliser des options plus sûres par défaut, mais vous pouvez toujours les configurer explicitement via tor_config :

• NoExec 0 -> 1
• Sandbox 0 -> 1 (sur Debian uniquement)

Variables de Rôle

Toutes les variables mentionnées ici sont optionnelles.

• tor_ContactInfo chaîne

  • Définit le champ ContactInfo du relais.
  • Ce paramètre est obligatoire.
  • Les opérateurs sont encouragés à utiliser la Spécification de Partage d'Informations ContactInfo pour publier des informations de contact utiles.

• tor_signingkeylifetime_days entier

  • toutes les instances Tor créées par relayor fonctionnent en mode OfflineMasterKey
  • ce paramètre définit la durée de vie des clés de signature Ed25519 en jours
  • définit indirectement la fréquence à laquelle vous devez exécuter votre playbook Ansible pour garantir que vos clés de relais n'expirent pas
  • une instance de Tor en mode OfflineMasterKey s'arrête automatiquement lorsque sa clé/certificat expire, donc c'est un paramètre crucial !
  • des valeurs plus basses (ex. : 7) sont meilleures d'un point de vue de la sécurité, mais nécessitent des exécutions plus fréquentes du playbook
  • par défaut : 30

• tor_config dictionnaire

  • ce dictionnaire contient les paramètres torrc et leur valeur, pour les options disponibles, consultez la section 'OPTIONS SERVEUR' dans le manuel de Tor.
  • chaque paramètre ne peut être défini qu'une seule fois (peu importe ce que dit la page de manuel de Tor)
  • ce dictionnaire peut être utilisé pour définir n'importe quelle option torrc mais PAS les suivantes : 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 dictionnaire

  • Cette variable vous permet de
    • sélectionner l'ORPort et le DirPort de Tor
    • décider combien d'instances Tor vous souhaitez exécuter par adresse IP (2 par défaut) - assurez-vous de ne pas en exécuter plus que ce qui est autorisé par adresse IP
  • désactiver les DirPorts en les définissant à 0
  • CONSEIL : choisissez les ORPorts judicieusement et ne les changez jamais à nouveau, du moins pas ceux déjà déployés, ajouter d'autres sans modifier ceux déjà déployés est acceptable.
  • la fonction 'auto' de Tor n'est PAS supportée
  • valeur par défaut :
    • instance 1 : ORPort 9000, DirPort 9001
    • instance 2 : ORPort 9100, DirPort 9101

• tor_offline_masterkey_dir chemin_dossier

  • par défaut : ~/.tor/offlinemasterkeys
  • Définit l'emplacement où sur la machine de contrôle Ansible nous stockons les clés de relais (Ed25519 et RSA)
  • Dans ce dossier, Ansible créera un sous-dossier pour chaque instance Tor.
  • voir la documentation si vous souhaitez migrer des instances vers un nouveau serveur
  • remarque : ne manipulez pas manuellement les noms de fichiers et/ou de dossiers/contenu dans ces Dossiers de Données Tor

• tor_nickname chaîne

  • définit le surnom que les instances Tor utiliseront
  • toutes les instances Tor sur un hôte auront le même surnom
  • pour utiliser le nom d'hôte du serveur comme surnom, définissez-le à {{ ansible_hostname }}
  • les caractères non-alphanumériques sont automatiquement supprimés et les surnoms de plus de 19 caractères sont tronqués pour respecter les exigences de surnom de Tor
  • tor_nicknamefile prévaudra sur ce paramètre
  • valeur par défaut : aucune

• tor_nicknamefile chemin_fichier

  • il s'agit d'un fichier CSV simple séparé par des virgules stocké sur la machine de contrôle Ansible spécifiant les surnoms
  • première colonne : identifiant de l'instance (inventory_hostname-ip_orport)
  • deuxième colonne : surnom
  • une instance par ligne
  • toutes les instances DOIVENT être présentes dans le fichier CSV
  • les caractères non-alphanumériques sont automatiquement supprimés et les surnoms de plus de 19 caractères sont tronqués pour respecter les exigences de surnom de Tor
  • valeur par défaut : non défini

• tor_gen_ciiss_proof_files booléen

  • génère les fichiers de preuve rsa-fingerprint.txt et ed25519-master-pubkey.txt sur la machine de contrôle pour publication conformément à la spécification ContactInfo
  • les chemins par défaut sont : ~/.tor/rsa-fingerprint.txt et ~/.tor/ed25519-master-pubkey.txt
  • les fichiers sont écrasés s'ils existent
  • l'emplacement du dossier de sortie peut être configuré à l'aide de la variable tor_ciiss_proof_folder
  • le nom de fichier est codé en dur à celui exigé par la spécification et ne peut pas être configuré
  • valeur par défaut : Faux

• tor_ciiss_proof_folder chemin_dossier

  • définit le dossier de sortie pour les fichiers de preuve générés
  • valeur par défaut : ~/.tor

• tor_LogLevel chaîne

  • définit le niveau de journalisation de Tor
  • valeur par défaut : notice

• tor_alpha booléen

  • À définir sur Vrai si vous souhaitez utiliser les versions alpha de Tor.
  • Remarque : Ce paramètre ne garantit pas qu'une installation de Tor soit mise à niveau vers la version alpha.
  • Ce paramètre est pris en charge uniquement sur Debian/Ubuntu/FreeBSD (ignoré sur d'autres plateformes).
  • valeur par défaut : Faux

• tor_nightly_builds booléen

  • À définir sur Vrai si vous souhaitez utiliser le dépôt de constructions nocturnes de Tor depuis deb.torproject.org.
  • les constructions nocturnes suivent la branche principale git de Tor.
  • Supporté uniquement sur Debian et Ubuntu (ignoré sur d'autres plateformes).
  • valeur par défaut : Faux

• tor_ExitRelay booléen

  • Vous devez définir ceci sur Vrai si vous souhaitez activer la sortie pour toutes ou certaines instances Tor sur un serveur
  • Si cette variable n'est pas Vraie, cela sera un relais non-sortant
  • Si vous souhaitez exécuter un serveur mixte (instances Tor sortantes et non-sortantes), utilisez tor_ExitRelaySetting_file pour la configuration par instance en plus de cette variable
  • valeur par défaut : Faux

• tor_ExitRelaySetting_file chemin_fichier

  • il s'agit d'un fichier CSV simple séparé par des virgules stocké sur la machine de contrôle Ansible définissant le paramètre ExitRelay de torrc pour chaque instance Tor (plutôt que pour l'ensemble du serveur)
  • première colonne : identifiant de l'instance (inventory_hostname-ip_orport)
  • deuxième colonne : "exit" pour les instances Tor sortantes, toute autre valeur (y compris vide) pour les instances non-sortantes
  • cette variable est ignorée si tor_ExitRelay est Faux

• tor_RelayBandwidthRate_file chemin_fichier

  • il s'agit d'un fichier CSV simple séparé par des virgules stocké sur la machine de contrôle Ansible définissant le paramètre RelayBandwidthRate de torrc pour chaque instance Tor (plutôt que pour l'ensemble du serveur)
  • première colonne : identifiant de l'instance (inventory_hostname-ip_orport)
  • deuxième colonne : valeur acceptée par RelayBandwidthRate (voir la page de manuel de Tor)

• tor_RelayBandwidthBurst_file chemin_fichier

  • il s'agit d'un fichier CSV simple séparé par des virgules stocké sur la machine de contrôle Ansible définissant le paramètre RelayBandwidthBurst de torrc pour chaque instance Tor (plutôt que pour l'ensemble du serveur)
  • première colonne : identifiant de l'instance (inventory_hostname-ip_orport)
  • deuxième colonne : valeur acceptée par RelayBandwidthBurst (voir la page de manuel de Tor)

• tor_ExitNoticePage booléen

  • spécifie si nous affichons par défaut la page de notification de sortie de Tor html sur le DirPort
  • seulement pertinent si nous sommes un relais sortant
  • valeur par défaut : Vrai

• tor_exit_notice_file chemin_fichier

  • chemin vers un fichier HTML sur la machine de contrôle que vous souhaitez afficher (via le DirPort) au lieu de la page par défaut tor-exit-notice.html fournie par le projet Tor
  • seulement pertinent si nous sommes un relais sortant et si tor_ExitNoticePage est Vrai

• tor_AbuseEmailAddress adresse_email

  • si définie, cette adresse e-mail est utilisée sur la page de notification de sortie de Tor html publiée sur le DirPort
  • vous êtes encouragé à la définir si vous exécutez une sortie
  • seulement pertinent si nous sommes un relais sortant
  • Remarque : si vous utilisez votre propre modèle de notification de sortieTor personnalisé, cette variable est ignorée si vous ne l'incluez pas dans votre modèle.
  • valeur par défaut : non définie

• tor_ExitPolicy tableau

  • spécifiez votre politique de sortie personnalisée
  • seulement pertinent si tor_ExitRelay est Vrai
  • voir defaults/main.yml pour un exemple de comment la définir
  • valeur par défaut : politique de sortie réduite (https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy)

• tor_ExitPolicy_file chemin_fichier

  • il s'agit d'un fichier CSV simple séparé par des points-virgules stocké sur la machine de contrôle Ansible définissant le paramètre ExitPolicy de torrc pour chaque instance Tor (plutôt que pour l'ensemble du serveur)
  • première colonne : identifiant de l'instance (inventory_hostname-ip_orport)
  • deuxième colonne : valeur acceptée par ExitPolicy (voir la page de manuel de Tor)
  • exemple de contenu : "myrelay-192.168.1.1_443;reject *:25,reject *:123"
  • seulement pertinent si tor_ExitRelay est Vrai
  • cela peut être combiné avec le paramètre tor_ExitPolicy et le prévaudra (c'est plus spécifique)
  • seules les instances Tor pour lesquelles vous souhaitez avoir une politique de sortie spécifique doivent être listées dans le fichier (les autres peuvent être omises)
  • valeur par défaut : non définie

• tor_maxPublicIPs entier

  • Limite le nombre d'IP publiques que nous utiliserons pour générer des instances sur un seul hôte.
  • Limite indirectement le nombre d'instances que nous générons par hôte.
  • valeur par défaut : 1

• tor_IPv6 booléen

  • autodétecte si vous avez des adresses IP IPv6 et active un ORPort IPv6 en conséquence
  • vous pouvez choisir de ne pas l'utiliser en le définissant à Faux
  • valeur par défaut : Vrai

• tor_IPv6Exit booléen

  • active le trafic de sortie IPv6
  • seulement pertinent si tor_ExitRelay et tor_IPv6 sont Vrais et que nous avons une adresse IPv6
  • valeur par défaut : Vrai (contrairement à la valeur par défaut de Tor)

• tor_enableMetricsPort booléen

  • si Vrai, active le MetricsPort de Tor sur l'adresse IP localhost 127.0.0.1 et permet à la même IP d'y accéder (MetricsPortPolicy)
  • cette fonction de relayor est encore en bêta et changera à l'avenir pour utiliser l'option plus sécurisée socket UNIX une fois qu'elle sera disponible
  • activer ce paramètre désactive automatiquement OverloadStatistics s'il n'est pas activé explicitement (donc Tor ne publiera pas/uploadera les données vers les autorités de répertoire car nous utilisons le MetricsPort localement)
  • valeur par défaut : Faux

• tor_prometheus_host nom_d'hôte

  • cette variable n'est pertinente que si tor_enableMetricsPort ou tor_blackbox_exporter_host est défini
  • si vous souhaitez activer l'intégration Prometheus de relayor, vous devez définir cette variable sur votre hôte Prometheus
  • définit sur quel hôte Ansible doit générer la configuration de collecte pour collecter le MetricsPort de Tor
  • cet hôte doit être disponible dans le fichier d'inventaire d'Ansible
  • valeur par défaut : indéfini (aucune configuration de collecte n'est générée)

• tor_prometheus_confd_folder chemin_dossier

  • seulement pertinent si vous souhaitez utiliser Prometheus
  • ce dossier doit exister sur tor_prometheus_host
  • Relayor place les scrape_configs de Prometheus dans ce dossier
  • la section de configuration globale de Prometheus doit être dans ce dossier nommée 1_prometheus.yml
  • nous assemblons tous les fichiers dans ce dossier dans l'ordre de tri des chaînes en un seul fichier de sortie prometheus.yml, car Prometheus ne prend pas en charge les dossiers de style conf.d par défaut
  • valeur par défaut : /etc/prometheus/conf.d

• tor_prometheus_config_file chemin_fichier

  • seulement pertinent si vous souhaitez utiliser Prometheus
  • cette variable définit le chemin du fichier de configuration global de Prometheus sur tor_prometheus_host
  • nous sauvegardons le fichier dans le même dossier avant d'en générer un nouveau
  • il s'agit d'un fichier sensible en matière de sécurité car il contient des informations d'identification pour le MetricsPort de Tor
  • propriétaire du fichier : root, groupe : tor_prometheus_group, permissions : 0640
  • valeur par défaut : /etc/prometheus/prometheus.yml

• tor_MetricsPort_offset entier

  • définit le MetricsPort TCP utilisé sur la première instance Tor exécutée sur un hôte
  • les instances Tor supplémentaires utiliseront un numéro de port incrémenté 33301, 33302, ...
  • ainsi, si vous exécutez N instances sur un hôte, les N-1 ports suivants après ce port doivent être inutilisés sur 127.0.0.1 afin que Tor puisse les utiliser pour le MetricsPort
  • valeur par défaut : 33300

• tor_prometheus_scrape_file nom_fichier

  • seulement pertinent si tor_prometheus_host est défini et tor_enableMetricsPort ou tor_blackbox_exporter_host est défini
  • définit le nom de fichier pour les fichiers de scrape_config par serveur sur le serveur Prometheus à l'intérieur du tor_prometheus_confd_folder
  • le nom de fichier DOIT être spécifique à l'hôte, chaque hôte a son propre fichier de configuration de collecte sur le serveur Prometheus pour prendre en charge l'option cli --limit du playbook Ansible
  • selon tor_enableMetricsPort et tor_blackbox_exporter_host, les fichiers de configuration de collecte contiendront des travaux de collecte pour le MetricsPort de Tor (derrière un proxy inverse pour TLS/authentification de base) et/ou des travaux de collecte pour les probes TCP ORPort/DirPort via blackbox exporter
  • le contenu de fichier est sensible (contient des informations d'identification de collecte) et a ces permissions de fichier : 0640 (propriétaire : root, groupe : tor_prometheus_group)
  • les fichiers de configurations de collecte générés seront automatiquement enrichis de quelques étiquettes Prometheus utiles selon vos paramètres torrc, voir la section "Étiquettes Prometheus" dans ce README
  • valeur par défaut : tor_{{ ansible_fqdn }}.yml

• tor_prometheus_group chaîne

  • seulement pertinent si vous souhaitez utiliser Prometheus
  • définit le nom de groupe utilisé pour les permissions de fichier Prometheus (prometheus.yml, fichiers de configuration de collecte, fichier de règles d'alerte)
  • valeur par défaut : prometheus

• tor_prom_labels dictionnaire

  • nombre arbitraire de paires clé/valeur d'étiquettes Prometheus
  • peut être défini au niveau de chaque serveur, pas au niveau de chaque instance
  • pour un exemple, voir defaults/main.yml
  • valeur par défaut : dictionnaire vide

• tor_blackbox_exporter_host nom_d'hôte:port

  • lorsqu'il est défini, relayor ajoute la configuration de collecte Prometheus nécessaire pour les probes TCP blackbox exporter dans le fichier défini par tor_prometheus_scrape_file
  • surveille tous les ORPorts de relais et les DirPorts lorsque cela est défini sur IPv4 et IPv6 (si activé) en utilisant un contrôle de connectivité TCP
  • cette fonctionnalité n'est pas supportée sur les relais derrière NAT
  • définit où Prometheus trouve le blackbox exporter ; il peut également fonctionner sur le serveur Prometheus lui-même, dans ce cas, ce serait 127.0.0.1:9115
  • l'hôte est écrit dans la configuration de collecte Prometheus résultante
  • le blackbox_exporter doit avoir un simple module tcp_probe nommé "tcp_connect" configuré
  • relayor n'installe ni ne configure le blackbox_exporter
  • valeur par défaut : indéfini

• tor_blackbox_exporter_scheme chaîne

  • définit le protocole utilisé par Prometheus pour se connecter au blackbox exporter (http ou https)
  • valeur par défaut : http

• tor_blackbox_exporter_username chaîne

  • seulement pertinent lorsque tor_blackbox_exporter_host est défini
  • vous permet de définir le nom d'utilisateur si votre blackbox exporter nécessite une authentification basique HTTP
  • si vous ne définissez pas de nom d'utilisateur, la configuration de collecte n'inclura pas les informations d'identification d'authentification basique HTTP
  • valeur par défaut : indéfini (pas d'authentification basique HTTP)

• tor_blackbox_exporter_password chaîne

  • seulement pertinent lorsque tor_blackbox_exporter_host est défini
  • vous permet de définir le mot de passe si votre blackbox exporter nécessite une authentification basique HTTP
  • la valeur par défaut génère une chaîne aléatoire de 20 caractères en utilisant le lookup de mot de passe Ansible
  • valeur par défaut : "{{ lookup('password', '~/.tor/prometheus/blackbox_exporter_password') }}"

• tor_metricsport_nginx_config_file chemin_fichier

  • cette variable est seulement pertinente si tor_enableMetricsPort est Vrai et tor_prometheus_host est défini
  • elle définit le chemin du fichier où sera stockée la configuration du proxy inverse nginx pour le MetricsPort sur le relais
  • ce fichier doit être inclus dans votre configuration de serveur web sur le relais pour rendre le MetricsPort accessible pour la collecte distante de Prometheus
  • le dossier doit être présent sur le serveur au préalable (relayor ne le crée pas)
  • valeur par défaut : /etc/nginx/promexporters/tor_metricsports_relayor.conf

• tor_gen_prometheus_alert_rules booléen

  • seulement pertinent lorsque tor_enableMetricsPort est activé
  • défini sur True si vous souhaitez générer des règles d'alerte Prometheus sur le serveur Prometheus (tor_prometheus_host)
  • l'emplacement du fichier est défini par tor_prometheus_rules_file
  • valeur par défaut : faux (aucune règle n'est générée)

• tor_prometheus_rules_file chemin_fichier

  • seulement pertinent lorsque tor_gen_prometheus_alert_rules est True
  • définit où sur le serveur Prometheus (tor_prometheus_host) relayor générera le fichier de règles (le dossier doit être présent)
  • le fichier doit être dans le dossier inclus par votre configuration Prometheus (rule_files) et doit généralement se terminer par .rules
  • relayor fournit un ensemble par défaut de règles d'alerte et vous pouvez également ajouter vos propres règles personnalisées (via tor_prometheus_custom_alert_rules)
  • propriétaire/groupe de fichier : root, permissions de fichier : 0644
  • valeur par défaut : /etc/prometheus/rules/ansible-relayor.rules

• tor_prometheus_alert_rules dictionnaire

  • définit les règles d'alerte Prometheus
  • les règles sont automatiquement validées à l'aide de promtool
  • voir defaults/main.yml pour les règles par défaut

• tor_prometheus_custom_alert_rules dictionnaire

  • si vous souhaitez ajouter vos règles définies par l'utilisateur, ajoutez-les à ce dictionnaire, il attend le même format que dans tor_prometheus_alert_rules
  • les règles définies dans ce dictionnaire sont également écrites dans tor_prometheus_rules_file
  • cela vous permet de profiter de nouvelles règles fournies par les nouvelles versions de relayor tout en maintenant vos règles définies par l'utilisateur
  • les règles sont automatiquement validées à l'aide de promtool
  • valeur par défaut : indéfini

• tor_gen_metricsport_htpasswd booléen

  • cette variable est seulement pertinente si tor_enableMetricsPort est Vrai
  • lorsque cette variable est définie sur Vrai, nous créons le fichier htpasswd qui peut être utilisé par un serveur web sur le relais pour protéger le MetricsPort de Tor avec une authentification basique HTTP
  • le fichier sera la propriété de root et lisible par le groupe du serveur web (www-data/www - selon l'OS)
  • nous n'installons pas le serveur web, utilisez un autre rôle pour cela.
  • le mot de passe est généré automatiquement et fait 20 caractères de long (chaque serveur reçoit un mot de passe distinct)
  • le chemin vers le fichier sur le relais est défini dans tor_metricsport_htpasswd_file
  • le mot de passe en clair est écrit dans un fichier sur la machine de contrôle Ansible (voir tor_prometheus_scrape_password_folder)
  • valeur par défaut : Vrai

• tor_metricsport_htpasswd_file chemin_fichier

  • seulement pertinent si tor_enableMetricsPort et tor_gen_metricsport_htpasswd sont définis sur Vrai
  • il définit le chemin vers le fichier htpasswd (contenant le nom d'utilisateur et le mot de passe hashé) sur le relais
  • valeur par défaut : /etc/nginx/tor_metricsport_htpasswd

• tor_prometheus_scrape_password_folder chemin_dossier

  • seulement pertinent si tor_enableMetricsPort est Vrai
  • Ansible générera automatiquement un mot de passe unique et aléatoire de 20 caractères par hôte (pas par instance Tor) pour protéger le MetricsPort via nginx (auth http)
  • cette variable définit le dossier où Ansible stockera les mots de passe en clair (lookup de mot de passe)
  • les noms de fichiers dans ce dossier correspondent au nom d'hôte (inventory_hostname) et ne peuvent pas être configurés
  • la variable doit contenir une barre oblique à la fin /
  • valeur par défaut : ~/.tor/prometheus/scrape-passwords/

• tor_prometheus_scrape_port entier

  • définit quel port de destination est utilisé pour atteindre la cible de collecte (MetricsPort) via nginx
  • valeur par défaut : 443

• tor_enableControlSocket booléen

  • si Vrai, crée un fichier ControlSocket pour chaque instance Tor (c'est-à-dire à utiliser pour nyx)
  • le contrôle d'accès repose sur les permissions du système de fichiers
  • pour donner à un utilisateur l'accès au fichier de socket de contrôle d'une instance Tor spécifique, vous devez ajouter l'utilisateur au groupe principal de l'instance Tor
  • le chemin vers le(s) fichier(s) de socket est /var/run/tor-instances/instance-id/control
  • ce paramètre affecte toutes les instances sur un serveur donné
  • la configuration par instance n'est pas supportée
  • valeur par défaut : Faux

• tor_freebsd_somaxconn entier

  • configure kern.ipc.somaxconn sur FreeBSD
  • par défaut, nous augmentons cette valeur à au moins 1024
  • si la valeur est supérieure à cela, nous ne la touchons pas

• tor_freebsd_nmbclusters entier

  • configure kern.ipc.nmbclusters sur FreeBSD
  • par défaut, nous augmentons cette valeur à au moins 30000
  • si la valeur est supérieure à cela, nous ne la touchons pas

• tor_package_state chaîne

  • spécifiez quel état de paquet le paquet Tor doit avoir
  • valeurs possibles : présent, dernière (non pris en charge sur les BSD)
  • Remarque : Les métadonnées du dépôt ne sont pas mises à jour, donc définir cela sur dernière ne vous garantit pas que c'est réellement la dernière version.
  • valeur par défaut : présent

• tor_binary chaîne

  • nom du binaire Tor sur la machine de contrôle utilisé pour générer les clés hors ligne
  • si le binaire Tor n'est pas nommé "tor" sur votre machine de contrôle, vous devez changer la valeur par défaut (par exemple sur des stations de travail Whonix)
  • valeur par défaut : tor

Étiquettes Prometheus

Lorsque tor_enableMetricsPort est activé, nous remplissons également les étiquettes Prometheus suivantes :

• id : identifie l'instance Tor par IP_ORPort. Exemple : 198.51.100.10_9000
• relaytype : la valeur est soit "exit" soit "nonexit" en fonction de tor_ExitRelay
• tor_nickname : lorsque les surnoms sont définis (tor_nicknamefile ou tor_nickname), cette étiquette est ajoutée
• service : "torrelay"

Vous pouvez ajouter des étiquettes Prometheus supplémentaires en utilisant tor_prom_labels.

Tags de Rôle Disponibles

Utiliser des tags Ansible est optionnel mais vous permet d'accélérer les exécutions de playbook si vous gérez de nombreux serveurs.

Il existe des tags spécifiques au système d'exploitation :

• debian (inclut ubuntu)
• freebsd
• openbsd

Tags orientés tâches :

• renewkey - s'occupe du renouvellement des clés Ed25519 en ligne uniquement (suppose que les instances Tor sont déjà entièrement configurées et en cours d'exécution)
• install - installe Tor mais ne le démarre pas ou ne l'active pas
• createdir - crée (vides) des dossiers uniquement sur l'hôte Ansible, utile pour la migration
• promconfig - régénère les configurations liées à Prometheus (configuration de collecte, blackbox exporter, nginx)
• reconfigure - régénère les fichiers de configuration (Tor et promconfig) et recharge Tor (nécessite des instances Tor préalablement configurées)

Ainsi, si vous avez une grande famille et que vous êtes sur le point d'ajouter un hôte OpenBSD, vous pouvez généralement procéder en deux étapes

1. installer le nouveau serveur en ne exécutant que sur le nouveau serveur (-l) et uniquement le tag spécifique au système d'exploitation (openbsd)

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

2. ensuite, reconfigurer tous les serveurs (MyFamily) en exécutant le tag 'reconfigure' sur tous les serveurs.

   ansible-playbook yourplaybook.yml --tags reconfigure

Considérations de Sécurité

Ce rôle Ansible utilise la fonctionnalité OfflineMasterKey de Tor sans nécessiter de configuration manuelle.

La fonctionnalité de clé maître hors ligne expose uniquement une clé de signature temporaire au relais (valide pendant 30 jours par défaut).
Cela permet de récupérer d'un compromis complet du serveur sans perdre la réputation d'un relais (pas besoin de démarrer une nouvelle clé maître permanente depuis le début).

Chaque instance Tor est exécutée avec un utilisateur système distinct. Un utilisateur par instance n'a accès qu'à ses propres clés (temporaire), mais pas à celles des autres instances.
Nous ne faisons pas confiance à chaque relais Tor que nous exploitons (nous essayons de valider les entrées lorsque nous utilisons les données fournies par le relais sur l'hôte Ansible ou un autre relais).

Soyez conscient que la machine de contrôle Ansible stocke TOUS vos clés de relais (RSA et Ed25519) - appliquez des mesures de sécurité en conséquence.

Si vous utilisez l'intégration Prometheus, la machine de contrôle Ansible stockera également toutes vos informations d'identification de collecte Prometheus sous ~/.tor/prometheus/.
La rotation de ces informations d'identification est très simple : vous pouvez simplement supprimer ce dossier et exécuter à nouveau le playbook Ansible.

Chaque hôte de serveur Tor obtient son propre ensemble d'informations d'identification Prometheus, donc un hôte compromis ne devrait pas permettre de collecter toutes les autres hôtes.

Tests d'Intégration

Ce rôle Ansible est livré avec un fichier .kitchen.yml qui peut être utilisé pour tester Relayor - en utilisant différentes configurations - contre des machines virtuelles Vagrant sous VirtualBox.
Il est principalement utilisé pour les tests de développement/integration (pour repérer les régressions) mais vous pouvez également l'utiliser pour vous familiariser avec Relayor dans un environnement local de type terrain de jeu.
Ces relais Tor ne rejoindront pas le réseau puisqu'ils ne sont créés qu'à des fins de test.

Kitch vous téléchargera des boxes Vagrant depuis Vagrant Cloud pour créer des VMs de test.

Pour commencer, installez les packages gem requis :

gem install test-kitchen kitchen-ansiblepush kitchen-vagrant

Listez les instances de test disponibles avec kitchen list.

Ensuite, vous pouvez exécuter tous les tests ou choisir simplement des instances spécifiques, par exemple : kitchen test t-guard-debian-10.

Notez que pour exécuter les tests, vous avez également besoin de Vagrant et de VirtualBox.

Origines

https://github.com/david415/ansible-tor (changé de manière significative depuis lors)