Configuración de un proxy en LAN/WLAN

Un proxy es, en el más sentido estricto de la palabra, un intermediario, si suponemos que es un programa o dispositivo que actúa de intermediario (en una red de ordenadores) entre un servidor, siendo éste el objetivo de la otra parte, en este caso, el cliente.

Suponiendo el caso que tengamos tres máquinas, vamos a acuñar el nombre de máquina A al cliente, B para el Proxy y C para el servidor. El cliente (A) desea conectarse al servidor (C) como normalmente se haría, pero antes de que la petición pueda llegar a su destinatario, ésta pasa hacia el Proxy (B) y de este último al servidor.

Esquema de un proxy

Sus usos son relativos a cada cliente, pero entre los más caprichosos podríamos mencionar necesidades de lo más variopintas:

• Cortafuegos: Se podría decir de cierta forma, que este uso es muy habitual si se desea bloquear tráfico indeseado o prevenir ataques perpetuados por el malware. Además que de esta medida también se podría usar como filtro para sitios publicitarios.
• Filtración del contenido: En una empresa regularmente se dispone de este tipo de uso para bloquear el tráfico saliente generado por los empleados. Esto puede ser muy útil para prevenir cualquier tipo de distracción o, inclusive, se podría decir que podría mejorar la seguridad.
• Aceleración y ahorro de ancho de banda: Ya sea que estemos usando un navegador o cualquier otro software que tenga la posibilidad de conectarse a otra máquina (a través de Internet o Intranet, por ejemplo), es muy útil guardar datos como imágenes, vídeos, y misceláneas, como lo pueden ser los archivos usados mayormente en los sitios web: HTML, CSS, JS, etc.; esta característica para ahorrar y acelerar la trae con sí cualquier navegador decente, pero muy útil igualmente cuando no, o es otro software de diferente índole.
• Control de acceso: En la administración de ordenadores en una empresa, instituciones y sitios gubernamentales, es muy útil ser permisivos con determinados usuarios o restringir el uso de cada quien, para regular la información que se comparte entre sí. No obstante, la regulación de la información no es el único fin, se podría decir que para usar que sean provistos ciertos servicios es necesario el uso de un proxy.
• Anonimato y privacidad: En algunos países donde la información que se comparte puede ser restringida de forma arbitraria, ya sea por un gobierno o un ISP, los proxies son muy útiles para evadir la censura.

Dante & Stunnel:

SOCKS es un protocolo de Internet para el intercambio de paquetes a través de un servidor proxy. La naturaleza del protocolo brinda versatilidad para crear todo tipo de herramientas de enrutamiento, y también es muy útil para otros objetivos, como ser una precisa herramienta para la elusión, que permite evadir el filtrado de Internet para acceder a contenidos bloqueados por gobiernos, lugares de trabajo, escuelas y dependiendo del caso, acceder a servicios específicos de una nación.

Dante es eso, un servidor proxy que usa SOCKS como protocolo. Este software es muy simple, pero totalmente funcional, y si se combina con Stunnel aumentaría el poderío de cualquier individuo que busque un buen equilibrio entre privacidad y seguridad.

Instalación de Dante:

Usando nuestro gestor de paquetes apt, y aclarando que el sistema se debe encontrar actualizado, vamos a instalar el paquete dante-server.

sudo apt-get install dante-server

Instalación de dante-server

Una vez finalizado, debemos configurarlo.

Configuración de Dante

Editando el archivo de configuración de danted

Primero que nada, vamos a editar el archivo de configuración de danted, pero para simplificar aún más este artículo, vamos a agregar el siguiente extracto de configuración muy elemental:

logoutput: /var/log/socks.log
internal: 127.0.0.1 port = 1080
external: eth0
clientmethod: none
socksmethod: none
user.privileged: root
user.notprivileged: nobody

# Permitir conexiones localhost (stunnel)
client pass {
        from: 127.0.0.1/32 to: 127.0.0.1/32
}

# Bloquear y registrar el resto de intentos de conexión
client block {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}

# Bloquear el acceso de los clientes a los servicios localhost
socks block {
        from: 0.0.0.0/0 to: lo
        log: connect error
}

# Permitir a los clientes acceso al exterior - tcp 80 utilizando el método "connect"
socks pass {
        from: 127.0.0.1/32 to: 0.0.0.0/0 port = 80
        command: connect
        protocol: tcp
}

# Permitir a los clientes acceso al exterior - tcp 443 utilizando el método "connect"
socks pass {
        from: 127.0.0.1/32 to: 0.0.0.0/0 port = 443
        command: connect
        protocol: tcp
}

# Bloquear y registrar todos los demás intentos de clientes
socks block {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}

logoutput

Este valor controla la salida del servidor de los registros.

internal

Toda dirección y sólo en esta dirección, que provenga de ésta o una interfaz, será aceptada.

external

Esta será la dirección o la interfaz de salida, y es importante que, si es que lo deseamos, nos brinde la conexión a Internet.

clientmethod

Exigir que la conexión se "autentique" utilizando uno de los métodos apropiados.

socksmethod

Si el cliente ofrece más de un método de autenticación, Dante seleccionará el método a utilizar en función del orden en que los métodos son listados aquí.

user.privileged

Nombre de usuario para realizar ciertas operaciones con privilegios.

user.notprivileged

