Pivoting entre proxys encadenados con Proxychains

Proxychains es una herramienta que actúa como un servidor proxy soportando conexiones TCP en protocolos HTTP, HTTPS, SOCKS4 y SOCKS5. Su principal característica es el encadenamiento de servidores proxy configurados y como redirige estas peticiones de uno a otro.

En una fase de reconocimiento y enumeración hacía un sitio web, dependiendo el caso, intentamos mantener un cierto grado de anonimato ocultando nuestra dirección IP pública. Para ello usamos servidores Proxy o VPN Proxy o VPN siendo estas más fiables, prácticas y con un mayor nivel de garantía.

El uso de Proxychains nos permite configurar varios servidores proxy e ir reenviando de uno a otro de forma secuencial las peticiones que realicemos usando una segunda herramienta que no tenga capacidad para realizar esta tarea y así convertirla en anónima como pueden ser el uso de Nmap, SSH, un navegador web, etc.

proxychains <aplicación> <argumento>

proxychains firefox http://ifconfig.me

Existen multitud de sitios web donde podemos encontrar servidores proxy abiertos, para realizar las siguientes pruebas de forma rápida son los que usaré, lo ideal sería usar diferentes máquinas que nosotros montemos y conozcamos en distintos hostings, configurar un servidor proxy con usuario y password y hacer uso de estas IPs y puertos.

hidemy.name

Es un sitio web en el que encontramos una gran lista que suele estar actualizada de servidores proxy públicos.

• Proxy list: https://hidemy.name/es/proxy-list/

Figura 1: Proxy list en https://hidemy.name.

Podemos instalar Proxychains desde los repositorios, en Kali ya viene incluido en su suite de herramientas. Algunas de las opciones disponibles a configurar en su fichero de configuración /etc/proxychains.conf.

• quiet_mode: Si está descomentada indicaría un modo verbose activado.
• proxy_dns: Todas las peticiones DNS también saldrán por el proxy, es importante para conservar el anonimato, si la petición DNS va por nuestra IP y el tráfico por la IP del proxy podría llegar a encontrarse una correlación en los logs del servidor remoto.

Se encadenan en el mismo orden en el que se define la lista. Un ejemplo de la sintaxis de configuración sería.

<tipo> <IP> <puerto> <usuario> <password>

socks4 192.168.40.30 1080 user pass

En el caso de que el servidor proxy sea público y por lo general no contenga un usuario y contraseña se omitiría.

En el apartado de ProxyList definimos la lista de servidores proxy. Por defecto Proxychains hace uso de Tor. En el siguiente escenario se usarán servidores proxy de la lista anterior de hidemy.name. 

Figura 2: Estableciendo un tipo de proxy socks4 público en proxychains.

En la siguiente captura se muestra el resultado de una petición curl a la web https://ifconfig.me/ip que nos dará como resultado nuestra dirección IP pública sin proxychains. Usando proxychains vemos como la dirección IP pública es el servidor proxy configurado en proxychains, siendo este quién realiza la petición al sitio web.

proxychains curl https://ifconfig.me/ip

Figura 3: Comprobando la IP del proxy al visitar ifconfig.me.

Ahora añadiremos dos servidores proxy al fichero de configuración de proxychains. Si realizamos la misma petición con curl usando proxychains vemos como la petición se reenvía de uno a otro en el mismo orden establecido en el fichero de configuración. Para el sitio ifconfig.me será último servidor proxy quién realizó la solicitud y será el que se registre en log de acceso del servidor web.

Figura 4: Encadenando varios proxy con proxychains.

Pivoting entre redes internas con Proxychains

Proxychains también nos ayuda en la evasión de firewalls entre las comunicaciones en redes locales internas.

En el siguiente escenario el equipo de la Red A no tiene visibilidad con el equipo de la Red B pero existe un equipo intermedio que tiene visibilidad con ambas redes y que el equipo de la Red B solo aceptará peticiones que provengan de ese equipo intermedio.

Si queremos realizar un escaneo de puertos con nmap desde el equipo de la Red A al equipo de la Red B en una conexión directa no podríamos por una cuestión de visibilidad en la segmentación de redes internas locales. Sin embargo si tenemos acceso al equipo intermedio que si está autorizado para poder comunicarse con el equipo de la Red B.   

Figura 5: Pivoting hacia otra red interna con Proxychains.

Podríamos conectarnos al equipo intermedio y usar namp desde ese equipo, pero no queremos interferir instalando paquetes ni tampoco tenemos permisos suficientes para realizar instalaciones.

En estos casos lo mejor sería establecer una conexión tunelizada ejecutándose en background habilitando un reenvío de puerto dinámico (port forwarding dynamic).

ssh -NfD 1280 adrian@10.0.0.40

