Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon WebTunnels de Tor: otra forma de evitar la censura

viernes, 29 de noviembre de 2024 | Publicado por el-brujo | Editar entrada

En un esfuerzo por combatir la censura en internet y promover una experiencia en la red personalizada y privada, Tor ha lanzado su más reciente innovación: WebTunnel. Esta nueva configuración puente, incorporada en su última versión estable, está diseñada para ayudar a los usuarios en regiones represivas al simular tráfico HTTPS, facilitando la evasión de las restricciones sin ser detectados.



WebTunnel surge como respuesta a las limitaciones impuestas en varios países hacia Tor, una herramienta que permite el acceso a la web oscura y que ha sido prohibida en múltiples regiones debido al tráfico de internet peculiar que genera. Tradicionalmente, las capas de cifrado aplicadas por Tor para proteger los datos de los usuarios hacen que el tráfico sea fácilmente identificable para las autoridades, debido a su aspecto fuertemente ofuscado. Sin embargo, WebTunnel busca cambiar esta situación al mimetizar el tráfico de Tor con el tráfico HTTPS común, haciendo casi imposible su detección por parte de regímenes opresivos.

La tecnología detrás de WebTunnel envuelve la conexión de carga útil en una conexión HTTPS tipo WebSocket, apareciendo ante los observadores de la red como una conexión HTTPS (WebSocket) ordinaria. Tor garantiza que la similitud con el tráfico HTTPS es tal que puede coexistir con un sitio web en el mismo punto de red, permitiendo que un proxy inverso de tráfico estándar redirija tanto el tráfico convencional como el WebTunnel a los respectivos servidores de apl

Cómo funciona

WebTunnel funciona envolviendo la carga útil de la conexión en una conexión HTTPS similar a WebSocket. Para un observador externo el tráfico es indiscernible del que generaría un usuario que estuviese visitando una página web convencional.

Esto es de especial utilidad en situaciones en las que el censor trabaja con una lista de protocolos permitidos y bloquea todos los demás. En un entorno de estas características otro tipo de puente, como obfs4, no conseguiría evitar el filtrado.

Cómo utilizarlo

Aunque planean incluir más métodos de distribución en el futuro, por el momento WebTunnel sólo se pueden encontrar en la web de Tor Project.

Paso 1 — Obtener el puente WebTunnel

  • Utilizando un navegador cualquiera visitar el sitio https://bridges.torproject.org/options
  • En “Advanced Options” seleccionar webtunnel y hacer click en “Get Bridges”.
  • Resolver el captcha.
  • Copiar la línea que se proporciona.


Paso 2 — Descargar e instalar el navegador Tor

  • Descargar e instalar el navegador Tor para escritorio.
  • Abrir el navegador, ir a las preferencias de conexión.
  • Hacer click en “Add a Bridge Manually” y añadir la línea copiada en el paso 1.
  • Cerrar el cuadro de diálogo y hacer click en “Connect”.

Otra forma de obtener puentes es enviar un correo electrónico a bridges@torproject.org. Deja el asunto del correo en blanco y escribe "get transport obfs4" en el cuerpo del mensaje. Ten en cuenta que debes enviar el correo electrónico desde una dirección de uno de los siguientes proveedores: Riseup o Gmail.


Obtener puentes a través de Telegram

Envía un mensaje a @GetBridgesBot en Telegram. Toca en 'Start' o escribe /start o /bridges en el chat. Copia las direcciones de los puentes.

El objetivo de Tor Project es asegurarse de que su red sea accesible para todo el mundo.

En momentos en que conflictos geopolíticos ponen a millones de personas en riesgo, Internet es crucial para comunicarnos, compartir y ser testigos de lo que sucede en el mundo, organizarnos, defender los derechos humanos, y construir redes de solidaridad.

Desde la organización se recuerda que la contribución de los voluntarios es vital para la continuidad del proyecto.


Actualmente hay cuatro transportes enchufables disponibles, pero se están desarrollando más.

  • obfs4 hace que el tráfico Tor parezca aleatorio, y también evita que los censores encuentren los puentes escaneando Internet. los puentes obfs4 son menos propensos a ser bloqueados que sus predecesores, los puentes obfs3.
  • meek transports hace que parezca que está navegando por un sitio web importante en lugar de usar Tor. meek-azure hace que parezca que está usando un sitio web de Microsoft.
  • Snowflake enruta su conexión a través de proxies operados por voluntarios para que parezca que está haciendo una videollamada en lugar de usar Tor.
  • WebTunnel enmascara su conexión Tor, haciendo que parezca que está accediendo a un sitio web a través de HTTPS. 


Traducción realizada con la versión gratuita del traductor DeepL.com

Instalación de Webtunnel para servidores

WebTunnel es un puente de transporte conectable (PT) para el ecosistema Tor. Es un proxy resistente a la censura que intenta imitar el tráfico HTTPS.

Pasos para la instalación y puesta en marcha de un puente Webtunnel

  1. Requerimientos previos
  2. Instalación de software
  3. Configuración
  4. Inicio de la aplicación Webtunnel en un contenedor
  5. Actualización

1. Requerimientos previos

  • Dominio de internet con sus DNS habilitados
  • Una máquina virtual o dedicada con Debian 11 o 12
  • Dirección IP pública

