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.
<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.
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!