Usuario que el servidor ejecuta la mayor parte del tiempo. Éste debe tener un ID con tan pocos privilegios como sea posible.


Si es necesario realizar operaciones mucho más complejas de las que se muestran acá se pueden apreciar mejor en la propia documentación de Dante.

Uso de dante:

Ya concluida su configuración, es necesario activar el servicio, que si resulta satisfactoria su ejecución, podremos conectarnos a él por el puerto 1080, que, si no se es sabido, es el puerto estándar de los servidores proxy SOCKS.

sudo service danted start

Iniciando el servicio danted

Una el servicio se inicia, es hora de probarlo, y para ello, podemos usar la herramienta CURL, que si bien, en la mayoría de distribuciones se tiene preinstalada, puede que esta o la del lector no, así que con el siguiente comando es posible instalarlo:

sudo apt-get install curl

Instalación del paquete CURL

En mi distribución está la versión más reciente de CURL.

Una vez que se ha instalado, es posible ver nuestra dirección IP pública, aunque aclarando que sin importar (para este caso) si se usa o no un proxy, se obtendrá la misma, pero el objetivo de esto es verificar si podemos conectar con el proxy que hemos configurado.

curl -x "socks5h://127.0.0.1:1080" https://ifconfig.me && echo

Probando la conectividad del proxy

Nota: No hace falta aclarar el porqué de ocultar la dirección IP pública.

Si bien, y como se aclaró, usando o no el proxy se obtendrá el mismo resultado, pero suponiendo el caso de que el servicio no se haya iniciado por cualquier situación, podríamos comprobarlo de la siguiente manera.

sudo service danted stop
curl -x "socks5h://127.0.0.1:1080" https://ifconfig.me && echo

Fallo de la conexión

Como se puede apreciar, no indica que ifconfig.me ha fallado, más bien indica que el proxy lo ha hecho, por lo que para cerciorarnos es de esta manera.

No todo es color de rosas, y es que con un sniffer decente es todavía posible observar el contenido que se comparte entre el cliente y el servidor SOCKS, como se puede apreciar en la siguiente figura usando Wireshark.

Usando Wireshark para ver el contenido que se comparte un cliente y un servidor

Esto es sumamente peligroso si se desea compartir datos confidenciales, pero afortunadamente hay soluciones.

Instalación de Stunnel:

Stunnel se utiliza mayormente para proveer conexiones seguras a clientes que no propician TLS o SSL de forma nativa. Es posible ejecutarlo en una variedad de sistemas, usa criptografía clave pública y entre otras características igual de excelentes que las antes mencionadas.

Al inicio de su ejecución puede presentar un puerto externo seguro que es mapeado a un puerto TCP o UDP no seguro perteneciente a la aplicación objetivo.

Suponiendo el primer caso más trivial donde se desee implementar una conexión SSL segura a una conexión hacia un servidor inseguro, siendo éste un servidor SMTP, Stunnel mapeará el puerto 443 al puerto 25 del servidor de correo. Inicialmente el tráfico generado por los clientes que se conecten a través del proxy deberá pasar a través del puerto 443 y a su vez Stunnel lo redireccionará al 25. Stunnel puede ser ejecutado en el mismo servidor donde se mantenga en ejecución a la aplicación de correo, que aunque esta última no disponga de protección concienzuda, los dos programas serán ejecutados en un firewall interno seguro, además que todo este proceso será transparente.

Para poder instalar Stunnel, con un simple comando es posible:

sudo apt-get install stunnel4

Instalación del paquete stunnel4

Configuración de Stunnel:

Antes de iniciar la configuración, debemos agregar la marca de orden de bytes, algo requerido por el mismo dante, y para aclarar un poco más, se especificará que la codificación unicode en este caso será en UTF-8, como lo indica la siguiente figura.

Marca de orden de bytes

Para ello, es necesario primero cambiar de el usuario actual al usuario root.

sudo su
echo -e '\xef\xbb\xbf; BOM composed of non printable characters. It is here, before the semicolon!' > /etc/stunnel/stunnel.conf
exit # Salimos

Iniciando la configuración de stunnel

Es indispensable escribir en la línea 2 del archivo de configuración, y si el lector es olvidadizo, ese es el objetivo del comentario «BOM composed of non printable characters. It is here, before the semicolon!».

Simplificando, aquí una configuración para el correcto y básico funcionamiento de Stunnel:

setuid = stunnel4
setgid = stunnel4

[trivial server]
accept      = 1081
connect     = 127.0.0.1:1080
ciphers     = PSK
debug       = 3
PSKsecrets  = /etc/stunnel/psk.txt
setuid      = stunnel4
setgid      = stunnel4

Configuración de stunnel

setuid

Como opción global: setgid() al grupo especificado en modo daemon y borrar todos los demás grupos.
Como opción de nivel de servicio: establezca el grupo del socket Unix especificado con "accept". setuid = USER (solo Unix)

setgid

Como opción global: setuid() al usuario especificado en modo daemon.
Como opción de nivel de servicio: establezca el propietario del socket Unix especificado con "accept".

accept

Aceptar conexiones en la dirección especificada.
Si no se especifica ningún host, el valor predeterminado es todas las direcciones IPV4 para el host local.
Para escuchar en todas las direcciones IPV6 se debe utilizar:

accept = :::PORT

connect

