Un Firewall es un accesorio de cocina (Probando ISA Server 2006)

Notas sobre este articulo: Este articulo esta publicado en ingles en isaserver.org (http://www.isaserver.org/tutorials/ISA-Server-2006-Kitchen-Utensil-Part1.html)

Un firewall es un accesorio de cocina

Normalmente la gente ve los firewalls como si fueran sólidos muros llameantes, como la milagrosa solución a todos los problemas de seguridad en las empresas.

Los firewalls hacen que la gente se sienta segura, pero desgraciadamente los firewalls no hacen seguras las redes, en realidad solo las hacen algo más seguras.

En mi opinión los firewalls son coladores, el tamaño de los agujeros del colador depende de cómo es administrado el firewall.

Según esta teoría los hackers serian como los grumos que no quieres en tu zumo 😀

Los usuarios legítimos de los servicios acceden a ellos a través de los agujeros del colador, por lo tanto la seguridad dentro de los servicios accesibles a través del firewall es tan importante como la del propio firewall en si.

En teoría ¿si un administrador de seguridad estuviera completamente seguro de la seguridad de sus servidores necesitaría firewalls?, yo opino que si.

He terminado de configurar mi firewall, ¿ahora que hago?

En realidad ahora empieza lo difícil, tienes que asegurarte de que tu firewall hace lo que realmente tú crees que hace.               

También tienes que asegurarte de que la seguridad que te ofrece el firewall no se degrade con el tiempo debido a una mala administración.

En este artículo podrás aprender más sobre:

· Como probar un firewall con ISA 2006.

· Como ISA 2006 reacciona a un ataque.

· Algunas herramientas que los hackers podrían usar para atacar tu red.

· Algunas nuevas funcionalidades de ISA 2006

La siguiente figura muestra la red de ejemplo que se usara en este artículo.

Diagrama 1. Red de Ejemplo

No te lo creas, pruebalo

Después de que hayas instalado tu firewall y creado las reglas iniciales, la primera cosa que debes hacer es auditar tu firewall.

Auditando tu firewall desde dentro y desde fuera de tu red, obtendrás una clara visión de cual es tu superficie de ataque.

La primera cosa que un hacker hará si quiere atacar tu sistema es encontrar información sobre el.

Una de las fuentes de información más valiosa que un hacker puede tener son los port scanners.

Por esta razón un administrador de seguridad, debe conocer como sus sistemas reaccionan a un scan y que información obtendrán los atacantes al escanearle.

Una de las herramientas más famosas para hacer port scanning es NMap.

Nmap es una de código abierto que soporta docenas de técnicas de escaneo, además provee de algunas técnicas que en teoría se denominan “ocultas” y con las cuales se supone que los sistemas escaneados no deberían detectar que lo han sido.

Puedes encontrar NMap y más información sobre el en: Insecure.org

En arquitecturas informáticas enfocadas en la seguridad, es común encontrar IDS e IPS que pueden detectar escaneos, las técnicas “ocultas” tratan de engañarlos para que no sean detectados.

Ahora vamos a scanear nuestro firewall en la red de ejemplo, durante esta parte del test, debes recordar que el puerto 80 del firewall esta publicando una web y por lo tanto esta abierto.

Figura 1. Escaneo basico NMap Scan (sS)

NMap Detecta el puerto 80 abierto.

Pero ISA Server detecta varias cosas extrañas en la actividad de red; el número de conexiones que NMap establece para realizar el escaneo hace que ISA lance una alerta y escriba un evento en el log.

Figura 2. Alerta de conexiones denegadas por minuto.

Esta alerta también escribe un evento en el visor de sucesos, este evento es fácilmente capturable desde herramientas de monitorización como MOM.

Figura 3 . Evento de conexiones denegadas por minuto.

Esta alerta es producida por una nueva funcionalidad de ISA 2006 que trata de evitar ataques de tipo DOS y gusanos, al final de este articulo hablaremos mas sobre estas nuevas funcionalidades.

Pese a que en un escaneo básico con NMap se usa una técnica llamada SYN que en teoría es de las denominadas “ocultas”, ISA Server detecta el trafico y obviamente lo deniega, excepto por supuesto el dirigido al Puerto 80 que esta abierto.

Figura 4. Trafico Denegado y aceptado.

Cuando una regla de ISA Server deniega un paquete, el firewall hace un “drop” del paquete y de la conexión, debido a este comportamiento, los port scanners no pueden saber si el puerto esta cerrado o filtrado, dado que no reciben ningún tipo de contestación.

Otra famosa técnica de escaneado es usar paquetes fragmentados, ISA Server solo corre en servidores Windows y Windows por defecto descarta todo el tráfico fragmentado, por esta razón escanear un ISA con paquetes fragmentados no tendrá ningún resultado.

ISA 2006 por defecto no escribe ninguna alerta o evento sobre escaneos de puertos, para cambiar esto, hay que configurar el firewall de forma específica:

Figura 5. Habilitar la detección de escaneos (paso 1).

Figura 6. Habilitar la detección de escaneos (paso 2).

Para mas información sobre esta configuración puedes leer el siguiente artículo de Microsoft: ISA Server Port Scan Alerts .

Después de que hayas activado estas opciones, ISA Server escribirá una alerta y un evento cada vez que detecte un escaneo que cumpla con las condiciones que hayas especificado.

Si después de este cambio, escaneamos de Nuevo el firewall veremos la siguiente alerta:

Figura 7. Alerta de escaneo de puertos detectado.

También se escribe un evento en el visor de eventos, si tenemos MOM, este evento es recogido también por el management pack de MOM para ISA 2006.

Nmap provee de otras técnicas de escaneo, en este articulo las probaremos todas, para ver como reacciona ISA.

Aviso de que NMap permite indicar opcionalmente conjunciones de Flags de TCP para realizar otros tipos de scans, esas combinaciones nos las probare, dado que según mis pruebas los resultados no afectan a la conclusión de este articulo.

Null Scan

De la ayuda de NMap: “The null scan (sN) does not set any bits (tcp flag header is0)”

Los resultados del null scan en ISA son:

Figura 8. Alerta: Null Scan.

Figuras 9 y 10 Eventos Null Scan.

NMap no detecta ningún Puerto específicamente abierto, para el todos los puertos están abiertos o filtrados, pero recordar que el Puerto 80 si esta abierto, por lo tanto en realidad el hacker no obtiene ninguna información útil.

Figura 11. Resultado del Null scan .

Figura 12. Trafico detectado por el firewall.

FIN Scan

De la ayuda de NMap:”The FIN scan sets just the TCP FIN bit.”

Los resultados del FIN scan en ISA son:

ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.

Figura 13. Resultados del FIN.

Figure 14. Trafico detectado en los logs del firewall.

Xmas Scan

De la ayuda de NMap: “Xmas Scan sets the FIN, PSH and URG flags, lighting the packet up like a Christmas tree.”

Los resultados del Xmas scan en ISA son:

ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.

Figura 15. Resultados: Xmas Scan.

Figura 16. Trafico detectado en los logs del firewall.

TCP ACK Scan

De la ayuda de NMap: “The ACK scan probe packet has only the ACK flag set (unless you use –scanflags). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don’t respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are labeled filtered.”

Los resultados del ACK scan en ISA son:

ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.

Figura 17. Resultados:ACK Scan.

Figura 18. Trafico detectado en los logs del firewall.

TCP connect scan

En este tipo de scan, NMap usa al sistema operativo sobre el que corre para hacer un connect() de forma completamente normal, por esa razón este tipo de scan se detecta de forma muy simple, cualquier IDS o IPS y por supuesto ISA, lo detectan.

Los resultados del TCP Connect scan en ISA son:

ISA escribe una alerta de intrusión y un evento, NMap encuentra el puerto 80 abierto.

Figure 19. Alerta: Intrusion detection.

Figura 20. Resultados: TCP Connect Scan.

Figura 21. Trafico detectado en los logs del firewall.

TCP Window Scan.

De la ayuda de NMap:”Window scan is exactly the same as ACK scan except that it exploits an implementation detail of certain systems to differentiate open ports from closed ones, rather than always printing unfiltered when a RST is returned. It does this by examining the TCP Window field of the RST packets returned. On some systems, open ports use a positive window size (even for RST packets) while closed ones have a zero window. So instead of always listing a port as unfiltered when it receives a RST back, Window scan lists the port as open or closed if the TCP Window value in that reset is positive or zero, respectively.”

Los resultado del TCP Window scan en ISA son:

ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.

Figura 22. Resultado del escaneo.

TCP Maimon scan

De la ayuda de NMap: ”The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). Nmap, which included this technique, was released two issues later. This technique is exactly the same as Null, FIN, and Xmas scans, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.”

