Archivo de la categoría: Defensas

Evitar vulnerabilidad de Open DNS Resolver en nuestros servidores DNS

Se denomina como Open DNS Resolver a aquel servidor que resolverá cualquier petición recursiva de información sin importar el origen de la misma.

DNS logo

Fuente imagen: bleepingtech.com

El funcionamiento normal del protocolo DNS indica que si recibe una petición de un dominio que desconozca buscará dicha información (pidiéndosela a sus servidores DNS de referencia) y la entrega al cliente que la ha solicitado. Esto permite que cualquier ordenador pueda conectarse a cualquier sitio del mundo aunque no lo conozca previamente. El problema del Open DNS Resolver es que un tercero, que no tiene nada que ver con nuestra empresa, puede utilizar los recursos de nuestro servidor y nuestro ancho de banda para su propio beneficio. Ya no es sólo el mero hecho de asegurar la eficiencia del servicio al eliminar un uso externo ni previsto ni autorizado, sino que pueden utilizar nuestra infraestructura como parte de un ataque a un tercero e involucrarnos sin ni siquiera tener constancia de él.

Comparativa del tamaño relativo de una petición DNS válida y su respuesta

Comparativa del tamaño relativo de una petición DNS válida y la respuesta originada, que se envía a la víctima del ataque espejo. Fuente imagen: ArsTechnica

Los ataques de denegación de servicio mediante técnicas de espejo se basan en localizar la mayor cantidad de servicios no protegidos, a los que realizar peticiones aparentemente legítimas pero con la dirección IP originaría falseada por la de la víctima que quieren atacar. En nuestro caso un atacante solicitará la resolución de un nombre de dominio extraño, solicitando el máximo de información posible, de tal manera que la respuesta se envíe a la víctima. Este equipo víctima recibiría una gran cantidad de información desde diferentes fuentes de tal forma que sufriría un ataque DDoS. Si la víctima investiga el origen del atacante únicamente encontrará a los servidores DNS utilizados pero no el causante primario del ataque.

Cómo evitar tener un servidor Open DNS Resolver

Diagrama de un ataque de espejo

Diagrama de un ataque de espejo. Fuente imagen: Wikimedia

A continuación indicaremos las principales medidas de protección para que no nuestro sistema DNS no tenga esta debilidad y evitar así que se convierta en parte de un ataque DDoS en espejo:

  1. Deshabilitar la búsqueda recursiva. Tal cómo hemos indicado el propio funcionamiento del protocolo DNS hace que las búsquedas recursivas sean necesarias por lo que deshabilitarla no parece una opción práctica en la mayoría de situaciones. Quizás sí sea interesante si los servidores DNS públicos (aquellos que dan servicios a nuestras páginas web, sitios FTP, etc.) no son utilizados por nuestros trabajadores.
  2. Bloquear las peticiones externas. Al igual que en el caso anterior bloquear las peticiones externas, vía firewall o sistema similar, sólo sería útil si los servidores DNS son de uso interno exclusivo y son diferentes a los que dan servicio público.
  3. Limitar las peticiones de resolución con recursividad. La mayoría de sistemas DNS modernos permiten limitar desde qué redes es aceptable generar peticiones que incluyan resoluciones con recursividad. Así podemos configurar nuestro sistema DNS para que acepte las peticiones de las redes internas (las generadas por nuestros usuarios) mientras que descarte aquellas que provengan de redes externas que no controlemos. En la mayoría de empresas sería suficiente con indicar que sólo se permitan las direcciones IP de rangos privados.

Si bien las dos primeras opciones evitarían el uso de nuestros sistemas (tanto servidores, como anchos de banda, confiabilidad de nuestras direcciones IP, etc.) para formar parte de estos ataques es preferible configurar siempre las redes de confianza para realizar resoluciones con recursividad de tal forma que aunque debido a un fallo de configuración los servidores DNS quedarán expuestos a Internet tampoco pudieran usarse.

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 😉

DHCP snooping

Se utiliza la expresión DHCP Snooping para definir una serie de técnicas que permiten asegurar que únicamente los servidores DHCP autorizados estén funcionando en una red.