conectarse a una dirección remota
Si no se especifica ningún host, el valor predeterminado del host es localhost.
Se permiten varias opciones de conexión en una sola sección de servicio.
Si el host se resuelve en varias direcciones y/o si se especifican varias opciones de conexión, la dirección remota se elige mediante un algoritmo round robin.

ciphers

seleccionar cifrados TLS permitidos (TLSv1.2 y inferiores)
Esta opción no afecta a los cifrados TLSv1.3.
Una lista delimitada por dos puntos de los cifrados para permitir en la conexión TLS, por ejemplo DES-CBC3-SHA:IDEA-CBC-MD5.

debug

El nivel es uno de los nombres o números de nivel syslog o números, emerg(0), alert(1), crit(2), err(3), warning(4), notice(5), info(6) o debug(7). Se mostrarán todos los registros para el nivel especificado y todos los niveles numéricamente inferiores a los que se mostrarán. Utilice debug = debug o debug = 7 para la mayor salida de depuración. El valor predeterminado es notice(5).

PSKsecrets

archivo con identidades PSK y claves correspondientes
Cada línea del archivo en el siguiente formato:

IDENTITY:KEY

Las claves hexadecimales se convierten automáticamente en forma binaria. Las claves deben tener al menos 16 bytes de longitud, lo que implica al menos 32 caracteres para claves hexadecimales. El archivo no debe ser legible en para todo el mundo ni grabable para cualquiera.

Todo lo mostrado en esta sección es lo elemental, pero si se requiere ir más allá y extrapolar conceptos, no hay mejor que leer la propia documentación.

Uso de Stunnel:

Es necesario primero, generar la clave precompartida, cosa posible con openssl, que podría o no estar instalado, de cualquier modo, es sencillamente instalable con el siguiente comando:

sudo apt-get install openssl

Acto seguido, vamos a generar la susodicha clave:

sudo su
openssl rand -base64 -out /etc/stunnel/psk.txt 180
sed --in-place '1s/^/psk:/' /etc/stunnel/psk.txt
cat /etc/stunnel/psk.txt | tr -d "\n" > /etc/stunnel/psk.1.txt
mv /etc/stunnel/psk.1.txt /etc/stunnel/psk.txt
chmod 600 /etc/stunnel/psk.txt
exit

La explicación es sumamente sencilla: primero generamos 180 bytes de números pseudo aleatorios codificados a base64, acto seguido, le agregamos como prefijo psk a la cadena anteriormente generada, siendo en realidad un valor arbitrario, luego se eliminan todos los caracteres de nueva línea, pero el archivo resultante será nombrado como psk.1.txt para que no quede vacío por un conflicto entre dos flujos, aunque después éste remplaza al original, se le asignan los permisos correctos (en este caso, 600) y salimos.

A partir de este momento, es necesario, primero, compartir la clave precompartida a los clientes, e iniciar el servicio stunnel4.

Para seguir con el ejemplo, se usará Arch Linux como cliente. Aunque como no se desea que terceros puedan ver la clave, es mejor usar herramientas parecidas a scp, o el mismísimo en este caso:

sudo scp /etc/stunnel/psk.txt dtxdf@192.168.1.104:/tmp

Transfiriendo la clave de forma segura

sudo mv /tmp/psk.txt /etc/stunnel

Luego el cliente debe agregar el archivo de configuración de stunnel para poder realizar la conexión con el servidor, y los diversos servicios.

; BOM composed of non printable characters. It is here, before the semicolon!

setuid = stunnel
setgid = stunnel

[trivial client]
client     = yes
accept     = 127.0.0.1:1080
connect    = 192.168.1.106:1081
debug      = 3
PSKsecrets = /etc/stunnel/psk.txt
setuid     = stunnel
setgid     = stunnel

Cabe aclarar que, al igual que el servidor, se debe agregar al inicio del archivo el BOM.

Por supuesto, que la configuración cambia entre sistemas, pero para este caso será de la manera plasmada anteriormente. Una vez que se han escrito los cambios del archivo de configuración, se debe iniciar el servicio, que en Arch es llamado sockd:

sudo systemctl start stunnel

Iniciando stunnel en la máquina cliente

No podemos ultimar esta sección sin antes haber probado y verificado que el resultado es digno de agradecimiento.

curl -x "socks5h://127.0.0.1:1080" http://ifconfig.me && echo

Wireshark analizando tráfico encriptado

No importa qué paquete veamos, todo está encriptado, por lo que nuestra configuración ha sido satisfactoriamente ejecutada.

Autenticación segura con Stunnel y Dante:

Un efecto posiblemente indeseado sea el de no querer que todo el mundo use del proxy, por lo que agregando una medida extra podría evitar éso. Efectivamente se haría con un simple cambio en la configuración y reiniciando el servicio.

socksmethod: username

¡Listo! Ya se podría usar la autenticación, que, si no se sabe ni cómo generar usuarios, pues vienen siendo los mismos del sistema. Y que lo diga mejor el código:

sudo adduser proxy_user
sudo passwd proxy_user

Agregando al usuario proxy_user

El cliente ahora, si desea ingresar, debe iniciar sesión desde su programa-cliente, en este caso CURL.

curl -x "socks5h://proxy_user:123@127.0.0.1:1080" http://ifconfig.me && echo

Aumentando la privacidad, seguridad y evadiendo restricciones: Tor:

La red Tor, esa fascinante red que nos provee una capa extra de seguridad en nuestras comunicaciones. Una red capaz de evadir la censura más torturadora para una persona que reside en un país donde la libertad de expresión es nula o inimaginable. Tor (siglas de The Onion Router), es un proyecto cuyo principal objetivo es desarrollar una red distribuida de baja latencia, superpuesto sobre Internet donde el encaminamiento de mensajes no revela la identidad del usuario.

La red tor

Tor implementa una técnica llamada encaminamiento cebolla, o del inglés, onion routing, técnica usada conseguir que las redes preserven su privacidad de forma transparente con los individuos de la red, por ende, es viable realizarlo de forma pública.

Por lo general, cuando un cliente desea conectarse a un servidor de la manera tradicional, la petición pasa a través del router, a su vez ésta a los enrutadores del ISP, y por último, al servidor objetivo.

Por supuesto, que es posible que un tercero puede leer lo que transferimos, y aunque lo cifraramos desde el origen, podrían residir datos que nos puedan identificar.

La solución ante tal hecho, es usar la susodicha técnica. En vez de que el paquete pase por una vía directa, es mejor que viaje por una no directa y más o menos aleatoria a través de los nodos de la red.

La red tor

Usando un directorio donde residan las claves de los nodos, la petición A cifrará el contenido para C, y luego se lo enviará a B, luego ésta cifrará ese contenido al penúltimo nodo, y finalmente, cuando se finalice toda esta transacción, se le enviará la respuesta descifrada al destinatario.

La red en diseño tiene sus pros y contras, y entre uno de sus contras está, que el último nodo es capaz de ver el contenido tal cual como lo envió A, solo sí no se cifró desde el origen.

Instalación de tor:

Para hacer uso de Tor, es necesario el paquete, por suerte en la mayoría de distribuciones de diferente índole, el nombre es invariable.

sudo apt-get install tor

Uso:

Tanto su uso puede ser perfectamente ejecutado como un daemon o iniciándolo como un aplicativo más, pero para ser más organizados, vamos a hacerlo de la manera tradicional.

sudo service tor start

El uso de Tor es aun más sencillo que los anteriores aplicativos, ya que como está por defecto, su uso, es perfecto.

curl -x "socks5h://127.0.0.1:9050" http://ip-api.com/json | jq

Viajando a través de la red

Como se puede apreciar nos encontramos en los Países Bajos en un santiamén.

Configuración automática en LAN/WLAN:

Cualquiera que esté en sus cabales, puede notar lo excesivo que puede ser esto para un usuario promedio en un ambiente doméstico: instalar la aplicación correspondiente, procurar que no se quejará por algún error o un sinfín de vicisitudes que se puedan presentar en determinado contexto, y luego, si se tiene éxito, conectar a la aplicación. ¿Y si se pudiera adelantar todos esos pasos de forma transparente al usuario? Afortunadamente sí es posible, y el usuario lo único que tiene que hacer es conectarse, ya sea por medio de Ethernet o WIFI, a nuestro pequeño punto de acceso (o usando el cable de ethernet, si es por esta vía).

En aras a la simplicidad, vamos a usar por el resto de las subsecciones, scripts que nos ayuden a configurar de forma amena toda la infraestructura. Claro está que es necesario instalar un par de paquetes que se irán nombrando a lo largo del artículo.

Instalación de redsocks:

Según, desde el repositorio oficial de redsocks, es:

Una herramienta que permite redirigir cualquier conexión TCP a SOCKS o proxy HTTPS utilizando su firewall, por lo que la redirección puede ser en todo el sistema o en toda la red.

Esta herramienta, con un par de configuraciones, es posible que cumpla con éxito el objetivo de esta sección, pero antes, es necesario instalarla:

sudo apt-get install redsocks

Ya instalado, es ahora indispensable ejecutar ciertos scripts que hacen uso de iptables para configurarlo junto con redsocks.

Uso de redsocks:

Antes que nada, he aquí los archivos:

Archivos necesarios para configurar redsocks

init.sh:

# Crear una nueva cadena
sudo iptables -t nat -N REDSOCKS
# Ignorar LANS y otras dirección reservadas (https://es.wikipedia.org/wiki/Anexo:Direcciones_IP_reservadas).
sudo iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
# Cualquier otra cosa debería ser redirigida al puerto 12345
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345

redsocks.conf:

base {
        log_debug = on;
        log_info = on;
        log = "file:/tmp/redsocks.log";
        daemon = on;
        redirector = iptables;
}

redsocks {
       /*
        * Por defecto es 127.0.0.1 por razones de seguridad,
        * pero si deseamos escuchar en todas las interfaces,
        * usamos la dirección no especificada, 0.0.0.0. El
        * puerto es arbitrario igualmente.
        */
        local_ip = 0.0.0.0;
        local_port = 12345;

        // Dirección IP y puerto del servidor proxy
        ip = <Dirección IP>;
        port = <Puerto>;

        // Los tipos conocidos son: socks4, socks5, http-connect, http-relay
        type = <Tipo>;
}

restore.sh:

sudo iptables -F
sudo iptables -X
sudo iptables -Z
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t nat -Z
killall redsocks