Los resultados del TCP Maimon scan en ISA son:

ISA no registra ninguna alerta o evento, pero NMap no encuentra ningún Puerto específicamente abierto pese a que el Puerto 80 si lo esta.

Figura 23. Alerta de conexiones denegadas.

Figura 24. Resultados del escaneo.

Tabla 1. Port Scanning ISA Server 2006

Reaccionando a un escaneo de puertos.

ISA Server puede reaccionar a un ataque o escaneo ejecutando una accion desde la alerta.

Figura 25. Configurando las definiciones de alertas.

Figura 26. Modificando la definición de la alerta de intrusión.

Figura 27. Configurando las acciones de una alerta.

Es sencillo hacer un script que bloquee todo el tráfico que tenga como origen al atacante.

Firewall Fingerprint.

NMap también nos provee de técnicas para detectar el sistema operativo que corra en el objetivo del escaneo, esto se realiza gracias a una base de datos de huellas de las pilas de TCP IP de los diferentes sistemas operativos.

Cuando un atacante usa esta opción sobre ISA, solo podrá averiguar que ISA corre sobre una maquina Windows.

Un hacker podría presuponer que se esta corriendo ISA y buscar vulnerabilidades conocidas para atacarlo.

Security focus tiene una base de datos de vulnerabilidades ampliamente reconocida, si un atacante trata de buscar vulnerabilidades de ISA 2004 o 2006 solo encontrara una, y además no es de firewalling si no de proxy, además no supone un riesgo a nivel de intrusión.