2. Instalación de software

  • Docker CE
  • Cerbot
  • Nginx
Instalación de docker
sudo apt install curl
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh ./get-docker.sh'

Instalación de cerbot

sudo apt install certbot
Instalación de nginxs

udo apt install nginx python3-certbot-nginx

3. Configuración

  • Creación de certificados
  • Configuración del servidor nginx
  • Crear el archivo de configuración .env para docker-compose.yml
Creación de certificados

Antes de proceder a la creación de los certificados con Certbot es necesario agregar a los DNS de nuestro dominio el registro A necesario para que el dominio apunte a la dirección IP de nuestra máquina.

sudo certbot --nginx -d mydominio.org

Configuración del servidor nginx

Configuración de reenvío de http para el dominio en /etc/nginx/site-enabled/default

Reemplace $PATH con una cadena aleatoria que se genera con el siguiente comando:


echo $(cat /dev/urandom | tr -cd "qwertyuiopasdfghjklzxcvbnmMNBVCXZLKJHGFDSAQWERTUIOP0987654321"|head -c 24)

Agregamos el siguiente bloque de configuración al archivo /etc/nginx/site-enabled/default



server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name $SERVER_ADDRESS;
    #ssl on;

    # certificates generated via acme.sh
    ssl_certificate /root/.acme.sh/DOMAIN_ecc/fullchain.cer;
    ssl_certificate_key /root/.acme.sh/DOMAIN_ecc/DOMAIN.key;

    ssl_session_timeout 15m;

    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:MozSSL:50m;
    #ssl_ecdh_curve secp521r1,prime256v1,secp384r1;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000" always;
    
    location = /$PATH {
        proxy_pass http://127.0.0.1:15000;
        proxy_http_version 1.1;

        ### Set WebSocket headers ###
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        ### Set Proxy headers ###
        proxy_set_header        Accept-Encoding   "";
        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;
        add_header              Front-End-Https   on;

        proxy_redirect     off;
        access_log  off;
        error_log off;
    }

}
Apache:

<VirtualHost *:443>
    ServerName [[HOST_NAME]]

    Protocols http/1.1 h2

    SSLEngine on

    # Certificates generated via acme.sh
    SSLCertificateFile /root/.acme.sh/DOMAIN_ecc/fullchain.cer
    SSLCertificateKeyFile /root/.acme.sh/DOMAIN_ecc/DOMAIN.key

    SSLProtocol TLSv1.2 TLSv1.3
    SSLSessionCacheTimeout 900

    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

    ProxyPreserveHost On
    ProxyRequests off

    Header always set Strict-Transport-Security "max-age=63072000"

    <Location /[[SECRET_PATH]]>
        # This lets Apache set the "X-Forwarded-For", "X-Forwarded-Host" and
        # "X-Forwarded-Server" HTTP headers automatically if enabled (Default is 'On').
        # "X-Forwarded-For" is set manually below to avoid the other two
        # headers provided by this directive that we don't need.
        ProxyAddHeaders Off

        # Set Proxy headers
        RequestHeader unset Accept-Encoding
        RequestHeader set X-Real-IP         "%{REMOTE_ADDR}s"
        RequestHeader set X-Forwarded-For   "%{REMOTE_ADDR}s"
        RequestHeader set X-Forwarded-Proto "%{REQUEST_SCHEME}s"
        Header        set Front-End-Https   on

        ProxyPass "ws://127.0.0.1:15000/%{REQUEST_URI}s"
        ProxyPassReverse "ws://127.0.0.1:15000%{REQUEST_URI}s"
    </Location>

    ErrorLog off
</VirtualHost>

Docker

Descarga del archivo docker-compose.yml

curl https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/raw/main/release/container/docker-compose.yml?inline=false > docker-compose.yml

Creamos en el mismo directorio el archivo .env

truncate --size 0 .env

Agregamos las siguientes variables de configuración. Esto creará un archivo de entorno para la configuración del puente.

Variable de nombre de dominio o subdominio. Tendremos que cambiar el nombre de dominio o subdominio que dispongamos para nuestro puente

echo "URL=https://mydominio.org/$path" >> .env

Variable de dirección de correo electrónica que estará asociada a nuestro puente

echo "OPERATOR_EMAIL=your@email.org" >> .env

Agregamos nombre del puente

echo "BRIDGE_NICKNAME=WTBr$(cat /dev/urandom | tr -cd 'qwertyuiopasdfghjklzxcvbnmMNBVCXZLKJHGFDSAQWERTUIOP0987654321'|head -c 10)" >> .env

Agregamos número de puerto

echo "GENEDORPORT=4$(cat /dev/urandom | tr -cd '0987654321'|head -c 4)" >> .env

4. Inicio de la aplicación Webtunnel en un contenedor

Una vez que tenemos nuestro .env con las variables completas iniciamos nuestra aplicación con docker compose. Para así ejecutar la aplicación Webtunnel en un contenedor dentro de nuestra máquina.

docker compose up -d

Ahora podemos comprobar que nuestro puente Webtunnel se está funcionando adecuadamente

docker compose exec webtunnel-bridge get-bridge-line.sh

5. Actualización

Para mantener actualizado el software por medio de docker compose. Utiliza los siguientes comandos

docker compose pull
docker compose up -d

Renovación de certificados

Vía:

Etiquetas: , , , , , ,

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.