Identificando tráfico con cortafuegos, Parte II

Hablábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de identificar los protocolos e instrucciones para limitar aquellas acciones que pueden realizar sobre Sistemas de Control Industrial. Para llevar a cabo esta acción, podemos emplear soluciones como Nozomi SCADAGuardian la cual, entre otras funciones, permite realizar Deep Packet Inspection (DPI) y extraer la información que necesitamos.

Sin embargo, los  mismos cortafuegos que nos ayudan a “Separar y Segmentar” podrán ayudarnos en esta tarea. En “Identificando tráfico con cortafuegos, Parte I” veíamos como podríamos hacerlo con equipamiento del fabricante Fortinet. En el día de hoy abordaremos la misma tarea, pero con aquellos del fabricante Palo Alto.

El mismo, dispone del equipo PA-220R para proteger este tipo de entornos teniendo la capacidad para realizar DPI sobre protocolos de esta índole. Además, es apto para instalaciones de entornos tales como subestaciones o plantas generadoras de energía ya que dispone de compatibilidad con estándares como IEC 61850-3 e IEEE 1613. Sus características físicas le permiten operar en rangos de temperatura y humedad de -40-70º C y 10-90%; respectivamente, pudiendo evitar daños físicos en entornos hostiles y polvo en suspensión ya que carece de piezas móviles para su refrigeración. Igualmente dispone de doble alimentación proporcionando así redundancia en lo que suministro eléctrico se refiere.

Palo Alto 220R

Dicho lo cual, veremos que las interfaces pueden ser configuradas de distintos modos, entre ellas el “TAP” con el que podremos monitorizar y analizar el tráfico que le llega.

Configuration TAP Port Palo Alto Firewall

Más tarde, definiremos una “Zona” en la cual incluir la interfaz que recibirá el tráfico que replicaremos desde el puerto espejo del switch o un dispositivo TAP. La denominaremos “Analisis_Trafico_ICS” y le asignaremos la interfaz “ethernet1/8”.

Configuration Zone Palo Alto Firewall

Luego, habrá que crear una política en la que deberemos indicar como origen y destino la Zona configurada en los puntos anteriores e indicar qué aplicaciones queremos detectar.  En nuestro caso seleccionaremos “Any” para poder hacerlo sobre todas aquellas que recojan las firmas que hayan sido desarrolladas hasta el momento.

Configuration Application Palo Alto Firewall

Adicionalmente podremos habilitar otros controles para la detección de amenazas tales como antivirus, vulnerabilidades, filtrado URL, etc. Esto nos permitirá identificar la presencia de actividades o tráfico malicioso ya presente en nuestra red. Como se puede apreciar hemos creado un “Security Profile Group” con alguno de ellos.

Configuration Security Profile Group Palo Alto

Hecho esto, el siguiente paso será comenzar a procesar tráfico. De igual modo que hicimos en la entrada “Identificando tráfico con cortafuegos, Parte I”, reproduciremos tráfico con la herramienta TCPReplay previamente capturado a partir de distintas fuentes. En este nos hemos decantado por IEC 60870-5-104 y BACnet.

A partir de aquí, en la pestaña “Monitor” podremos ver los logs generados según distintos resultados de ese análisis. Por ejemplo, continuación se muestra el contenido relativo al tráfico en sí mismo, esto es, IPs de origen destino, puertos, Aplicación, etc.Detecting Industrial traffic and protocol Palo Alto Firewall

Detecting Industrial Traffic and protocol Palo Alto Firewall

Pero como hemos dicho, también nos interesa analizar en busca de amenazas como intentos de intrusión, malware, etc. Esta información la localizamos en el subapartado “Threat”. En este caso vemos cómo de entre las capturas reproducidas identificamos la presencia del archiconocido “Wannacry”, algunas anomalías relativas a Siemens S7 o DNP3.

Detecting Threats Palo Alto Firewall

Threats Panel on Aplo Alto Firewall

