3.3.2.5. Escaneo de puertos avanzado

Tabla de contenidos:

3.3.2.5.1. Escaneo de puertos en Internet
3.3.2.5.2. Escaneo de puertos con proxy: técnicas de ocultación
3.3.2.5.3. Escaneo de puertos con Firewall: técnicas de evasión
3.3.2.5.4. Escaneo de puertos con Firewall: IDLE Scan
3.3.2.5.5. Escano de puertos con sistema de detección de intrusos
3.3.2.5.6. Túnel SSH dinámico

Técnicas para escaneo de puertos

A continuación se va a describir algunas situaciones para el escaneo de puertos en Internet. Estas situaciones incluyen operaciones para encubrir la IP pública y el escaneo en entornos protegidos por sistemas de Firewall (cortafuegos) y otras herramientas antiintrusos o de protección de redes que pueden dificultar esta tarea.

En estos ejemplos, se utilizará principalmente NMAP y se simularán entornos con las características que se pueden encontrar en Internet. A la hora de efectuar estas pruebas, si no se dispone de dos puntos de acceso a Internet por parte de dos IPS diferentes, una alternativa es utilizar el punto de acceso de una red de datos de telefonía móvil mediante la zona wifi.

3.3.2.5.1. Escaneo de puertos en Internet

Para el escaneo de puertos en Internet, simplemente se tiene que incluir en la opción de target una IP pública. Las IP públicas en Internet suelen estar asociadas a un nodo (router), cuya función es canalizar el tráfico de datos entre diferentes redes mediante routing. Así pues, si bien es cierto que un router puede disponer de servicios para que un administrador de redes pueda configurarlo mediante conexión remota, en la mayoría de ocasiones el resultado de escanear un IP de un router será insatisfactorio como se muestra en el siguiente ejemplo (los puertos accesibles para conexión remota estarán normalmente filtrados para garantizar la seguridad de la red):

Esta situación es diferente cuando el router está dando cobertura a un servidor de acceso público. En este ejemplo (IP pública XXX.XXX.XXX.40), el puerto del router está abierto mediante la técnica de portforwarding, permitiendo acceder a los recursos de un servidor web (puerto 80) que tendrá su propia IP privada en la red interna:

Hay que tener en cuenta que al efectuar estos escaneos sin ningún mecanismo de ocultación, la IP pública de la red desde la que se efectúa el escaneo quedaría al descubierto, siendo consultable tanto en los logs del servidor como en los registros de un sistema antiintrusos que normalmente soportan un sistema de sniffing del tráfico de datos como Wireshark. En este ejemplo, la IP pública del atacante es XXX.XXX.83.18, quedando al descubierto al efectuar el escaneo en la máquina con IP privada 192.168.1.41 que dispone del servicio web:

3.3.2.5.2. Escaneo de puertos con proxy: técnicas de ocultación

Una de las formas habituales para que un atacante oculte su IP pública, es emplear algún tipo de proxy. Un proxy suele ser algún servidor que hace de intermediario en las peticiones de servicios entre un cliente y servidor. En estos casos, la IP pública expuesta es la del proxy. Existen diferentes tipos de proxy y también se puede emplear la red TOR como proxy.

Es común que para efectuar un escaneo de puertos con NMAP mediante consola de línea de comandos en Kali Linux con proxy, se utilice la herramienta proxychains. Proxychains permite configurar el acceso a uno o varios servidores proxy o la red TOR y canalizar el tráfico de red a través de estos. Para emplear NMAP con proxychains o algún otro software de proxy, es necesario utilizar el modo de escaneo -sT, quedando así en línea de comandos (dependiendo de la versión de proxychains):

				
					proxychains4 nmap -sT [OPCIONES DE ESCANEO] [target]

Al efectuar este escaneo, proxychains informará de si la conexión con el proxy se está efectuando satisfactoriamente:

En esta ocasión, el software de sniffing mostrará la IP del proxy o la que haya proporcionado la red TOR como se ve en la siguiente pantalla (IP pública 5.255.99.205). Este sistema, a pesar de permitir ocultar la IP de forma efectiva, tiene sus inconvenientes. Entre estos inconvenientes está la lentitud del escaneo y que el método de escaneo –sT no es nada sigiloso. Así pues, en ocasiones hay que sopesar si es mejor efectuar otras opciones de escaneo sigiloso de modo que los sistemas antiintrusos no alerten, o bien optar de forma preferente para ocultar la IP.