El primer archivo (init.sh) como su mismo nombre lo indica, serán las reglas para iptables, así redsocks funcionará correctamente; el segundo (redsocks.conf) es la configuración de redsocks, que se hablará en breve; y, el tercero y último, pero no menos importante, es la contraparte de init.sh, ya que es el encargado de restaurar las cadenas y reglas de iptables y terminar (si está en ejecución) el proceso redsocks.

Pasemos directo a la acción ejecutando el primer archivo, no sin antes permitir la redirección de paquetes, y, especificar nuestra interfaz de salida:

sudo sysctl net.ipv4.ip_forward=1
sudo iptables --table nat --append POSTROUTING --out-interface ppp0 --jump MASQUERADE

Para mi caso, la interfaz del sistema de salida es ppp0. Ahora sí, se deberá ejecutar el script anteriormente mencionado.

sudo sh init.sh

A su vez, aunque es opcional y se le deja en libertad al lector, vamos a crear una función para agregar reglas que serán redirigidas a la cadena REDSOCKS, anteriormente creada con el script init.sh.

function add_redsocks_rule() {
    local is_extern=$1
    local port=$2
    local chain

    if [ "$#" -lt 2 ];then
        echo "Sintaxis: add_redsocks_rule <0|1> <PUERTO>"
        return 1
    fi

    if [ "$is_extern" -eq 1 ];then
        chain="PREROUTING"
    elif [ "$is_extern" -eq 0 ];then
        chain="OUTPUT"
    else
        echo "No se puede saber si la regla es externa o no."
        return 1
    fi

    sudo iptables -t nat -A "$chain" -p tcp --dport "$port" -j REDSOCKS
}

Y, para el gozo de los perezosos u olvidadizos, vamos a agregar dos alias.

alias add_redsocks_rule_internal="add_redsocks_rule 0"
alias add_redsocks_rule_external="add_redsocks_rule 1"

Una vez se ha realizado con diligencia el prologo de nuestra operación, es momento de configurar redsocks.conf, siendo elemental configurar sólo la dirección de nuestro servidor proxy, que, si bien, no es recomendable hacer la práctica que se citará a continuación, se eligió uno al azar por la web, siendo su localización: Brasil.

Configurando la dirección del proxy

Es momento de ejecutar redsocks.

sudo redsocks -c redsocks.conf

Y, se deberá probar si funcionó, ya sea comparando nuestra dirección IP pública original con la del servidor proxy, o viendo la localización del ISP, pero antes de continuar, es importante que usemos la función que se creó hace unos momentos para poder agregar los puertos a los que se deberá redirigir.

add_redsocks_rule_internal 80
add_redsocks_rule_internal 443

Esto lo que hará será aplicar la cadena REDSOCKS a los puertos TCP especificados. Y como paso final, se prueba su eficacia:

curl http://ip-api.com/json | jq

Proxy en Brasil

Como es posible apreciar por las ilustraciones, no es necesario especificar, con el parámetro de CURL -x, la dirección, ni el puerto, ni el tipo del proxy, sino que será sigilosamente ejecutado.

LAN:

Ya es sabido lo sencillo que es configurar un proxy tanto si se desea usar con configuraciones implícitas o explícitas, pero no se puede obviar el hecho de que algunos usuarios se vean en la necesidad de disponer de un proxy sin tener que configurarlo, como puede ser en LAN.

Para que eso sea posible, es necesario propiciar de un servidor DHCP, cosa que nos la puede facilitar mucho dnsmasq.

Instalación de dnsmasq:

dnsmasq proporciona tanto un servidor DNS, un servidor DHCP, y entre otras cosas muy interesantes. Es adecuado para maquinarias de escasos recursos, ya que es liviano y tiende a consumir muy poco. Además, una característica muy relevante en este software es, que puede almacenar las consultas en caché, lo que aumentaría la búsqueda de los sitios almacenados con anterioridad.

Su instalación, al igual que los demás paquetes no pasa de un comando:

sudo apt-get install dnsmasq

Configuración de dnsmasq:

Su configuración es simple, pero se ha comentado diligentemente cada detalle debido a la largura de las descripciones.

# Los navegadores antiguos tenían una barra que era específica para las búsquedas en los 
# buscadores, pero el usuario por ignorancia usaba la que era para los dominios, lo que
# provocaba que se perdiera tiempo resolviendo dominios inexistentes, lo que acarreaba
# en una respuesta DNS "NXDOMAIN". Con esta instrucción se evita eso (aunque los navega-
# dores actuales ya solucionarón ese inconveniente), pero esto hace referencia a los
# antiguos.
domain-needed

# Evitar que se haga una consulta DNS inversa a una dirección local o en el espacio de
# direcciones.
bogus-priv

# No usar el fichero 'resolv.conf'
no-resolv

# Definimos los servidores DNS, que, a conveniencia se usan los de OpenDNS.
server=208.67.222.222
server=208.67.220.220

# Configuramos el servidor DHCP para asignar el rango de direcciones en 24h(oras) en las
# interfaces wlan0 (la tarjeta de red inalámbrica) y eth0 (la de ethernet).
# wlan0 tendrá el siguiente rango: 192.168.0.2 a 192.168.0.254, mientras que el punto de
# acceso (nosotros) tendrá la dirección 192.168.0.1
# eth0 tendrá el siguiente rango: 10.42.0.2 a 10.42.0.254, mientras que la máquina local
# tendrá la siguiente dirección 10.42.0.1
#
# Nota #1: Tienen que usar sus propias interfaces.
# Nota #2: Recuerden que su tarjeta de red inalámbrica debe admitir el modo AP para que
# sea posible crear un punto de acceso.
dhcp-range=eth0,192.168.0.2,192.168.0.254,24h
dhcp-range=wlan0,10.42.0.2,10.42.0.254,24h