Con la interoperabilidad entre entornos IT y OT, es imprescindible conocer las comunicaciones que se realizan hacia/desde los equipos. Un activo no sólo se compone de los datos de fabricante, modelo, instalación, etc. también han de incluirse sus comunicaciones dentro del modelo de gestión de activos. Un firewall y sus funcionalidades extras serán tan eficientes como estrictos seamos con su configuración y mantenimiento.

Pero, para conseguirlo, hemos hacer la tarea previa de identificarlas y estructurarlas y para ello los mismos cortafuegos también pueden ayudarnos.

Un saludo, ¡nos vemos en la siguiente!

 

Transferencia de Zona en DNS

Aquí estamos con otra entrada, la primera en este 2013. A ver si gusta y se convierte en un buen presagio para el resto del año.

 En esta ocasión vamos a meternos con DNS. Como muchos sabréis DNS es un protocolo que permite asociar, de forma jerárquica, nombres de dominio a IPs así como identificar hosts dentro de estos dominios. Para los que no lo conozcan os dejo el enlace de la Wikipedia donde se habla de este protocolo, pinchar aquí.

Dejando de lado el servicio que presta en Internet, vamos a ceñirnos esta vez al ámbito empresarial. Muchas organizaciones contarán con su propio servidor DNS para resolver los nombres de equipos en direcciones IP para un dominio concreto, que es al fin y al cabo, lo que emplean los sistemas operativos y las aplicaciones para establecer conexiones contra otros hosts, principalmente servidores. En este caso se utilizará DNS sobre protocolo UDP y el puerto 53. Cabe mencionar que en muchos casos el servidor DNS presta servicios de DHCP, o viceversa. Si bien servidores, impresoras, u otros equipos tendrán un direccionamiento estático, los equipos finales podrán emplear un direccionamiento asignado mediante DHCP. Si ambos servicios son prestados por el mismo equipo, cuando la parte de DHCP asigne una dirección IP, automáticamente se generará un registro DNS para ese equipo.

Sin embargo también existe la posibilidad de utilizarlo sobre TCP y en el mismo puerto. Pero ¿para qué se emplea? Pues para realizar Transferencias de Zona, por ejemplo de un servidor primario a uno secundario. Es decir, habrá un servidor primario DNS al que le llegan todas las consultas de los clientes (UDP:53); pudiendo existir otro, para que el caso de que el primero caiga, sea el secundario el que continúe resolviendo los nombres de máquina y así garantizar el servicio. Lógicamente el servidor secundario tiene que saber en todo momento las entradas de IPs, nombres de máquina, etc. que maneja el servidor primario. Esto se realiza mediante lo que se denomina “Transferencia de Zona”. Esto es, el servidor secundario abre una conexión mediante TCP al puerto 53 del servidor primario y le solicita todos los registros de nombres para el dominio de la empresa.

Como se puede ver un servidor DNS es una gran fuente de información, y como tal también hay que tomar medidas en lo que a la seguridad se refiere. ¿Por qué? Porque si no restringimos de alguna forma y mantenemos el servidor primario con el puerto TCP:53 abierto, “alguien” con no muy buenas intenciones podría detectarlo y solicitar realizar una trasferencia de zona y hacerse con todo el direccionamiento de nuestro dominio sin necesidad de lanzar ni un solo escaneo para detectar hosts o servicios. Aparte hay que tener en cuenta que DNS permite asociar un texto a un registro de equipo, generalmente utilizado para añadir una descripción a éste.

A continuación veremos cómo se podría desarrollar esto mismo, por supuesto en un entorno de test.

Para ello tendremos un laboratorio virtual creado con GNS3 y VMware. Tendremos 3 switches, dos de core y uno de acceso. A este último irán conectados 3 máquinas, un XP, un Windows 7 y la máquina atacante que será un Backtrack 5 R3. Y por supuesto un servidor DHCP/DNS para asignación de IPs y resolución de nombres. Quedaría algo así:

escenario