Logo DHCP

Logo DHCP
Fuente imagen: IES Haría

El intento de hacer funcionar servidores DHCP no autorizados (DHCP Rogue) se conoce como DHCP Spoofing.

El servicio de DHCP (Dynamic Host Configuration Protocol)  es de uso casi imprescindible para cualquier red de uso común: permite que los equipos se unan a una red de forma automática y sin necesidad de configuración manual. Así ya no hace falta que un administrador de la red configure todos y cada uno de los equipos para poder trabajar. Su uso está tan extendido que muchas veces lo damos por supuesto: cuando llegamos a casa nuestro teléfono móvil se conectar a la red WiFi sin que tengamos que hacer nada (salvo poner la contraseña la primera vez) y nadie se pregunta porqué.

Porqué proteger el servicio DHCP

Como hemos visto el servicio DHCP permite la configuración de cualquier ordenador que se conecte a una red y parte de esa configuración suele ser la puerta por defecto y los servidores DNS que debe utilizar. Los ataques tipo Man-In-the-Middle buscan forzar que el tráfico legítimo pase por sus sistemas y una de las formas de hacerlos es precisamente engañando a los equipos para que usen sus servicios como puerta de enlace o sus DNS. Así si queremos asegurar que los equipos se conecten a nuestra red lo hagan con una configuración segura deberemos proteger el servicio DHCP para que únicamente funcione el sistema oficial y no sea posible crear un sistema falso.

Debilidades del funcionamiento DHCP

Antes de proteger nada, hay que revisar el funcionamiento básico del protocolo DHCP y cuáles son sus puntos débiles.

A grandes rasgos el funcionamiento de DHCP que permite que cualquier equipo se conecte de forma automática a una red sería:

  1. Un equipo se conecta a una red (bien porque se arranca un equipo apagado, bien porque conectamos nuestro móvil a una red Wifi, etc.)
  2. El equipo (cliente) envía un mensaje de difusión (broadcast), que llegará a todos los equipos de esa red, solicitando información sobre la propia red.
  3. El servidor DHCP (o el elemento delegado), y únicamente él, le responderá con un mensaje directo con la información de autoconfiguración que necesita para trabajar.
  4. El cliente configurará sus parámetros con la información recibida del servidor.
Ataque DHCP Spoofing

Ataque DHCP Spoofing
Fuente imagen: RSTUT

La petición del cliente se envía en modo difusión por lo que todos los equipos de la red detectan esa petición. Esto es necesario porqué el nuevo equipo no sabe cómo está montada la red, así que la única opción es enviar la petición de forma que todos los equipos la puedan recibir. el protocolo supone que únicamente responderá a la petición el servidor DHCP y el resto de equipos simplemente la ignorarán, pero ¿qué pasa si un equipo malicioso responde a esa petición? Pues que el nuevo cliente se autoconfigurará con los parámetros que le haya enviado dicho equipo malicioso (el cliente no conoce la red así que no puede saber a priori quién es el servidor DHCP). Esta técnica es conocida como DHCP Spoofing.

Motivos para el DHCP Spoofing

¿Para qué querríamos falsear los datos de configuración de los nuevos equipos que se conecten a la red? Estos son los principales usos de un DHCP spoofing:

  • Hacer creer a un nuevo equipo que nosotros somos su proxy de navegación: Así conseguiremos que el ordenador nos envíe su navegación web a nosotros que podremos analizarla.
  • Hacer creer al nuevo equipo que somos su puerta de enlace: Así todo el tráfico del equipo que salga de la red local pasará por nuestro equipo. Esta opción incluye más tráfico que no sólo el web.
  • Asignarle servidores DNS maliciosos: Podemos redirigir al usuario a nuestros servidores cuando el equipo solicite la resolución de nombre de dominio. Así el usuario creer estar entrando en su banco, cuenta de correo electrónico, etc. cuando en realidad lo está haciendo a una web falsa.
  • Asignación de prefijos telefónicos: Es posible propagar a los teléfonos IP un prefijo de llamada de tal forma que redirijan las llamadas salientes a una numeración especial que tenga un mayor coste.