# Registramos las consultas y demás (opcional, pero altamente recomendable para la depuración)
log-queries
log-dhcp
log-facility=/var/log/dnsmasq.log

La ubicación donde se debe escribir es en /etc/dnsmasq.conf. A continuación se reinicia dnsmasq.

sudo service dnsmasq restart

Asimismo como hicimos para agregar reglas internas, ahora debemos agregar reglas externas.

add_redsocks_rule_external 80
add_redsocks_rule_external 443

Y, por motivos de prueba, usamos la máquina cliente para ver si hemos tenido o no éxito, que, se debe hacer de forma parecida al examen que hicimos localmente.

curl http://ip-api.com/json | jq

Probando el proxy sin necesidad de configurarlo en el cliente

WLAN:

Se aumenta paulatinamente la complejidad, pero estas palabras no son ni de lejos ciertas. Ya habiendo configurado exitosamente el proxy, tanto de forma local como en LAN, ahora pasamos al siguiente nivel, que sería la conectividad inalámbrica, algo que a día de hoy, es muy bien recibido.

Para ello, vamos a crear un punto de acceso, pero para el cliente será como conectarse a cualquier router doméstico, además, si le sumamos que navegará por un proxy sin necesidad de instalar ni configurar nada, es en serio, muy útil.

Instalación de hostapd:

hostapd es un software gratuito y de código abierto, que está diseñado para facilitar la creación de puntos de acceso. En caso de verse en la necesidad de no contar con un router, pero sí con una tarjeta de red inalámbrica compatible con el modo AP, esta herramienta es muy útil, y muy configurable, además tiene diferentes características que, de solo mencionarlas, sería quedarse corto. Entre sus características son:

• Soporte WPA/WPA2, WEP, entre otros.
• Es posible crear redes ocultas.
• Estadísticas muy detalladas de los datos.
• Entre otras tantas.

Primero para explotar todas las características, hay que tener instalado dicho paquete, que se puede hacer con el siguiente comando:

sudo apt-get install hostapd

Configuración de hostapd:

Ahora es necesario configurarlo, para ello, se deja aquí mismo el archivo ya comentado, no sin antes repetir que se debe verificar si la tarjeta de red tiene soporte para el modo AP, por suerte se puede ver con el comando iw, pero si no se tiene instalado:

sudo apt-get install iw

Para ver cuántas tarjetas de red inalámbricas tenemos:

iw dev

Listado de interfaces de redes

Donde dice phy#0, es el índice de hardware, y es importante saberlo para poder ver la información con el siguiente comando, aunque para no complicar su visualización, solo se mostrará parte del resultado, que son los modos soportados, que es lo que nos interesa.

iw phy0 info

Modos soportados

Se ve claramente que entre los modos soportados está el que nos interesa: AP, pero en caso de que no esté y se intente crear un punto de acceso con hostapd puede ser muy inestable o ni siquiera se crearía.

Ahora que ya se ha comprobado si nuestra tarjeta de red tiene ese poder, he aquí la tan esperada configuración:

# El nombre de la red
ssid=DtxdF

# El canal
channel=5

# Esta opción, que depende de la tarjeta, significando así, junto con la
# compatibilidad 'N', la tecnología que admite.
hw_mode=g

# 1 = WPA; 2 = WEP; 3 = Ambos
auth_algs=3

# Compatibilidad con la tecnología 'IEEE 802.11n'
ieee80211n=1

# QoS
wmm_enabled=1

# La interfaz de la tarjeta de red inalámbrica
interface=wlan0

# Versión 2 de WPA
wpa=2

# Una contraseña super segura
wpa_passphrase=thisisapasswordsupersecure123@

# (AES) Counter Mode CBC-MAC Protocol
rsn_pairwise=CCMP

Está perfectamente comentado, por lo que lo único que faltaría es aclarar que algunos valores como el de hw_mode, ieee80211n, y rsn_pairwise, depende de las posibilidades de nuestra tarjeta de red, y para poder ver esa información, el compañero ideal será iw, aunque si éste no muestra detalles útiles o específicos, tal vez sea necesario instalar el paquete lshw, o usar el viejo iwconfig.

Ya guardado el archivo de configuración en /etc/hostapd/hostapd.conf, es hora de reiniciar el daemon hostapd:

sudo service hostapd restart

Mientras tanto en el cliente, y ya habiendo accedido vía WIFI a nuestro punto de acceso, es posible ver si la magia ha hecho efecto al corroborar la ubicación.

Uso del proxy en Android a través de WIFI

The Onion Router Access Point (Tor-ap):

Si el lector no ha quedado satisfecho con usar un proxy común y corriente, de formal local, por LAN y WLAN, entonces quizá le atraiga la idea de usar la red Tor.

Uso:

tor-ap es un script simple que permitirá redirigir todas las conexiones hacia la red Tor. Tal script se puede encontrar en las siguientes líneas:

#!/usr/bin/env sh

# El identificador del usuario de Tor.
TOR_UID=$(id -u debian-tor)