Si mantenemos nuestro Wireshark arrancado mientas ejecutamos “dhclient eth0” para solicitar una IP y capturamos el tráfico resultante veremos entre otros datos que nos proporciona DHCP el nombre del dominio en el que nos encontramos, es decir edorta.lcl.

nombre_dominio y servidor

Como podemos apreciar nuestro servidor de nombres (DNS) tiene la IP 192.168.10.5, que curiosamente es la misma IP desde la cual se nos asigna la nuestra, la 192.168.10.20. O sea, DHCP y DNS están el mismo equipo. A continuación lanzaremos nmap para saber sobre qué protocolos de Capa 4 tiene abierto el puerto 53.

root@bt:~# nmap -sU -sS -p53 192.168.10.5Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-05 19:47 CET
Nmap scan report for XXXXXXXX.edorta.lcl (192.168.10.5)
Host is up (0.00099s latency).
PORT   STATE SERVICE
53/tcp open  domain
53/udp open  domain
MAC Address: 00:0C:29:FB:52:A8 (VMware) 
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds 

¡Perfecto! Tenemos el TCP:53 “open” con lo que vamos a tratar si podemos llevar a cabo la transferencia de zona. Para ello utilizaremos la herramienta “dig”. Dig, es una utilidad que nos permitirá realizar consultas DNS de distintas formas y ajustar las opciones que nosotros deseemos. Entre ellas está la de llevar a cabo una transferencia de zona. Esto se realiza ejecutando:

root@bt:~# dig edorta.lcl axfr 
; <<>> DiG 9.7.0-P1 <<>> edorta.lcl axfr
;; global options: +cmd
edorta.lcl.                 259200   IN       SOA      XXXXXXX.edorta.lcl. hostmaster.edorta.lcl. 2012123076 28800 7200 2419200 86400
edorta.lcl.                 259200   IN       NS       XXXXXXX.edorta.lcl.
edorta.lcl.                 259200   IN       A        192.168.10.5
edorta.lcl.                 259200   IN       A        192.168.11.5
bt.edorta.lcl.              900      IN       A        192.168.10.20
bt.edorta.lcl.              900      IN       TXT      «00445d89f28c340342881e7f7a4605c117»
core-of-01.edorta.lcl.      259200   IN       A        192.168.5.10
core-of-01.edorta.lcl.      259200   IN       TXT      «switch» «01» «de» «core» «de» «oficinas»
core-of-02.edorta.lcl.      259200   IN       TXT      «switch» «02» «de» «core» «de» «oficinas»
core-of-02.edorta.lcl.      259200   IN       A        192.168.5.11
core-srv-01.edorta.lcl.     259200   IN       TXT      «switch» «01» «de» «core» «de» «servidores»
core-srv-01.edorta.lcl.     259200   IN       A        192.168.5.13
core-srv-02.edorta.lcl.     259200   IN       TXT      «switch» «02» «de» «core» «de» «servidores»
core-srv-02.edorta.lcl.     259200   IN       A        192.168.5.12
fw-01.edorta.lcl.  259200   IN       TXT      «Firewall» «Granja» «Servidores»
fw-01.edorta.lcl.  259200   IN       A        192.168.100.254
IPS-01.edorta.lcl. 259200   IN       TXT      «IPS» «Granja» «de» «servidores»
IPS-01.edorta.lcl. 259200   IN       A        192.168.100.253
of-01.edorta.lcl.  259200   IN       A        192.168.10.10
srv-01.edorta.lcl. 259200   IN       TXT      «switch» «de» «la» «granja» «de» «servidores»
srv-01.edorta.lcl. 259200   IN       A        192.168.100.10
srvficheros.edorta.lcl.     259200   IN       TXT      «Servidor» «de» «ficheros»
srvficheros.edorta.lcl.     259200   IN       A        192.168.100.5
XXXXXXX.edorta.lcl.         259200   IN       A        192.168.1.1
XXXXXXX.edorta.lcl.         259200   IN       A        192.168.10.5
XXXXXXX.edorta.lcl.         259200   IN       A        192.168.11.5
edorta.lcl.                 259200   IN       SOA      XXXXXXX.edorta.lcl. hostmaster.edorta.lcl. 2012123076 28800 7200 2419200 86400
;; Query time: 13 msec
;; SERVER: 192.168.10.5#53(192.168.10.5)
;; WHEN: Sat Jan  5 19:47:19 2013
;; XFR size: 27 records (messages 1, bytes 835) 