3.3.2.5.3. Escaneo de puertos con Firewall: técnicas de evasión

Los Firewall son un recurso para proteger servicios no públicos añadiendo un perímetro de seguridad en una red. Todos los Sistemas Operativos incluyen algún software de tipo Firewall relativamente fácil de configurar mediante reglas de entrada y salida para el tráfico de red, y así poder restringir las operaciones de comunicación con otros dispositivos permitidas para un router o host. Un Firewall se puede configurar para aplicar reglas sobre casi cualquier elemento de un protocolo de red del modelo OSI.

Para el escaneo de puertos, cuando un Firewall actúa sobre un servicio, el rango de actuación para el atacante resulta extremadamente limitado, sobre todo cuando la regla restringe o permite el acceso para un rango de direcciones IP. A pesar de ello, existen técnicas para ver si sobre un puerto o servicio de un host está actuando alguna regla. Una vez descubierto que hay algún Firewall pero el servicio existe, explotarlo ya sería otra cuestión.

Los siguientes ejemplos volverán a ser en un entorno de laboratorio LAN pero son aplicables también a Internet (ver punto anterior). En este laboratorio se configura para el host Windows con IP 192.168.1.41 un servicio SSH (Secure Shell Host) para el acceso remoto. Sin configurar ninguna regla de Firewall, el escaneo de puertos y uso del servicio no se ven restringidos.

A continuación se introduce una regla de entrada en el Firewall del SO de Windows que restringe la IP del atacante 192.168.1.37 para todos los servicios (no se va a explicar aquí el detalle de configuración).

Ahora, al efectuar el escaneo de puertos tanto para el puerto específico (22) como para el resto, el servicio se mostrará como filtrado o sin resultados respectivamente:

Hay que tener en cuenta que a pesar del bloqueo por el Firewall, el sistema del host seguirá registrando las peticiones de conexión, como se puede apreciar con Wireshark, aunque evidentemente estas peticiones quedarán sin respuesta:

A pesar de esto, NMAP permite opciones para tratar de evadir el control de un Firewall. Estas opciones consisten principalmente en alterar el contenido de las cabeceras de los diferentes protocolos de red mediante spoofing, o bien fraccionando y alterando el tamaño de los paquetes de datos empleados para el escaneo, esperando algún fallo en el Firewall. Estas opciones no resultan muy eficientes cuando las reglas del Firewall restringen por IP, pero conviene estudiarlas porqué también resultan útiles cuando se tiene que ser sigiloso. A continuación se explican las más recurrentes (se pueden combinar):

Opciones de fragmentación y tamaño de paquetes
-f	Fragmenta los paquetes de red enviados en porciones de 8 bytes, que posteriormente la máquina destino deberá ensamblar (fragmentación IP).
–mtu <n>	Fragmenta los paquetes de red enviados en bytes según el valor indicado en n. El número indicado debe ser un múltiplo de 8. No es compatible con el parámetro –f.
–data-lenght <n>	Genera un payload (la parte que no es cabecera IP del paquete de red) con n bytes. Se complementa con los valores de fragmentación.
Opciones de spoofing
–spoof-mac <opcion>	Permite modificar la marca física (dirección MAC) de la tarjeta de red. Este dato se encuentra como parámetro de información de los protocolos para la capa de enlace del modelo OSI.
-g / –source-port <port>	Permite modificar el valor del puerto de origen de la cabecera TCP del paquete.
Otras opciones
-D < RND:n \| ME \| IP>	Envíe múltiples peticiones al puerto destino empleando diferentes IP que sirven como señuelos. Se puede indicar varias direcciones IP reales o ficticias, separadas por comas. La opción RND:n generará n direcciones IP aleatorias, mientras que la opción ME indica que se emplee la IP real (se pueden combinar ambas opciones).
–randomize-hosts	Efectúa un escaneo de hosts aleatorio para modificar la firma y despistar un sistema antiintrusos.
–ip-options <especial>	Opciones avanzadas para la modificación de datos de la cabera IP de los paquetes de datos enviados. Ver: https://seclists.org/nmap-dev/2006/q3/52