# Las destinos que no se enrutarán a través de Tor.
NON_ROUTE="127.0.0.1/8"

# El puerto DNS local, que, por defecto es el 53.
LOCAL_DNS=53

# Esta sección es para la máquina local.
#
# L_TOR_DNS: El puerto DNS de Tor para la máquina local.
# L_TRANS_PORT: El puerto del proxy transparente para la máquina local.
L_TOR_DNS=5353
L_TRANS_PORT=9040

# Esta sección es para las máquinas remotas (cliente conectados vía LAN/WLAN).
#
# No hace falta explicación, es lo mismo que la anterior sección, pero
# aplicado a las máquinas remotas.
R_TOR_DNS=5354
R_TRANS_PORT=9041

iptables --flush
iptables --table nat --flush

iptables --table nat --append OUTPUT --match owner --uid-owner $TOR_UID --jump RETURN
iptables --table nat --append OUTPUT --protocol udp --dport $LOCAL_DNS --jump REDIRECT --to-ports $L_TOR_DNS
iptables --table nat --append PREROUTING --protocol udp --dport $LOCAL_DNS --jump REDIRECT --to-ports $R_TOR_DNS

for NET in $NON_ROUTE;do
        iptables --table nat --append OUTPUT --destination $NET --jump RETURN

done

iptables --table nat --append OUTPUT --protocol tcp --syn --jump REDIRECT --to-ports $L_TRANS_PORT
iptables --table nat --append PREROUTING --protocol tcp --syn --jump REDIRECT --to-ports $R_TRANS_PORT

Damos los correspondientes permisos de ejecución:

chmod +x tor-ap

Y, configuramos Tor:

/etc/tor/torrc:

# Cuando Tor necesita asignar una dirección virtual (no utilizada) debido a un comando
# MAPADDRESS del controlador o la función AutomapHostsOnResolve, Tor elige una
# dirección no asignada de este rango. Más en 'man 1 tor'.
VirtualAddrNetwork 10.192.0.0/10
# Cuando esta opción está habilitada y recibimos una solicitud para resolver una dirección que termina
# con uno de los sufijos en AutomapHostsSuffixes, asignamos una dirección virtual no utilizada a esa
# dirección y devolvemos la nueva dirección virtual. Esto es útil para hacer que las direcciones
# ".onion" funcionen con aplicaciones que resuelven una dirección y luego se conectan a ella.
# Más en 'man 1 tor'
AutomapHostsOnResolve 1

# Esto es necesario para la máquina local.
#
# El puerto del proxy transparente
TransPort 9040
# El puerto del servidor DNS UDP de Tor
DNSPort 5353

# Esto es necesario para los clientes remotos.
TransPort 0.0.0.0:9041
DNSPort 0.0.0.0:5354

Ahora se reinicia Tor:

sudo service tor restart

Antes de ejecutar CURL, debemos, con una instancia de Tor en ejecución, ejecutar tor-ap.

sudo ./tor-ap

Ahora comprobamos:

curl http://ip-api.com/json | jq

Finalización de tor-ap

La ventaja más llamativa de tor-ap frente a la tradicional configuración de este austero artículo, es, que no es necesario especificar los puertos específicos, ni hacer malabares para que funcione Tanto local, como en LAN y WLAN, con la simple ejecución del script es posible realizar todo esto, y con la segunda ventaja, pero igual de grandiosa, y es que si realizamos una prueba de fuga de DNS, los resultados serán magníficos.

DNS Leak Test

No hay fugas.

No está demás decir, antes de concluir, que, no es necesario aplicar una regla a iptables para indicarle al sistema qué interfaz será la de salida (en otras palabras, la que brindará al usuario conexión a Internet) y tampoco es necesario habilitar la redirección de paquetes (con sysctl), eso es otra ventaja.

Nyx & Tor:

Circuitos de Tor usando Nyx

Nyx es un monitor de línea de comandos para Tor. Con él es posible obtener información sumamente detallada en tiempo real sobre los circuitos que hacen uso los usuarios, como el uso de ancho de banda, las conexiones, los registros, y muchísimo más.

Para usar la imprescindible herramienta, podremos instalarla de la siguiente manera:

python3.7 -m pip install nyx

Es importante que seleccionen su versión de Python correspondiente, ya que en algunas distribuciones el comando sin especificar su versión implica ejecutar la versión 2.7, ya vieja y descontinuada.

Ya instalado, no es necesario configurar Nyx, pero sí a Tor

Configuración de Tor para su uso con Nyx:

Antes de hacer nada, vamos a generar una clave para aumentar la seguridad en el control de Tor, para ello con el siguiente comando, que se comentará en breve, es posible hacerlo.

tor --hash-password 123

HASH que se deberá usar en la configuración de Tor

Anotando la salida de ese comando, y pegándola en la configuración de Tor de la siguiente manera:

/etc/tor/torrc:

ControlPort 9051
HashedControlPassword 16:A2A0C4D4E718EBE8600E129DB98AA1C3459069F221E8BDC73063CC4EF6

Allí especificamos el HASH de la contraseña 123, y además, con ControlPort damos a entender que es el puerto para habilitar el control del proceso Tor.

Ahora ejecutamos nyx y por motivos de seguridad se nos preguntará la contraseña.

Inicio de sesión con nyx