¡Tranferencia realizada! A continuación os dejo la captura en la que se puede apreciar el “Three Way Handshake” de TCP desde Backtrack hacia el servidor, paquetes 6 al 8. Una vez establecida la conexión el PC  realiza la consulta para la transferencia de zona, paquete 9. Y finalmente la respuesta del servidor, paquete 11, y que corresponde con la información que sale en la ventana de abajo y donde se pueden ver listados todos los equipos. 

axfr_dig

Como podemos ver tenemos los registros de los equipos que figuran en la imagen del escenario y alguno más que he metido a propósito para agregar más contenido al ejemplo. A partir de aquí un atacante podría saber los nombres de equipos, su descripción si la hubiese, IPs, redes implementadas, y otra información proporcionada por los distintos registros que emplea DNS como CNAME, MX, NS, etc.

Fijaros de qué manera más tonta, un atacante se ha ahorrado tener que lanzar escaneos para localizar equipos, servicios, etc. y así seguir avanzando en sus propósitos. Aparte, ha minimizado el riesgo de ser detectado por algún IPS o que se logue en algún firewall el descarte de paquetes de las sondas que envía NMAP. Ahora podrá ir a tiro fijo sobre un equipo. Como decía, existen algunos registros que nos indican la funcionalidad de los equipos. Tal es el caso de MX que se emplea para identificar los servidores de correo electrónico asociados a ese dominio. Por tanto, ¿tiene mucho sentido lanzar a destajo sondas para ver si tiene otros servicios abiertos con el riesgo que esto supone? Si sabemos que es un servidor de correo, lanzará las sondas a los puertos que sabemos emplea ese servicio. A ver, un servidor puede tener varios servicios corriendo en un mismo equipo, pero bueno primero vayamos contra los puertos que sabemos que puede estar utilizando. ¿Que no puede cumplir con sus objetivos? pues entonces ya realizará un escaneo para ver si corre otro servicio más vulnerable, comprometerlo y llevar a cabo otras acciones. Otro ejemplo, en la captura vemos que hay un equipo llamado “srvficheros” con una descripción acorde a su nombre. Por tanto, ¿tiene mucho sentido lanzar escaneos contra un servicio IPSEC, aplicación OpenVPN, detección de Web Proxy, etc? Mejor hacerlo al TCP:139,445; ¿no? A partir de estos detectar el sistema operativo, número de saltos, etc.

En cualquier caso lo que se pretende mostrar es la manera cómo, a partir de una mala configuración, o no afinada como debiera, un atacante podría hacerse con multitud de información que revelaría nombres de equipos, IPs, funcionalidades de servidores, si éstos corren más servicios, etc. Si además esto lo complementamos con otras técnicas mejor que mejor.

Así que, de una forma u otra deberemos proteger este servicio que de lo contrario, podría suponer una desagradable sorpresa.

Un saludo, seguiremos informando.

Wireshark y Recolección de Información

Hola de nuevo. En esta ocasión os traigo un par de lecturas elaboradas por el Instituto Nacional de Tecnologías de la Comunicación, más conocido como INTECO.

El primero de ellos habla sobre la herramienta «Wireshark», conocido sniffer y analizador de tráfico allá donde los haya; mientras que el segundo trata sobre los distintos métodos, aplicaciones, protocolos, etc. que podremos utilizar para recolectar información tanto de redes como de sistemas con vistas a un Test de Penetración.