Estas opciones de spoofing o evasion también son útiles para los sistemas antiintrusos, como se verá en el siguiente punto. El modo de empleo es el siguiente:

				
					nmap [Scan Type] [Options] [Spoofing-evasion options] [targets]

A continuación se muestran dos ejemplos contra el servidor SSH anterior (IP 192.168.1.41) empleando algunas de estas opciones de evasión, teniendo en cuenta la regla de Firewall (ver arriba):

				
					#Ejemplo 1
sudo nmap -sS -sV -p 22 -T4 -Pn -D RND:1,ME --data-length 50 -g 22 --mtu 32 192.168.1.41

#Ejemplo 2
sudo nmap --spoof-mac Cisco --send-ip -sS -sV -p 22 -T4 -Pn --data-length 30 --randomize-hosts -f --source-port 22 192.168.1.41

Como se aprecia en la imagen, el resultado no es satisfactorio pues la regla de bloqueo se efectúa sobre una determinada IP (la del atacante). A pesar de esto, aún queda un as en la manga que consiste en efectuar la técnica de IDLE Scanning (ver siguiente punto). Para el primer ejemplo, se ha generado una petición ficticia para la dirección 149.246.19.191 junto a la IP del atacante (opción RND:1,ME). Además, se ha realizado una fragmentación de los paquetes por valores de 32 bytes, contiendo un tamaño de payload de 50. Como se puede apreciar, al no haber una restricción sobre la IP ficticia, el servidor SSH ha enviado una respuesta ACK/SYN hacia este, obviamente sin resultado.

3.3.2.5.4. Escaneo de puertos con Firewall: IDLE Scan

La técnica IDLE Scan para el escaneo de puertos fue desarrollada por el investigador en seguridad Antirez. Resumiendo mucho, esta técnica permite obtener información acerca de si un puerto de un host o router está filtrado por algún Firewall empleando para ello de forma (in)directa un host zombi que está afectado por una determinada vulnerabilidad.

Esta vulnerabilidad está basada en los valores generados del parámetro IPID que sirve para identificar un fragmento de un paquete IP. Este valor lo genera el Sistema Operativo y cuando es secuencial en el host zombi, permite inferir información valiosa a través del intercambio de paquetes entre el atacante, el host zombi y la víctima. El objetivo principal de un IDLE Scan es ver si alguno de los puertos de la víctima esta filtrado por algún Firewall.

A continuación se describe cómo funciona este tipo de escaneo y como permite inferir información, siempre y cuando el host zombi esté operativo en algún servicio y no tenga restricciones para efectuar peticiones a la máquina víctima. Se supone que en la máquina víctima actúa un Firewall que no permite peticiones entrantes de la máquina atacante (hacker):

Se envía un paquete de datos SYN/ACK al host zombi. Este, al no haber recibido anteriormente una petición formal de conexión (SYN), responderá con un paquete RST con un determinado valor de IPID, generado por su Sistema Operativo.
El atacante ahora envía un paquete SYN a la máquina víctima (target) haciendo spoofing con la IP del host zombi. Como se supone que el Firewall no bloquea las peticiones del host zombi, en el caso de que el puerto esté abierto, la máquina víctima enviará un paquete SYN/ACK al zombi. El host zombi, como en el punto 1, responderá con un paquete RST y aumentará en 1 el IPID, al estar afectado por la vulnerabilidad.
Para terminar de confirmar que los servicios de la máquina víctima están filtrados por un Firewall, se vuelve a efectuar la misma operación que en el punto 1. Si el valor de IPID ha aumentado en 2 respecto al valor original, significaría que efectivamente hay un Firewall operando en la máquina víctima. Por el contrario, si solo hubiera aumentado en 1, es que los servicios de la máquina víctima están simplemente cerrados.

NMAP permite automatizar este proceso. Una vez localizada la máquina víctima, que aparentemente tiene los puertos cerrados, este proceso consiste primero en emplear un script para identificar si algún host en una red está afectado por la vulnerabilidad del IPID secuencial y emplearlo como zombi. Este script es el ipidseq. Por defecto, en las últimas versiones (en el momento de escribir esto), este script está afectado por algún error cuando se emplea:

Para solucionar este problema, se debe modificar el código del script ubicado en el directorio de scripts. Se debe sustituir de forma entera (copiando y pegando, con algún editor de texto) por el código que puede encontrarse en el repositorio GitHub (https://raw.githubusercontent.com/nmap/nmap/master/scripts/ipidseq.nse).

Una vez arreglado el script, se puede emplear añadiendo como target un número CIDR (identificación de red). En el siguiente ejemplo, se ha empleado el script contra un servidor del cual se sabe que está afectado por la vulnerabilidad para poder ver mejor el funcionamiento de la técnica. Si algún target está afectado por esta vulnerabilidad, en el resultado aparecerá Incremental como se muestra en la imagen.

				
					nmap [opciones] --script ipidseq [target (red)]

Ahora ya se puede emplear el host con IP 192.168.1.39 del ejemplo como zombi. Suponiendo que este host no tiene restricciones para efectuar peticiones a la maquina víctima, para realizar un IDLE Scan, se emplea el parámetro –sI (i mayúscula) seguido de la IP del zombi y el target. Como puede apreciarse, mientras que en primer escaneo de nuevo el Firewall bloquea la petición del atacante, en el resultado del IDLE Scan si muestra como el puerto en realidad está abierto (pero filtrado por un Firewall).

				
					nmap [opciones] -sI [zombie] [target]

Para ver más ejemplos y ventajas de este sistema de escaneo, se recomienda consultar la página oficial de NMAP, que tiene una sección dedicada y traducida muy interesante (https://nmap.org/idlescan-es.html).

3.3.2.5.5. Escano de puertos con sistema de detección de intrusos

Además de Firewalls, es común encontrar en grandes empresas o entidades públicas otros componentes para prevenir ataques e intrusiones. Estos componentes son aplicaciones especializadas que monitorizan el tráfico entrante y saliente de la red, y suelen operar en sectores de red estratégicos (subredes, servidores restringidos, servicios en host de conexión remota, etc.). Dependiendo de su función, se pueden clasificar en los siguientes tipos (aunque es habitual que un mismo software pueda ejecutar funciones hibridas):

NIDS: Network Instrusion Detection System
- Son sistema de detección de intrusiones. Monitorizan el tráfico y emiten mensajes de alerta, almacenándolos en logs.
- Funcionan como un sniffing de paquetes de red, solo que previamente deberán configurarse una serie de parámetros o reglas para identificar algún tráfico de red sospechoso sobre un sector de red o un host específico y así emitir la alarma.
NIPS: Network Prevention Detection System
- Son sistemas de prevención de intrusiones. En la práctica funcionan como un NIDS, llevando a cabo un análisis del tráfico en tiempo real e identificando a través de patrones, anomalías o comportamientos sospechosos un acceso no autorizado o algún tipo de ataque.
- A diferencia de un NIDS, puede descartar tráfico y bloquear conexiones entrantes y salientes sobre el sector de red o host sobre el que actúa.

Estas aplicaciones suelen combinarse con sistemas de gestión de eventos e información (SIEM, de las siglas en inglés Security Information and Event Management) que centralizan la gestión de tareas relacionadas con la seguridad informática de una red. También se incluyen dentro de un UTM o sistema de Gestión Unificada de Amenazas, de las siglas en inglés Unified Threat Management, que consiste en juntar una serie de elementos para la seguridad perimetral que incluye antivirus, firewalls, sistemas de VPN, IDS/IPS, etc.

Como se verá en los siguientes ejemplos, a la hora de instalar y configurar estos productos, hay que pensar previamente para que sector de red o host va a operar, sobre qué servicios y puertos, si se quiere solo para almacenar logs de movimientos sospechosos o bien restringir directamente ciertas operaciones, etc. Una mala configuración puede suponer falsas alarmas, bloqueos de tráfico innecesarios, ralentizar el tráfico de red o bien ser sencillamente innecesario.

Tanto en el mercado como en formato open source, pueden encontrarse una amplia gama de productos que combinan funciones de detección y prevención. Los siguientes ejemplos se realizarán a través de SNORT, que combina funciones de NIDS/NIPS SNORT (hay un anexo de OBLIGADA LECTURA ANTES donde se explica la instalación y configuración de este software).

Configuración de reglas para la detección de intrusos en SNORT

Una vez instalado SNORT se deben configurar las reglas para determinar el sistema de alertas y su almacenaje a través de logs. Existen una serie de elementos a controlar para configurarlas correctamente (ver anexo de nuevo si es necesario).

1. Variables de red: En el primer apartado del fichero de configuración general de SNORT en / etc / snort / snort.conf se pueden introducir las variables $HOME_NET y $EXTERNAL_NET con un editor de texto, que posteriormente pueden emplearse para determinar las reglas sin tener que escribir reiteradas veces el segmento de red (CIDR) o host (IP) sobre el que operará SNORT. Como se indica en los comentarios del fichero, suele indicarse en $HOME_NET el segmento que hay que proteger, mientras que en $EXTERNAL_NET, al referirse a cualquier IP que pueda proceder de Internet, se puede dejar en any (cualquiera).

2. Preprocessors: Son componentes habituales en un NIDS y realizan operaciones de análisis del tráfico de red justo antes de iniciar el motor de detección de intrusos. También están disponibles para indicar su uso mediante directivas en el fichero de configuración general de SNORT. La configuración por defecto incluye (descomentados, sin #) algunos de los más importantes como son frag3_global, frag3_engine y stream5_global. A su vez, estos se pueden parametrizar. Se recomienda no modificar la configuración por defecto salvo si se es experto (para más información, ver en la web de SNORT). La sintaxis es:

				
					preprocessor <nombre_preprocessor>: <parametro1 valor_parametro1> …

3. Configuración de reglas: Estas se imputan en el fichero etc / snort / rules / local.rules. Las reglas se escriben con una determinada sintaxis para todos los casos. Se debe destacar la obligatoriedad de incluir una cabecera en donde indicar el tipo de acción a realizar, el protocolo a controlar y sobre que flujo establecer este control, si es tráfico saliente o entrante y a que puertos de entrada y salida. También se pueden incluir una serie de variables opcionales para afinar la detección como es el control del flujo en la conexión, el contenido del paquete de datos (payload), etiquetas TCP activas, etc.

El siguiente cuadro es un esquema de cómo deben escribirse las reglas:

Ejemplos de reglas SNORT

A continuación se describe con ejemplos el funcionamiento de las reglas, algunas de las cuales van a emplearse con NMAP. Hay que recordar que para las reglas locales el SID (número de identificación) debe tener un valor superior a 10000001. Por otro lado, hay que considerar siempre si el flujo es entrante o saliente y respecto a que red (interna o externa) se produce mediante las flechas:

				
					#ICMP alert
alert icmp any any -> $HOME_NET any (msg:"ICMP test"; sid:10000001; rev:001;)

SID: 10000001 → Regla usada en la comprobación de configuración tras instalación para PING.

				
					#NMAP scan, conection alerts
#TCP SCAN (-sT) or RANDOM CONECTION)
alert tcp any any -> $HOME_NET 80,22 (msg: "TCP connection";sid:10000002; rev:001;)

SID: 10000002 → Alerta de cualquier conexión TCP (todas las etiquetas) que se realiza desde el exterior hacía la red local ($HOME_NET) sobre los puertos 22 y 80, donde se hallan sendos servidores SSH y Web. Si se trata de un Servidor Web público de mucha concurrencia, esta regla puede resultar poco práctica, funcionando más bien como un sistema de logs de conexión.

				
					#XMAS SCAN (-sX)
alert tcp any any -> $HOME_NET any (msg: "Nmap XMAS Scan"; flags:FPU; sid:1000003; rev:001;)

SID: 10000003 → Alerta de cualquier escaneo realizado con la técnica de XMAS SCAN, que utiliza las etiquetas F, P y U del protocolo TCP que se realiza desde el exterior hacía la red local ($HOME_NET) sobre cualquier puerto.

				
					#FIN SCAN (-sF)
alert tcp any any -> $HOME_NET any (msg:"Nmap FIN Scan"; flags:F; sid:10000004; rev:001;)

SID: 10000004 → Alerta de cualquier escaneo realizado con la técnica de FIN SCAN, que utiliza las etiquetas F del protocolo TCP que se realiza desde el exterior hacía la red local ($HOME_NET) sobre cualquier puerto.

				
					#SSH ALERT LOGIN
alert tcp $HOME_NET 22 -> any any (msg: "Error autentication SSH"; sid:10000005; rev:001;)

SID: 10000005 → Permite detectar algún error de autenticación en el servidor SSH. En este caso, el flujo se realiza desde la red protegida (local) hacia la red exterior, a través del puerto 22.

				
					#CONNECT TO DATABASE SQL SHOW DATABASES
alert tcp any any -> $HOME_NET 3306 (msg:"MYSQL show databases attempt"; flow:to_server,established; content:"|0F 00 00 00 03|show databases"; sid:10000006; rev: 001;)

SID: 10000006 → Permite detectar alguna conexión a un servidor local de SQL cuyo servicio opera en el puerto 3306 desde el exterior. En este caso, el flujo entre cliente y servidor se ha asegurado y el atacante ha realizado una consulta (query) solicitando información de las bases de datos (show databases, también en hexadecimal).

				
					#CONNECT TO FACEBOOK
log tcp $HOME_NET any -> $EXTERNAL_NET 80,443 (msg:"Conexión a facebook"; content: "facebook.com"; sid: 10000007; rev:001;)

SID: 10000007 → Permite detectar alguna petición de conexión desde la red local al servidor web cuyo dominio es facebook.com.

				
					#REMOTE DESTINATION BOTNET (?)
alert tcp $HOME_NET any -> $EXTERNAL_NET 4444:5555 (msg:"Posible conexión remota"; sid: 1000008; rev:001;)

SID: 10000008 → Permite detectar si desde la red local se están realizando envío de datos a la red externa (Internet), hacia los puertos del 4444 al 5555, que suelen emplearse en aplicaciones de piratería, troyanos, botnets y similares.

Pruebas de detección de intrusos con SNORT

Para terminar esta sección, se van a realizar pruebas de control sobre las reglas anteriores cuyo valor es SID: 10000003 (NMAP FIN SCAN) y SID: 10000004 (error de autenticación en servidor SSH).

En el primer caso, se realizan dos escaneos con NMAP sobre el servidor web local en el que opera SNORT (192.168.1.44). El primero de ellos con la técnica de FIN SCAN y el segundo con la técnica SYN SCAN, para la cual no existe una regla de alerta. En ambos casos, se realiza fragmentación (-f) y sin PING.

				
					nmap -sF -Pn -f -p 80 192.168.1.44
nmap -sS -Pn -f -p 80 192.168.1.44

En el segundo caso, se realiza una petición de conexión al servidor SSH del mismo host, con resultado fallido tras varios intentos con el cliente SSH de Putty:

Como es de esperar, al iniciar SNORT en modo no pasivo, la aplicación advierte del escaneo de NMAP del tipo FIN y del error de autenticación, pero en cambio no ha advertido del escaneo silencioso (SYN SCAN) al no estar configurada la regla.

En estas prácticas se ha primado la comprensión del funcionamiento de un NIDS/NIPS basándose en pocos ejemplos prácticos en vez de realizar muchos ejemplos que llevarían a las mismas conclusiones. Las conclusiones son que si un sistema de detección de intrusos está bien configurado y operando en sectores estratégicos, será muy difícil evadir el ser detectado con una escaneo de puertos.

La recomendación al realizar escaneos sobre grandes organizaciones que cuentan con una infraestructura tecnológica superior y pueden contar con estos sistemas, es emplear en la medida de lo posible las opciones de escaneo que hagan menos ruido (SYN SCAN), realizar las opciones de fragmentación de los paquetes de red y también emplear el parámetro –T que regula la velocidad del escaneo en valores bajos.

3.3.2.5.6. Túnel SSH dinámico

Anteriormente se ha visto la técnica de IDLE Scan para realizar escaneo de puertos y así obtener información en determinadas situaciones cuando un Firewall u otro elemento protege una red. No obstante, existen otras técnicas que también permiten evadir los sistemas de protección de una red. Una de estas técnicas consiste en emplear un Túnel SSH o reenvío de puertos SSH. Basándose en las característica del protocolo SSH (Secure Shell), esta técnica consisten en encapsular (por eso se denomina túnel) el tráfico de red habitual sobre el protocolo SSH, permitiendo a los paquetes de datos viajar a través del túnel SSH.

Los túneles SSH permiten que las conexiones realizadas a un puerto local (es decir, a un puerto en el host que se está empleando) se reenvíen a una máquina remota a través de un canal seguro. Esto se puede realizar a través de un cliente SSH que se conecte a servidor SSH remoto. A parte de añadir una capa de seguridad en el tráfico por el cifrado, también será posible acceder a la red remota del servidor SSH, especificando un reenvío de puertos que permite establecer las conexiones a ese servicio remoto y a su red.

En un caso práctico, supongamos que el atacante (IP: 192.168.1.37) desea acceder al host remoto Windows10 (IP: 192.168.1.41). El host remoto está protegido por un Firewall que bloquea todas las peticiones entrantes, excepto para el host Metasploitable2 (IP: 192.168.1.37). Se descubre en el host Metasploitable un servicio de SSH vulnerable, al cual es posible acceder conociendo el usuario y contraseña. En este caso, se podrá realizar la técnica de Túnel SSH para acceder a realizar un escaneo de puertos contra el host remoto Windows10.

El uso de túneles SSH es habitual en auditorías de seguridad cuando los administradores de redes habilitan a los auditores un servidor SSH para así poder acceder a la red local. También se utilitzan para añadir una cada de seguridad cuando un usuario de conecta a una wifi pública, encriptando las comunicaciones. Finalmente, también es util para usuarios de Internet que desean acceder a servicios que en sus países están restringidos.

En el siguiente ejemplo, se va a utilitzar la forma dinámica del túnel SSH o SSH Dynamic Port Forwarding. La característica principal de esta modalidad es que el tráfico enviado por el cliente SSH se realiza a través del protocolo SOCKS, el mismo que utilitza por ejemplo la red TOR. En términos técnicos, se va a crear un proxy SOCKS que escuchará las conexiones en el puerto destinado al protocolo SOCKS (p. ej.: 9050). Al recibir una solicitud se va a enrutar el tráfico a través del canal SSH establecido entre la máquina del atacante y la red externa a la que se conecta mediante el servidor SSH remoto.

Para realizar las funciones de túnel SSH dinámico se va a utilitzar la herramienta proxychains, que ya se usó para mostrar técnicas de ocultación de IP. Existe un apéndice para la configuración de proxychains con TOR. No obstante, se puede revisar en el fichero / etc / proxychains.conf que al utilizar proxychains se va a enrutar el tráfico a través del protocolo SOCKS, configurando como registro de proxy el host local como servidor (127.0.0.1) y especifando el puerto 9050.

				
					socks5 127.0.0.1 9050

Ahora sí, para crear el túnel SSH se va a utilizar en Kali Linux el cliente SSH que viene por defecto. Para emplear el cliente SSH y conectarse al servidor remoto se puede utilizar la siguiente sintaxis, teniendo que introducir a continuación la contraseña del usuario de host remoto (suponiendo que el puerto que da acceso al servicio es el 22, que es lo usual):

				
					ssh -p 22 -l <usuario> <IP_servidor_SSH>

Para crear el túnel dinámico, deben añadirse los parámetros -N -D y el puerto local para SOCKS, quedando así (IP Servidor SSH remoto: 192.168.1.43):

				
					ssh -p 22 -l <usuario> -N –D <puerto_SOCKS_local> <IP_servidor_remoto_SSH>

Nota: Se puede comprobar que el túnel se ha realizado correctamente empleando la siguiente línea de comandos:

				
					proxychains wget -q0- <IP_servidor_remoto_SSH>

Deberá aparecer algo como:

				
					<IP_host_local>:9050 < > <IP_servidor_remoto_SSH>:80 - <> <> - OK

Una vez creado el túnel (debe mantenerse activo), es el momento de comprobar que se puede efectuar el escaneo de puertos contra el target pretendido inicialmente (IP: 192.168.1.41), al cual es posible acceder a través del servidor SSH, que sí tiene permitidas las comunicaciones. Se puede ver en la siguiente pantalla como el primer escaneo de puertos con NMAP resulta infructuoso, mientras que el segundo, empleando la herramienta de proxychains devuelve la información esperada (en este caso, el target también dispone de un servicio SSH en el puerto 22, habilitado para las pruebas):

				
					proxychains <nmap>

Además de poder obtener información sobre el estado de los puertos y servicios del target, con el túnel SSH también es posible realizar más acciones, como conectarse de forma remota al servidor SSH del target, empleando para ello siempre proxychains, que proporciona la función del túnel SSH dinámica:

				
					proxychains ssh –l <usuario> <IP_Target>