Trata de buscar vulnerabilidades de Firewall 1 y no te asustes!!! 😀

Figura 28. Security Focus ISA 2004 vulnerabilities.

Que es lo siguiente?

Si un atacante acepta el riesgo de ser detectado, podría conseguir información sobre tus puertos abiertos, el siguiente paso que tratara de realizar es atacar los servicios que estén publicados en el firewall, como por ejemplo servicios SMTP, paginas Web, etc.

Para realizar este trabajo un hacker usara herramientas de escaneo de vulnerabilidades como Nessus, Nikto, etc, pero este no es el objeto de este articulo así que no hablare mas sobre las técnicas de ataque a los servicios publicados.

Como buena practica, hay que tratar siempre de limitar el origen de las conexiones a los puertos publicados, por ejemplo si tienes que publicar un servicio web y no será usado por cualquiera en Internet, trata de que te indiquen desde que ips será usado.

Tus firewalls pueden ser seguros, pero desde luego si publicas un servidor NT 4, con una web IIS 5 sin securizar puedes estar seguro de que tu red será insegura, tienes que securizar todos tus servidores y servicios, especialmente los que estén publicados en Internet.

Mantener todos tus servicios actualizados con los últimos productos de cada familia es una pequeña garantía de seguridad.

Ok, ahora conozco mi superficie externa, ¿puedo descansar?

Desafortunadamente no, el 80% de los ataques provienen de la red interna, normalmente tendrás como mucho una docena de servidores publicados en Internet, pero puedes tener cientos de servidores en tu red interna.

Las redes internas son una pesadilla para los administradores de seguridad.

Las redes internas suelen estar segmentadas en DMZs pero es común encontrar servidores que están en el mismo segmento de red que los usuarios.

Para los servidores que no están en las DMZ puedes usar IPSec y firewalls locales, pero…. ¿Qué pasa con las DMZ si un hacker esta dentro de tu red?

Antes decía que las redes internas son una pesadilla para los administradores de seguridad, las dos claves técnicas para hacer esta afirmación son el envenenamiento ARP con todas sus variantes y los sniffers.

Las razones no técnicas están claras, normalmente se tiene una falsa sensación de seguridad con todo lo que se denomina “interno” además siempre que hago una auditoria oigo la misma frase: “quien nos atacaría desde dentro, eso no pasara, concentrémonos en el exterior”

Recuerdo un cliente hace varios años, tras decirnos esto, nos disfrazamos de técnicos de manteamiento, entramos por la puerta sonriendo y saludando a todo el mundo, nos metimos en una sala de impresoras y colgamos de la red un router wifi con un sniffer metido en el firmware, tras enseñarles lo fácil que había sido, nos dijeron que nadie haría una cosa así. ¿en serio?, recuerdo otro caso en el que nos llevamos una SUN por la puerta del edificio :-D, en fin siguen existiendo muchas empresas que invierten grandes cantidades en I+D pero que no quieren creer que haya nadie capaz de robarle sus ideas.

Volviendo al tema del ISA, en las redes internas, normalmente los administradores de ISA pueden usar dos elementos con el fin de distinguir a los usuarios que pueden usar una regla de los que no:

–La IP de origen; La ip de origen de una maquina se puede cambiar con facilidad y usando técnicas ARP, es posible secuestrar la IP y la MAC de un equipo. En Internet los hackers solo pueden ver los puertos que el firewall tenga abiertos para toda la red externa o para las subredes en las que se encuentre el hacker, pero en las redes internas, un hacker se puede hacer pasar por cualquier equipo y así averiguar que puertos están abiertos, aunque no sean para el.

-El usuario logeado en la maquina; Los administradores pueden poner reglas que se basen en el usuario que esta usando la maquina, desgraciadamente un hacker puede usar técnicas ARP y Sniffers para snifar las passwords en la red. Además las redes internas en muchas ocasiones contienen servicios poco seguros, cientos de servidores corren en muchas ocasiones desactualizados o con viejas versiones, en otros casos, hay servicios que usan contraseñas en texto plano o autenticación básica, o bien se usan antiguos hashes NTLM fácilmente capturables, otros servicios como webs o Terminal services no securizados, proxies ,etc también ponen fácil a un hacker averiguar contraseñas.

Las siguientes pruebas se realizaran desde dentro de la red de ejemplo, además habrá un regla que permita el trafico desde la red interna a un servidor en la DMZ (192.168.10.2) esta regla contendrá una excepción que impida acceder al equipo del hacker al servidor en la DMZ.

Figura 29. Regla en el ISA Server.

Figuras 30 y 31. Detalles de la regla.

En este punto si se escanea la ip del servidor web en la DMZ veremos que todos los puertos están abiertos o filtrados, por lo que el hacker no obtiene ninguna información de valor.

Figura 32. Resultados del escaneo.

Todo lo que separa la hacker de su objetivo es su IP y una password.

¿Que pasaría si usamos NMap para enviar los paquetes simulando tener otra ip?, ¿Qué pasa si esa ip esta en otra red de ISA como por ejemplo la DMZ o Internet?

Figura 33. Usando NMAp para usar una IP falsa de otro segmento de red del ISA, con el comando; “nmap –p 80-90 –e eth0 –S 10.10.10.2 –P0 192.168.10.2”.

Figura 34. ISA detecta los paquetes del spoofing packet y deniega el trafico.

Figura 34b. ISA detecta el ataque de spoofing y escribe un evento.

Bien, ¿pero que pasa si el paquete viene de la red correcta?

Se puede usar NMap para hacer spoofing de MACs e IPs pero hay que ir probando ip por ip dentro de tu subred, para este trabajo es mejor usar otra utilidad llamada IRS que esta hecha por los creadores de Cain & Abel.

Con IRS podemos escanear un objetivo y un Puerto hacienda spoofing de ips dentro de nuestra subnet, adicionalmente también podemos usar una MAC falsa.

Figura 35. Usando IRS (1)

Figura 36 Usando IRS (2), Configurando la tarjeta de red.

Figura 37. Usando IRS(3), Estableciendo el objetivo.

Figura 38. Resultados Usando IRS (4)!!!!!

Ahora el hacker ya sabe que ips tienen acceso y que ips no.

El protocolo ARP y los sniffers nos permiten otros muchos interesantes juegos.

Podemos capturar el tráfico de la red buscando passwords.

En el mundo real, la seguridad es atómica, o todo es seguro o nada es seguro, si tienes sistemas inseguros y no puedes securizarlos, lo mejor es aislarlos del resto de tus sistemas, haz otro dominio para los sistemas inseguros y haz que tus usuarios usen otro usuario y password para acceder a ellos, a nivel de seguridad es muy poco eficiente que un usuario entre en un sistema inseguro con la misma password que usa para entrar en nuestro sistema mas moderno y seguro, tal vez el usuario este muy contento con tener una sola password pero estaremos poniendo en peligro la seguridad de un porcentaje mucho mayor de nuestra red.

Si tus usuarios usan la misma password para validarse en sistemas inseguros que en sistemas seguros, un hacker puede usar un sniffer y ataques de tipo ARP como los de “man in the middle” (MITM) para encontrar las passwords de los usuarios.

Toda esta situación se agrava si además esos servicios inseguros usan el directorio activo para validar las contraseñas.

Programas como Ettercap, hacen las dos cosas, capturan el tráfico de red y usando decodificadores de protocolos buscan las passwords, Ettercap también permite hacer ataques de tipo MITM.

Hay gente que piensa que los switches de red impiden por defecto que se esnife el trafico, pero desgraciadamente muchos sabemos que no es así.

Figura 39. Usando Ettercap (1) Capturando el trafico de red.

Figura 40. Usando Ettercap (2).

Figura 41. Usando Ettercap (3) Passwords detectadas.

Figura 42. Usando Ettercap (4), MITM.