• -N: No ejecuta un comando remoto (útil solo para reenviar puertos)
• -f: Se ejecuta en segundo plano 
• -D: Reenvío local de un puerto dinámico

Figura 6: Estableciendo tunel ssh port forwarding dynamic.

Configuramos proxychains para usar el puerto local 1280 que reenviará la petición al equipo intermedio y este a su vez al equipo de la Red B. En la siguiente captura vemos como usando simplemente nmap no llegamos al equipo de la Red B pero a través de proxychains somos capaces de escanear un servicio web disponible en el puerto 80.

proxychains nmap -sS 10.0.0.16 -p80

Figura 7: Pivoting entre redes locales internas con Proxychains.

Saludos!

sshuttle: Múltiples túneles SSH y "VPN" (Proxy transparente)

sshuttle. Se trata de un cliente SSH desarrollado en pyhton que actúa como un proxy transparente funcionando como una "VPN". No se trata de una VPN como definición, sshuttle crea de forma automática distintas reglas usando pfctl (pf - Packet Filter) o en su defecto iptables para un múltiple reenvío de puertos a través de una conexión tunelizada vía SSH.

Ya comentara las diferencias entre los distintos tipos de túneles SSH. Esta aplicación nos abstrae de los detalles de realizar manualmente cada reenvío -port forwarding- a cada IP/Puerto hacia la red remota a la que queremos acceder.

La funcionalidad es como si realmente estuviéramos utilizando una VPN pero canalizada por una única conexión SSH a través de un host de la red remota que hará de equipo puente realizando múltiples túneles de reenvío. Su principal desarrollador Brian May, la define como "la VPN para el hombre pobre".

Soporta tunelización de DNS redireccionando todo el tráfico DNS local a través de la conexión SSH al host remoto, como si estuviéramos utilizando las direcciones DNS de la red remota. Por lo que toda la navegación es como si la hiciésemos a través de la red remota a la que nos conectamos, algo similar a un -dynamic port forwarding- o Proxy SOCKS

Si nos conectamos en un red wifi abierta o pública y queremos estar más seguros navegando y/o acceder a recursos internos de nuestra red doméstica sin necesidad de implementar o alquilar servicio VPN externo de terceros, esta aplicación es una muy buena solución.

Es compatible con Linux y MacOS (Windows con cygwin instalado).

• Repositorio Github: https://github.com/sshuttle/sshuttle
• Docs: https://sshuttle.readthedocs.io/en/stable/

Instalar sshuttle

git clone https://github.com/sshuttle/sshuttle.git
cd sshuttle
sudo ./setup.py install

En mi caso dispongo de una  RaspberryPi con el servicio SSH expuesto a Internet en un puerto no estándar.

Uso de sshuttle

sshuttle [-l [ip:]port] [-r [user@]sshserver[:port]] <subnets...>

sshuttle -v --dns -r USUARIO@IP:PUERTO 192.168.0.0/24

La opción --dns indica el tunelizado de tráfico DNS. 

En el caso de MacOS usa reglas de filtrado de redirección con pf (pfctl). Ejemplo de autenticación con clave pública.

MacOS:~ adrian$ sshuttle -v --dns -r USER@IP/DNS:PORT 10.0.0.0/24
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 2.7.16
firewall manager: ready method name pf.
IPv6 enabled: True
UDP enabled: False
DNS enabled: True
User enabled: False
TCP redirector listening on ('::1', 12300, 0, 0).
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('::1', 12299, 0, 0).
DNS listening on ('127.0.0.1', 12299).
Starting client with Python version 2.7.16
c : connecting to server...
Starting server with Python version 3.6.9
 s: latency control setting = True
 s: auto-nets:False
c : Connected.
firewall manager: setting up.
>> pfctl -s Interfaces -i lo -v
>> pfctl -s all
>> pfctl -a sshuttle6-12300 -f /dev/stdin
>> pfctl -E
>> pfctl -s Interfaces -i lo -v
>> pfctl -s all
>> pfctl -a sshuttle-12300 -f /dev/stdin
>> pfctl -E
c : DNS request from ('10.0.0.16', 51556) to None: 31 bytes

En el caso de Ubuntu usa reglas de filtrado de redirección con iptables. Ejemplo de autenticación con password.

adrian@ubuntu:~$ sshuttle -v --dns -r USER@DNS/IP:PORT 10.0.0.0/24
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.6.9
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: True
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('127.0.0.1', 12300).
Starting client with Python version 3.6.9
c : connecting to server...
USER@DNS/IP's password:
Starting server with Python version 2.7.17
 s: latency control setting = True
 s: available routes:
c : Connected.
 s:   2/10.0.0.0/24
 s:   2/172.17.0.0/16
 s:   2/172.18.0.0/16