Si bien las tres primeras opciones son las más habituales pero el protocolo define bastantes opciones de autoconfiguración que pueden ser falseadas con fines maliciosos.

Protección por DHCP Snooping

Como hemos visto el protocolo DHCP se pone en funcionamiento cuando un equipo se conecta a una red de la que desconoce cualquier tipo de información, por lo que no es posible delegar la seguridad del sistema en el cliente ya que simplemente no tiene información alguna de la red. Igualmente hemos visto que el tráfico de petición de información es, y debe ser, visible por toda la red por lo que cualquier equipo conectado a la red puede actuar de forma maliciosa, lo cual impide que deleguemos la seguridad del sistema en el propio servidor. Así pues la seguridad de DHCP queda en manos de los propios equipos de red (swithces y routers, principalmente).

Las diferentes técnicas de protección que componen el DHCP Snooping son las siguientes:

Funcionamiento de los puertos confiables.

Funcionamiento de los puertos confiables.
Fuente imagen: Cisco

  1. Definir, de forma fija y estática, cuáles son los servidores DHCP oficiales de la red. De esta forma cuando un equipo de red detecta tráfico del protocolo DHCP que no se ha originado en uno de los servidores oficiales puede descartarlo.
  2. Definir desde qué interfaces puede generarse tráfico DHCP. Podemos indicarle a los equipos de red, desde cuáles de sus interfaces son confiables y se puede recibir tráfico DHCP. De esta manera si el equipo detecta tráfico de dicho protocolo que se origina desde una posición no confiable puede descartarlo. Así si un equipo de usuario responde a una petición de DHCP el equipo de red más cercanos a él lo detecta y elimina dicho tráfico (y puede bloquear la toma de red, avisar al administrador, etc.).
  3. Delegación de DHCP. Es posible unificar la gestión del DHCP en un servicio externo que no esté dentro de la red local propia (p.e. empresas con diferentes oficinas interconectadas pero con el servicio centralizado en la sede central) de tal forma que los equipos de red descartarían cualquier paquete DHCP local.

Micropíldora 3 – Protege tu Apache contra SQL Injection

Los ataques SQL Injection son los más comunes en el mundo web y uno de los primeros que e suelen probar contra los servicios web de cualquier empresa.  Los ataques más básicos de esta categoría consisten en solicitar información no prevista a la base de datos de tal manera que bien nos la muestre en pantalla o bien que la podamos deducir (Blind SQL Injection). Esta solicitud de información suele realizarse añadiendo instrucciones SQL a la petición normal de tal forma que el servicio responda, además de la petición original y legítima, con la información que solicita el atacante o bien de tal forma que se pueda extrapolar. El funcionamiento de los ataques a ciegas (Blind SQL Injection) se tratará en su propio artículo.

Ejemplo ficticio de ataque SQL donde se solicitaría la versión de la base de datos que funciona tras la página web:

http://www.webvictima.com/?id=1 union select @@version()

Las instrucciones SQL utilizan diferentes palabras claves por lo que intentar localizarlas en las cadena de texto de las peticiones que llegan a nuestro navegador podría servir como medida de protección ante estos ataques. En el siguiente código se busca las palabras claves union y select dentro de la URL solicitada y en caso de encontrarlas se devolverá la página de error 404 (Page Not found) que haya definida en la configuración del servidor Apache. Como una de las técnicas básicas de los atacantes para evitar ser detectado es ofuscar las cadenas de peticiones para evitar su fácil detección se han incluido las conversiones de las cadenas de caracteres en formatos hexadecimal y Unicode que suelen ser utilizados:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*(union|%75%6E%69%6F%6E|&#117;&#110;&#105;&#111;&#110;).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(select|%73%65%6C%65%63%74|&#115;&#101;&#108;&#101;&#99;&#116;).* [NC]
RewriteRule . – [R=404,L,NC]
</IfModule>

Este truco supone que el servidor Apache tiene correctamente activado y configurado el módulo de rewrite y se ha definido correctamente la página de error 404. Como siempre que se tocan ficheros de configuración haced una copia de seguridad antes 😉