Con estos dos pasos, un hacker en la red interna habría obtenido la información que necesita para atacar nuestros servicios en la red DMZ, pero…. ¿Qué pasa si el hacker es realmente una mala persona y nosotros no hemos tomado precauciones?, en este caso, un hacker podría evitar toda comunicación entre las redes que conecte el ISA o cualquier otro router/firewall, incluida la red Internet.

En nuestra red de ejemplo, el firewall alcanza Internet a través del router con la IP 10.10.10.2.

¿que pasaría si un hacker engaña al firewall comunicándole una falsa MAC del router de Internet?, repuesta: que el firewall no se podría comunicar con Internet, este ataque es del tipo D.O.S (Denial Of Service)

Figura 43. Usando Nemesis desde el ordenador del hacker para inyectar un paquete ARP en el firewall.

Bien; Has visto lo malo y lo peor, déjame enseñarte lo bueno.

La primera cosa que debes saber, es que los ataques ARP y MITM son muy difíciles de hacer sobre Internet.

Los hackers tienen herramientas, pero los administradores también, para evitar un ataque DOS o de tipo MITM, se deben añadir rutas estáticas ARP en los firewalls y otros dispositivos de red.

Para realizar esto, se puede usar el comando ARP:

Figura 44. Creando una entrada ARP estática en el firewall.

Los dispositivos de red, pueden ser el mejor aliado de los administradores para combatir el spoofing.

Se pueden crear vlans que eviten el broadcast ARP y muchos dispositivos de red, disponen de capacidades que pueden ayudarte a hacer más segura la red, hoy en día se compra una electrónica de red estupenda pero de la que apenas se usa el 10% de las funciones.

Lo que de ninguna forma puede pasar, es que los hackers tengan más interés en mejorar sus conocimientos que los administradores de seguridad, si esto pasa, la batalla estará perdida.

Otras herramientas que los administradores tienen, son los IDS (Intrusion Detection System) o IPS (Intrusión Prevention System), estos programas usan sniffers para analizar el trafico de red y encontrar patrones maliciosos de uso, para encontrar estos patrones se usa una base de datos de reglas que se actualiza desde Internet.

Snort es uno de los IDS gratuitos mas famosos, IDSCenter es un interface grafico para Snort sobre windows.

Se puede configurar Snort para detectar ataques ARP contra IPs especificas, como firewalls, routers, proxies, etc.

Snort también detecta los ports scans y otros cientos de eventos de seguridad.

Figura 45. Configurando Snort para detectar ataques ARP.

También puedes configurar Snort para correr scripts que bloqueen el trafico desde la ip del atacante o te envíen un mail informándote del evento.

Figura 46. Configurado la notificación de alertas de Snort.

Figura 47. Evento de Snort: ARP Spoof detected.

Figura 48. Evento de Snort: Port scan detected.

Si instalas el agente de MOM en el servidor que tenga instalado el Snort, podrás capturar los eventos de Snort desde la consola de MOM, disparando alertas sobre eventos.

Flood Mitigation.

Algunas de las nuevas funcionalidades de ISA 2006 son las de mitigación de ataques DOS y gusanos de red.

Figura 49. Flood mitigation (1)

Figura 50. Flood mitigation (2)

Figura 51. Flood mitigation (3)

Para cada tipo de ataque se puede configurar un límite y un límite personalizado que solo se aplicara a una lista de excepciones por IP.

Para este ejemplo incluiremos la IP de un ordenador interno en la lista de excepciones y estableceremos un límite personalizado de 3 para las conexiones TCP/IP concurrentes.

Figura 52. Flood mitigation (4)

Figura 53. Flood mitigation (5)

Figura 54. Flood mitigation (6)

Con estos ajustes el ordenador con la IP 192.168.0.30, tendrá limitadas sus conexiones concurrentes a través de ISA a 3.

Para probarlo lanzaremos varios telnets desde el ordenador con la IP 192.168.0.30 al puerto 80 del firewall, también observaremos el numero de conexiones TCP/IP de ISA en tiempo real usando el performance monitor.

Figura 55. Flood mitigation (7)

Cuando el ordenador trata de abrir la cuarta conexión concurrente ISA deniega el tráfico y lanza una alerta.

Conclusiones

ISA Server es un gran producto, tiene certificaciones de seguridad al mas alto nivel y es “seguro por defecto”, a su vez Windows nos provee de una gran cantidad de características de seguridad que nos ayudan a luchar contra los hackers.

Pero la ultima responsabilidad de mantener tu red segura esta en tu manos, en tu trabajo y por supuesto en tus conocimientos.