This is a personal project page. Nothing to see here.
EOF ``` 2. **Obtener un certificado TLS** (si todavía no tienes uno) **Obtener certificado de Let's Encrypt** ```bash sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d your-domain.com ``` 3. **Crear el bloque de servidor de Nginx** **Fichero: `/etc/nginx/sites-available/tor-bridge.conf`** ```nginx # Tor WebTunnel Bridge — Camouflage configuration # This looks like a normal HTTPS website but proxies # a secret path to the WebTunnel pluggable transport server { listen 443 ssl; listen [::]:443 ssl; http2 on; server_name your-domain.com; # TLS certificates ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; # === Normal website (camouflage) === root /var/www/tor-camouflage; index index.html; location / { try_files $uri $uri/ =404; } # === WebTunnel reverse proxy (secret path) === # Replace YOUR_SECRET_PATH with your generated secret location = /YOUR_SECRET_PATH { proxy_pass http://127.0.0.1:15000; proxy_http_version 1.1; # WebSocket upgrade headers (required for WebTunnel) proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # Standard proxy headers proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Accept-Encoding ""; add_header Front-End-Https on; proxy_redirect off; proxy_buffering off; proxy_request_buffering off; # Long timeout for persistent Tor connections proxy_read_timeout 36000s; proxy_send_timeout 36000s; # Disable logging for the secret path (privacy) access_log off; error_log off; } } # HTTP to HTTPS redirect server { listen 80; listen [::]:80; server_name your-domain.com; return 301 https://$host$request_uri; } ``` 4. **Habilitar el sitio y probarlo** **Habilitar el sitio en Nginx y probar la configuración** ```bash sudo ln -sf /etc/nginx/sites-available/tor-bridge.conf \ /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx ``` **Comparación: Lo que ven los censores vs Lo que realmente sucede** **Lo que ven los censores** **Sitio web HTTPS normal** Una petición `GET /` a tu dominio devuelve una página HTML sencilla. El DPI ve tráfico TLS 1.3 estándar hacia un dominio registrado. Nada sospechoso. ``` HTTP/1.1 200 OK Content-Type: text/html Welcome... ``` **Lo que realmente sucede** **Conexión del bridge de WebTunnel** Una petición `GET /SECRET_PATH` con una cabecera `Connection: Upgrade` llega al servidor WebTunnel, que abre un túnel persistente para el tráfico de Tor — todo dentro de la misma sesión TLS. ``` HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade [El tráfico de Tor circula por el túnel] ``` --- ## Paso 5: configurar el reenvío de puertos Si tu servidor está detrás de un router (lo habitual en instalaciones domésticas), tienes que reenviar estos puertos desde la IP pública del router hasta la IP local de tu servidor: **Reenvíos de puertos necesarios** | Puerto | Protocolo | Propósito | ¿Necesario? | | --- | --- | --- | --- | | **9001** | TCP | ORPort — comunicación entre relés | Sí (siempre) | | **4443** | TCP | obfs4 — transporte ofuscado | Sí (si ejecutas obfs4) | | **443** | TCP | HTTPS — WebTunnel vía Nginx | Sí (si ejecutas WebTunnel) | Los pasos exactos dependen de tu router. El proceso general es este: **Reenvío de puertos en un router genérico** 1. **Entra en el panel de administración de tu router** (normalmente en `192.168.0.1` o `192.168.1.1`) 2. **Busca la sección de reenvío de puertos** (suele estar bajo "NAT", "Firewall" o "Port Forwarding") 3. **Crea reglas para cada puerto:** - **Puerto externo**: 9001 → **IP interna**: la IP de LAN de tu servidor → **Puerto interno**: 9001 - **Puerto externo**: 4443 → **IP interna**: la IP de LAN de tu servidor → **Puerto interno**: 4443 - **Puerto externo**: 443 → **IP interna**: la IP de LAN de tu servidor → **Puerto interno**: 443 (si no está ya reenviado) 4. **Guarda y aplica** los cambios. ### Firewall del servidor (UFW) Si usas UFW (Uncomplicated Firewall) en tu servidor: **Configurar UFW para los puertos del puente Tor** ```bash sudo ufw allow 9001/tcp comment "Tor ORPort" sudo ufw allow 4443/tcp comment "Tor obfs4 Bridge" # Port 443 is likely already open if you run Nginx sudo ufw allow 443/tcp comment "HTTPS" sudo ufw reload ``` Si usas `iptables` directamente: **Configurar iptables para los puertos del puente Tor** ```bash sudo iptables -A INPUT -p tcp --dport 9001 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 4443 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT ``` ### IPv6: sin NAT **Información — IPv6 es directo: sin reenvío de puertos** A diferencia de IPv4, las direcciones IPv6 son enrutables globalmente. Tu servidor ya es accesible directamente en su dirección IPv6: no hace falta NAT ni reenvío de puertos. Solo tienes que asegurarte de que las reglas del firewall de tu router **permitan** el tráfico entrante al ORPort (TCP 9001) hacia tu servidor. Si usas MikroTik, añade una regla en el firewall IPv6 que acepte tráfico TCP al puerto 9001 en la dirección de tu servidor. Comprueba que el puerto IPv6 está abierto: **Comprobar que el puerto IPv6 escucha y es accesible** ```bash # Verifica que Tor escuche en IPv6 ss -tlnp6 | grep 9001 # Prueba de accesibilidad IPv6 desde otra máquina nc -6zv TU_DIRECCIÓN_IPV6 9001 ``` --- ## Paso 6: configuración de AppArmor En sistemas Debian/Ubuntu, AppArmor puede restringir lo que Tor y obfs4proxy tienen permitido hacer. Hay que asegurarse de que el perfil de obfs4proxy permite la ejecución: **Configurar AppArmor para obfs4proxy** ```bash # Check if the profile exists sudo aa-status 2>/dev/null | grep obfs4proxy # If restricted, set to complain mode sudo aa-complain /usr/bin/obfs4proxy 2>/dev/null # Or create an explicit allow rule echo "/usr/bin/obfs4proxy mr," | sudo tee -a /etc/apparmor.d/local/system_tor sudo apparmor_parser -r /etc/apparmor.d/system_tor ``` --- ## Paso 7: iniciar y verificar **Arrancar el puente** 1. **Inicia Tor** **Reiniciar el servicio de Tor** ```bash sudo systemctl restart tor ``` 2. **Mira los logs para confirmar que el bootstrap ha ido bien** **Seguir el proceso de arranque de Tor** ```bash sudo journalctl -u tor -f --no-pager | head -30 ``` Busca estas líneas clave: **Salida de un bootstrap correcto** ```text Bootstrapped 0% (starting): Starting Bootstrapped 5% (conn): Connecting to a relay Bootstrapped 10% (conn_done): Connected to a relay Bootstrapped 14% (handshake): Handshaking with a relay Bootstrapped 15% (handshake_done): Handshake with a relay done Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Bootstrapped 95% (circuit_create): Establishing a Tor circuit Bootstrapped 100% (done): Done Self-testing indicates your ORPort 86.x.x.x:9001 is reachable from the outside. Excellent. Registered server transport 'obfs4' at '0.0.0.0:4443' Registered server transport 'webtunnel' at '127.0.0.1:15000' ``` 3. **Comprueba que los tres procesos están en ejecución** **Comprobar que Tor, obfs4proxy y webtunnel-server están en ejecución** ```bash ps aux | grep -E "(tor|obfs4|webtunnel)" | grep -v grep ``` Deberías ver tres procesos: `tor`, `obfs4proxy`, y `webtunnel-server`. 4. **Comprueba que todos los puertos están en escucha** **Comprobar los puertos en escucha del puente Tor** ```bash ss -tlnp | grep -E "(:443|9001|4443|15000|9051|9052)" ``` **Salida — Puertos que deberían estar en escucha** ```text LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=...,fd=...)) LISTEN 0 4096 0.0.0.0:9001 0.0.0.0:* users:(("tor",pid=...,fd=...)) LISTEN 0 4096 0.0.0.0:4443 0.0.0.0:* users:(("obfs4proxy",pid=...,fd=...)) LISTEN 0 4096 127.0.0.1:15000 0.0.0.0:* users:(("webtunnel-ser",pid=...,fd=...)) LISTEN 0 4096 127.0.0.1:9051 0.0.0.0:* users:(("tor",pid=...,fd=...)) LISTEN 0 4096 0.0.0.0:9052 0.0.0.0:* users:(("tor",pid=...,fd=...)) ``` 5. **Recupera la huella digital de tu puente** **Obtener la huella digital del puente** ```bash cat /var/lib/tor/fingerprint ``` ### Comprobar la accesibilidad externa Desde otra máquina (o con un comprobador de puertos online), comprueba que tus puertos son accesibles: **Probar la accesibilidad del ORPort desde otra máquina** ```bash # From another machine: nc -zv YOUR_PUBLIC_IP 9001 nc -zv YOUR_PUBLIC_IP 4443 curl -I https://your-domain.com/ ``` **Consejo — El autotest del ORPort** Tor hace su propio autotest de accesibilidad durante el bootstrap. Si ves `Self-testing indicates your ORPort is reachable from the outside`, todo va bien. Si el autotest falla, revisa otra vez las reglas de reenvío de puertos y la configuración del firewall. --- ## Paso 8: monitorización con Prometheus y Grafana Tor expone un conjunto muy completo de métricas por su `MetricsPort` en formato Prometheus. Con ellas puedes vigilar en tiempo real el uso de ancho de banda, las conexiones, la construcción de circuitos y la salud del relé. ### Configurar el scraping de Prometheus Añade un target de scrape para tu puente Tor en la configuración de Prometheus: **Fichero: `prometheus.yml` (fragmento)** ```yaml scrape_configs: - job_name: 'tor-bridge' scrape_interval: 30s scrape_timeout: 10s metrics_path: '/metrics' static_configs: - targets: ['YOUR_SERVER_IP:9052'] labels: instance: 'tor-bridge' nickname: 'YourBridgeName' ``` **Información — Firewall para el puerto de métricas** El MetricsPort (9052) solo debe ser accesible desde tu servidor de monitorización, nunca desde la Internet pública. Usa `MetricsPortPolicy accept YOUR_MONITORING_IP/32` en el `torrc` y restringe el acceso también en el firewall: **Restringir el MetricsPort al servidor de monitorización** ```bash sudo ufw allow from YOUR_MONITORING_IP to any port 9052 proto tcp \ comment "Prometheus: Tor Bridge Metrics" ``` ### Métricas clave que vigilar Tor expone decenas de métricas de Prometheus. Estas son las más importantes para quien opera un puente: **Métricas esenciales de Prometheus en Tor** | Métrica | Tipo | Lo que te dice | | --- | --- | --- | | `tor_relay_connections_total` | Counter | Conexiones totales por tipo y sentido (entrantes/salientes, OR/directorio) | | `tor_relay_traffic_bytes` | Counter | Bytes leídos y escritos en total — tu aportación de ancho de banda a la red | | `tor_relay_flag` | Gauge | Flags de directorio asignados a tu relé (Stable, Running, Valid, etc.) | | `tor_relay_circuits_total` | Gauge | Número de circuitos activos por estado (abiertos, cerrados, etc.) | | `tor_relay_streams_total` | Counter | Streams procesados — una aproximación a las conexiones reales de usuarios | | `tor_relay_load_oom_bytes_total` | Counter | Eventos de falta de memoria — si sube, añade más RAM | | `tor_relay_load_tcp_exhaustion_total` | Counter | Agotamiento de puertos TCP — si sube, ajusta los parámetros de red del kernel | | `process_resident_memory_bytes` | Gauge | RAM que usa ahora mismo el proceso Tor | | `process_cpu_seconds_total` | Counter | Tiempo de CPU consumido por Tor | ### Panel de Grafana Puedes montar un panel de Grafana bastante completo con gráficas para: 1. **Ancho de banda** — `rate(tor_relay_traffic_bytes[5m])` — throughput de entrada y salida en tiempo real 2. **Conexiones** — `tor_relay_connections_total` por tipo — quién se está conectando 3. **Flags del relé** — `tor_relay_flag` — ¿ha reconocido la red tu puente? 4. **Circuitos** — `tor_relay_circuits_total` — cuántos circuitos hay activos 5. **Recursos del sistema** — `process_resident_memory_bytes`, `process_cpu_seconds_total` 6. **Salud** — `tor_relay_load_oom_bytes_total`, `tor_relay_load_tcp_exhaustion_total` **Consejo — Cronología de los flags del relé** Después de arrancar el puente, los flags van apareciendo poco a poco: - **Running**: ~1 hora después de iniciar - **Valid**: ~1 hora - **Stable**: ~7 días de funcionamiento ininterrumpido - **Guard**: ~8 días (si procede) Ten paciencia: las autoridades de directorio de Tor tardan en confiar en un relé nuevo. Mantén el puente en marcha sin interrupciones y los flags acabarán llegando. ### Nyx: monitorización desde el terminal [Nyx](https://nyx.torproject.org/) es una interfaz de terminal para vigilar Tor en tiempo real. Se conecta al ControlPort y muestra gráficas de ancho de banda, conexiones, circuitos y configuración. **Instalar y ejecutar Nyx** ```bash sudo apt install -y nyx sudo -u debian-tor nyx ``` --- ## Paso 9: integración con CrowdSec (si aplica) Si ejecutas [CrowdSec](https://www.crowdsec.net/) en el mismo servidor (algo habitual si ya tienes Nginx), te vas a encontrar con un problema: CrowdSec está diseñado para bloquear IPs maliciosas, pero **los clientes del puente Tor disparan falsos positivos**. Tu propio IDS puede acabar bloqueando a usuarios legítimos de Tor que se conectan a tu puente. **Advertencia — El problema** El bouncer de firewall de CrowdSec añade una `CROWDSEC_CHAIN` al principio de tu cadena INPUT de iptables, y el bouncer de Nginx contrasta cada petición con una lista de bloqueos. Cualquiera de los dos puede bloquear sin querer a clientes legítimos del puente Tor. La solución es un **bypass de tres capas** que garantiza que el tráfico de Tor no se bloquee nunca: ### Capa 1: iptables — esquivar el bouncer de firewall Inserta reglas ACCEPT para los puertos concretos de Tor **antes** de la CROWDSEC_CHAIN: **Añadir reglas de bypass en iptables para los puertos de Tor** ```bash # IPv4 sudo iptables -I INPUT 1 -p tcp --dport 4443 -j ACCEPT # obfs4 sudo iptables -I INPUT 1 -p tcp --dport 9001 -j ACCEPT # ORPort # IPv6 sudo ip6tables -I INPUT 1 -p tcp --dport 4443 -j ACCEPT sudo ip6tables -I INPUT 1 -p tcp --dport 9001 -j ACCEPT ``` **Información — ¿Por qué no el puerto 443?** El puerto 443 lo comparten todos tus servicios HTTPS, no solo Tor. Saltarse CrowdSec para **todo** el tráfico HTTPS abriría un agujero de seguridad. El bypass de WebTunnel en el puerto 443 se resuelve en Nginx (capa 2), donde sí podemos filtrar por nombre de dominio. ### Capa 2: Nginx — esquivar el bouncer Lua Si el bouncer de Nginx de CrowdSec usa un `rewrite_by_lua_block` a nivel de `http {}`, añade una excepción para tu dominio de Tor: **Fichero: `/etc/nginx/conf.d/crowdsec_nginx.conf` (sección modificada)** ```lua rewrite_by_lua_block { local cs = require "plugins.crowdsec.lib.crowdsec" -- Bypass CrowdSec for Tor bridge domain if ngx.var.host == "your-tor-domain.com" then -- Skip CrowdSec check entirely for Tor bridge traffic else local ok, err = cs.Allow(ngx.var.remote_addr) if not ok then ngx.exit(ngx.HTTP_CLOSE) end end } ``` ### Capa 3: lista blanca en el parser de CrowdSec Aun con lo anterior, CrowdSec seguirá **analizando** tus logs de Tor y puede generar decisiones locales. Crea una lista blanca en el parser para que ignore todo el tráfico hacia tu dominio de Tor: **Fichero: `/etc/crowdsec/parsers/s02-enrich/tor-bridge-whitelist.yaml`** ```yaml name: custom/tor-bridge-whitelist description: "Ignore all traffic to the Tor bridge domain" whitelist: reason: "Tor bridge traffic — legitimate by definition" expression: - evt.Parsed.target_fqdn == 'your-tor-domain.com' ``` Para que CrowdSec detecte el `target_fqdn`, tus logs de Nginx tienen que incluir la variable `$host`. Crea un formato de log propio: **Fichero: `/etc/nginx/conf.d/tor_log_format.conf`** ```nginx # Log format with vhost prefix for CrowdSec target_fqdn detection log_format combined_vhost '$host $remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; ``` Después úsalo en el bloque de servidor de Tor: ```nginx access_log /var/log/nginx/tor.access.log combined_vhost; ``` Tras cualquier cambio, recarga los dos servicios: **Recargar CrowdSec y Nginx** ```bash sudo systemctl reload crowdsec sudo systemctl reload nginx ``` ### Persistir las reglas de iptables tras un reinicio Las reglas de bypass de iptables se pierden al reiniciar. Crea un servicio systemd que las vuelva a aplicar: **Fichero: `/etc/systemd/system/tor-bypass-crowdsec.service`** ```ini [Unit] Description=Tor Bridge — iptables bypass for CrowdSec After=crowdsec-firewall-bouncer.service Wants=crowdsec-firewall-bouncer.service [Service] Type=oneshot RemainAfterExit=yes # IPv4: Accept Tor traffic before CROWDSEC_CHAIN ExecStart=/bin/sh -c '\ iptables -C INPUT -p tcp --dport 4443 -j ACCEPT 2>/dev/null || \ iptables -I INPUT 1 -p tcp --dport 4443 -j ACCEPT; \ iptables -C INPUT -p tcp --dport 9001 -j ACCEPT 2>/dev/null || \ iptables -I INPUT 1 -p tcp --dport 9001 -j ACCEPT' # IPv6: Same rules ExecStart=/bin/sh -c '\ ip6tables -C INPUT -p tcp --dport 4443 -j ACCEPT 2>/dev/null || \ ip6tables -I INPUT 1 -p tcp --dport 4443 -j ACCEPT; \ ip6tables -C INPUT -p tcp --dport 9001 -j ACCEPT 2>/dev/null || \ ip6tables -I INPUT 1 -p tcp --dport 9001 -j ACCEPT' [Install] WantedBy=multi-user.target ``` **Habilitar el servicio que persiste las reglas de iptables** ```bash sudo systemctl daemon-reload sudo systemctl enable --now tor-bypass-crowdsec.service ``` --- ## Descripción general de la arquitectura Esta es la arquitectura completa de lo que has montado: **Arquitectura completa del puente Tor (dual-stack IPv4 + IPv6)** ```mermaid flowchart TB subgraph Internet["🌍 Censored Users"] User1["Tor Client