Una vez tecleamos la contraseña correspondiente, e ingresamos exitosamente, nos encontramos con el gráfico del ancho de banda, tanto de bajada como de subida.

Gráfico del ancho de banda

Presionamos la flecha derecha de nuestro teclado y obtenemos otra vista: ahora podremos ver los circuitos.

Circuitos de Tor

Si se presiona ENTER veremos información en pantalla.

Circuitos de Tor mejor detallados

Una muy útil forma de usar nyx es para obtener una nueva identidad. Simplemente presionando la tecla n se nos cambiará.

for i in {1..3};do
    curl -x "socks5://127.0.0.1:9050" -s http://ip-api.com/json | jq ".query" | tr -d '"'
done
# Después de requerir una nueva identidad.
curl -x "socks5://127.0.0.1:9050" -s http://ip-api.com/json | jq ".query" | tr -d '"'

Cambiando de identidad

Proxychains:

En ciertas ocasiones cuando una aplicación tiene la habilidad de conectarse, ya sea a Internet o un sucedáneo, no trae con sí el poder de configurar un proxy, afortunadamente existe una herramienta capacitada para este fin.

Proxychains es ideal para situaciones como las anteriormente planteadas, ya que permite, dependiendo de su configuración, encadenar una lista de proxies.

instalación:

sudo apt-get install proxychains

Uso:

Proxychains es fácil de configurar, ya que consta de un solo archivo de configuración, y dentro de él, tiene tres formas de funcionar, sumando a las diversas opciones.

• Dinámico o Dynamic: Cada conexión se realizará a través de proxies encadenados, tal y como estén en la lista, omitiendo a los muertos.
• Estricto o Strict: Igual que Dynamic, pero es necesario que todos los proxies encadenados estén en línea.
• Aleatorio o Random: Cada conexión se realizará a través de un proxy aleatorio.

Es necesario antes de ejecutar a proxychains, definir la cadena de proxies a utilizar, los cuales, para este artículo, serán:

socks5 135.181.39.13  1080  # Finland
socks5 151.106.34.139 1080  # France
socks4 127.0.0.1      1212  # Este no existe (!)
socks5 192.252.215.5  16137 # Canada

Suponiendo que el tercer proxy no exista, en teoría igualmente debería funcionar, salvo que ningún otro funcione, pero este no es el caso (al menos no en el momento de escribir estas palabras).

proxychains curl http://ip-api.com/json && echo

Modo dinámico de proxychains

Como se puede observar, aunque algunas conexiones fallen, sigue su ejecución con prontitud.

Ya habiendo probado el modo dinámico, por supuesto que para ver otro tipo de funcionamiento, vayamos con el estricto, que, según la descripción, es igual a dynamic, pero falla si alguna conexión falla. Así que lo que se debe hacer para cambiar el modo, es, comentar dynamic_chain en el archivo de configuración y a su vez, descomentar strict_chain, dejando intacto lo demás. Ejecutando el mismo comando, aquí su resultado.

Modo estricto en proxychains

Falló exactamente como se tenía en mente, pero ahora comentando el proxy que no existe, debería funcionar tal y como se está maquinando en nuestra mente.

Modo estricto sin fallar en proxychains

Obtenemos un resultado grato, y es porque se eliminó el proxy muerto o inexistente.

Faltaría entonces un modo, siendo uno de los más interesantes: random. Su mismo nombre ilustra lo que hará. Pasamos comentado strict_chain y descomentando random_chain, a su vez, ejecutamos nuevamente el mismo comando, pero esta vez en un bucle for, siendo su límite hasta tres veces para ver qué obtenemos.

Modo aleatorio de proxychains

Sin tocar absolutamente nada, se percibe tácitamente el cambio que proxychains hace entre las cadenas de proxies, concluyendo así las modalidades.

Opciones misceláneas de proxychains:

• chain_len: Esto determinará cuántas de las direcciones IP de la cadena se utilizarán en la creación de la nueva cadena de proxies aleatoria.
• quit_mode: No muestra la salida verbosa. Muy útil si se quiere combinar con otros programas usando tuberías, por ejemplo.
• proxy_dns: Usar los proxies para realizar una petición DNS. Lo positivo es que no habrá filtrado de datos, y lo negativo, es que el servidor de tener habilitada implementada esta característica.
• tcp_read_time_out: El tiempo de espera para la lectura en milisegundos.
• tcp_connect_time_out: El tiempo de espera para conectar en milisegundos.

El archivo de configuración de proxychains está muy bien documentado, así que en caso de duda, es buena idea acudir a él también.

Conclusión:

Desde el preludio de este austero artículo que tuvo el principal objetivo de inculcar, tanto a los novicios como a los más versados en la materia, las diferentes maneras de las que se podría o, implementar, o, usar un proxy en plataformas Gnu/Linux y compatibles, con el propósito, ya sea de aumentar la privacidad, la seguridad, evadir las restricciones que impone un gobierno, o para englobar, acceder a ciertos recursos que no son posibles de llevar a cabo en tal nación determinada. Espero sea de verdad muy útil para el que esté leyendo las siguientes líneas.

Este artículo es una especie de segunda versión de otro artículo que se hizo hace mucho tiempo, puliendo algunos detalles y agregando otros, es por eso que algunas características pueden tener cierto parentesco.

Contribución gracias a ~DtxdF de Underc0de