Os dejo los enlaces de estos excelentes documentos:

«Análisis de tráfico con Wireshark»

«Pentest: Recolección de Información (Information Gathering)»

Un saludo, seguiremos informando.

Robo de archivos

Todos somos conscientes que hoy en día la información es poder y que, para cualquier organización, controlar el acceso de los usuarios a determinados documentos, bases de datos, directorios, etc. resulta obligado. La fuga de información o la adquisición de la misma de forma ilegítima, en sí misma  puede convertirse en un gran problema al margen de las repercusiones legales que puedan derivarse.  Además, el espionaje industrial, gubernamental, empresarial o incluso doméstico, viene siendo una realidad desde hace tiempo. Flame, Stuxnet, Zeus, Spyeye, son algunos de los ejemplos más conocidos.

Pero ciñéndonos a entornos locales empresariales, el acceso y explotación de la documentación e información almacenada en ficheros  no deja de ser menos importante. Ni tan siquiera para una PYME. Por ejemplo, imaginemos un empleado descontento que decide copiarse los datos de clientes, cuentas bancarias, precios, números de teléfono, etc.  y decide filtrarlo o publicarlo en una clara maniobra de desprestigio o sabotaje. Incluso, dependiendo de la actividad de la empresa, por ejemplo sector sanitario, divulgar información de personas que la LOPD pueda perseguir y penalizar, y que cuando menos,  puede desembocar en multas elevadas.

Llegados a este punto, y sin extendernos demasiado, llegamos a la conclusión que la seguridad interna es vital tenga la organización en cuestión, el tamaño que tenga. Por tanto, hay que controlar  si  tal o cual usuario,  debe tener acceso a un archivo y lo que puede hacer con él. Pero ¿es suficiente con implementar permisos específicos sobre archivos y filtrar con firewalls el tráfico de red? Si bien esto es igualmente necesario, muchas veces nos centramos en proteger aquellos servidores que prestan uno u otro servicio, y nos olvidamos que todo (o casi) va sobre tramas, paquetes o segmentos. La seguridad no sólo  hay que aplicarla a los sistemas, también a la infraestructura que permite que éstos se comuniquen.

Imaginemos por un momento un escenario en el que nuestro Jefe, él y sólo él tiene acceso a un servidor donde se aloja información confidencial. Obviamente no tiene un switch y un cable para él solo, sino que tanto él como nosotros estamos conectados al mismo y con toda seguridad, a la misma VLAN. De ahí, por medio de equipos de conmutación multicapa, o routers, llegamos a la granja donde se encuentra nuestro servidor de ficheros, situado ahí sí, en una VLAN distinta a la nuestra.

Para la ocasión he creado una red de la cual he sacado la parte que nos interesa, como veréis tampoco está toda:

En resumen, el “Jefe” tiene acceso al servidor de fichero mientras que el “Atacante” no tiene acceso a nada, ya que hemos incluido en el switch “CORE_OF_01” una ACL (Access Control List, Lista de Control de Acceso) que deniegue todo el tráfico de la IP 192.168.10.20 a cualquier destino y permita solo el tráfico de la 192.168.10.22 a la 192.168.100.100. Puesto que cada ACL lleva implícito un deny any any sólo nos bastará con autorizar al equipo del jefe, ya que el resto de tráfico quedará denegado. Configuraremos entonces:

core-of-01(config)# access-list 100 permit ip host 192.168.10.22 host 192.168.100.100
core-of-01(config)#interface vlan 10
core-of-01(config-if)#ip access-group 100 in

Prueba de ello es que no llegamos al servido desde el equipo Atacante:

C:\Documents and Settings\Administrador>ipconfig
Configuración IP de Windows
Adaptador Ethernet Conexión de área local          :
Sufijo de conexión específica DNS : edorta.lcl
Dirección IP. . . . . . . . . . . . . . . . . . . : 192.168.10.20
Máscara de subred . . . . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada   : 192.168.10.1