firewall manager: setting up.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.0.53/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42

En el caso de Windows se complica el uso de esta herramienta.

Se propone instalar una máquina virtual Linux en modo puente que haga la conexión con sshuttle y desde la máquina anfitrión Windows enrutar todo el tráfico hacia la máquina Linux.

Info: https://sshuttle.readthedocs.io/en/stable/windows.html

Saludos!

Tipos de Firewall de red: Stateless, Stateful, SPI, AIC, DPI, NIDS, IDS/IPS - IDPS y Proxy

En el blog de Oscar Gerometta me encontré un estupendo artículo donde habla de los tipos de firewalls y en que se basan los firewalls con y sin estado, SPI, AIC, DPI, IDS/IPS - IDPS y Proxy.
Después algunos apuntes a mayores que anoté y editarlo un poco comparto el artículo como apunte personal y para quien le interese.

¿Qué es un firewall?

Un firewall es un sistema que fuerza la implementación de políticas de control de acceso entre 2 o más dominios de seguridad.

Es decir, un sistema (hardware, software, combinación de ambos o simplemente implementación en un dispositivo no dedicado) que facilita la aplicación de políticas de inspección y acceso entre 2 áreas de la red que tienen diferente política de seguridad.

 
Firewall puede ser entonces un dispositivo (hardware dedicado que corre un software especialmente diseñado para este propósito), un software implementado sobre un dispositivo no dedicado a ese propósito, lo que serían firewall ISR (Integrated Services Router), o una implementación de recursos o herramientas que permiten realizar este tipo de tareas, un conjunto de ACLs (Access Control List) en un router de acceso.

Hay que tener en cuenta que la implementación de Firewalls, a cuento más bajo nivel (en las capas del modelo OSI) se implementen, mucho mejor y más seguro. Ya que los accesos/bloqueos/filtrados serán más dificiles de eludir.

Tipos de Firewal

De acuerdo a las técnicas de filtrado de tráfico que se implementan, los firewalls pueden clasificarse en diferentes tipos.

Filtrado de paquetes stateless (sin estado)

Es la forma más básica de filtrado de tráfico.Usualmente se aplica en dispositivos de capa de red e implementa conjuntos de reglas estáticas que examinan los encabezados de cada paquete para permitir o denegar el tráfico, sin ninguna relación con los flujos de tráfico precedentes. Trabajan bien cuando el objetivo filtra aplicaciones basadas en TCP que no utilizan negociación dinámica de puertos.

Filtrado de paquetes stateful (con estado)

Es un método de filtrado de paquetes que trabaja a nivel de flujo o conexión, con ocasionales intervenciones a nivel de la aplicación.

Mantienen una tabla de estado que hace seguimiento de las sesiones que atraviesan el firewall y en función de ella hace inspección de cada paquete que atraviesa el dispositivo.
El mecanismo asume que si se permite el inicio de la conexión, cualquier conexión adicional que requiera esa aplicación será permitida. Es un mecanismo confiable para filtrar tráfico de red entre dominios de seguridad.

Filtrado de paquetes stateful con inspección SPI (Stateful Packet Inspection) y control de aplicaciones

Se trata de firewalls stateful que incorporan motores de análisis de tráfico que suman servicios adicionales que reciben la denominación de AIC (Application Inspection and Control) o DPI (Deep Packet Inspection).

Estos sistemas reensamblan en memoria las sesiones de capa de transporte para realizar inspección de protocolos de capa de aplicación y decodifican los protocolos de capa de aplicación para permitir filtrado de protocolos y contenidos. Pueden verificar los protocolos de capa de aplicación para eliminar paquetes que no se conformen con el funcionamiento estándar del protocolo.

Sistemas de prevención de intrusos en la red: NIPS (Network Intrusion Prevention Systems)

También conocidos como IDS/IPS o IDPS (Intrusion Detection Prevention System). Son sistemas que analizan el tráfico de la red con el propósito de bloquear tráfico malicioso conocido. Se asienta en una base de datos de ataques que debe ser actualizada periódicamente.

Son mecanismos permisivos y usualmente no pueden detectar amenazas nuevas a menos que hayan sido incluidas en las actualizaciones.

Gateways de aplicaciones (proxy)

Es un sistema de software diseñado para actuar como intermediario y reenviar requerimientos de capa de aplicación y respuestas entre los clientes y los servidores. En términos de control de acceso, permite un filtrado y seguimiento muy granular tanto de las solicitudes como de las respuestas.

Brindan opciones de control de acceso confiables para los protocolos soportados. Sin embargo, hay que tener presente que no hay proxy disponibles para todas las aplicaciones corporativas y no se aplican a aplicaciones de tiempo real.

Saludos!