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 :-D
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!!! :-D
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.
Fuente:
http://geeks.ms/blogs/dmatey/archive/2007/01/16/un-firewall-es-un-accesorio-de-cocina-probando-isa-server-2006.aspx
He
recibido varias consultas sobre licenciamiento de Terminal Services
dado los laboratorios que hemos ido haciendo sobre el tema. Hoy vamos a
ver como Implementar y Activar nuestro Terminal Services License Server, para luego implementar nuestro Client Access Licenses (CAL).