C:\Documents and Settings\Administrador>ping 192.168.100.100
Haciendo ping a 192.168.100.100 con 32 bytes de datos:

Respuesta desde 192.168.10.2: Red de destino inaccesible.
Respuesta desde 192.168.10.2: Red de destino inaccesible.
Respuesta desde 192.168.10.2: Red de destino inaccesible.
Respuesta desde 192.168.10.2: Red de destino inaccesible.

Estadísticas de ping para 192.168.100.100:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos)

A pesar de las limitaciones impuestas, veremos cómo hacernos con aquellos documentos que el “Jefe” consultará. Para ello en el equipo atacante utilizaremos una técnica y dos aplicaciones. La técnica es la archiconocida ARP Spoofing o ARP Poisonig, para llevar a cabo un MITM (Man In The Middle, Hombre en el medio), es decir haremos que todo el tráfico generado por el jefe hacia otras redes (en nuestro caso la del servidor, la 192.168.100.0/24) pase por el ordenador atacante mediante el envío de tramas ARP Reply que envenenarán su caché ARP, indicándole que la MAC de la puerta de enlace,  192.168.10.1, sea la MAC del atacante. Haremos lo mismo con el router, le diremos que la MAC del equipo 192.168.10.22 es la MAC del Atacante. Con ello el Atacante deberá enrutar todo el tráfico recibido por ambas partes para que éstas se comuniquen.

Como aplicaciones utilizaremos, por un lado, Caín para llevar a cabo el ARP Spoofing y Networkminer para capturar tráfico e interpretarlo. NetworkMiner, según definen la propia página web, es una herramienta  de análisis forense de red  que nos permitirá capturar tráfico para un posterior análisis y así detectar nombres de equipos, sesiones, ficheros, etc.

Primero ejecutaremos Caín y acudiremos a la pestaña Sniffer, y dentro de ésta en la de Hosts para llevar a cabo un escaneo de red pulsando en el símbolo + de color azul:

Detectados los host activos, el siguiente paso será hacer el ARP Spoofing.  Para ello nos iremos a la siguiente pestaña la APR desde donde lanzaremos el ataque como tal. Para ello seleccionaremos en la parte de la izquierda la IP del equipo víctima (el Jefe) y en la izquierda la puerta de enlace.

 

Finalmente le daremos al símbolo de color amarillo y veremos como empieza el envenenamiento:

Ahora, le toca turno a NetworkMiner. Para ello nos descargaremos la aplicación e instalaremos .NET Framework 2.0 si no lo tenemos instalado ya en nuestro equipo.

Seleccionaremos la tarjeta de red sobre la cual queremos capturar paquetes y presionamos start:

A media que el Jefe acceda a los ficheros en el servidor veremos cómo éstos van a ir apareciendo en la pestaña Files. En nuestro ejemplo Confidencial.docx y Confidencial.pdf:

Si pinchamos sobre alguno de ellos y seleccionamos en Open Folderaccederemos a la carpeta donde se guardan y una vez allí podremos abrir y ver su contenido:

NetworkMiner ofrece otras opciones entre ellas la posibilidad de ver imágenes. Imaginaros si en una de esas en lugar de un documento con información interesante le pillamos visitando su perfil de Facebook y capturamos sus fotos…. Ejem ejem. Mejor ni pensarlo…

En resumen, la seguridad no pasa solamente por proteger los servidores ni filtrar el tráfico de red por medio de firewalls, IPs’s, etc. ya que la amenaza también puede estar en el extremo del usuario, el más vulnerable. Si bien son medidas necesarias, no son las únicas para prevenir la fuga o acceso no autorizado a determinados archivos, que vaya uno a saber con qué fin serán utilizados. Si bien hay equipos de red que impiden los ataques mediante ARP Spoofing no todos cuentan con esta posibilidad, y los que la tienen no siempre están configurados para ello. Una vez más los administradores de redes y sistemas debemos trabajar conjuntamente.

Seguiremos informado….