Que no, que no quiero a mi DNS!

Pues sí, parece ser que el DNS es un bicho raro que nadie quiere y seguro que algunos se preguntarán qué es eso del DNS. Pues el DNS es un servicio encargado de resolver los nombres de las direcciones de Internet, es decir, que si usted pone en su navegador web www.google.es, él se encarga de decirle a su navegador que donde quiere usted ir es a la IP 1.2.3.4.

Como ven bajo esas tres letritas tan raras se esconde uno de los servicios más críticos para la infraestructura de su empresa. ¿Por qué? Pues porque es el encargado de que si un cliente pone www.suempresa.es vaya a su empresa y no a la de la competencia, porque también es el encargado de que si su servidor requiere una actualización la obtenga del sitio correcto y no de “pedazo-rootkit-te-voy-a-meter” y, como no, de que cuando un usuario se conecte a Facebook el lunes para comprobar qué planes hay para el sábado vaya realmente a Facebook y no a un falsa web que robe las credenciales del usuario (tenga en cuenta que quien dice Facebook puede decir su entidad bancaria).

Una vez mostrado la importancia del DNS para su infraestructura, nos planteamos… ¿Por qué en ocasiones no se toman las medidas necesarias de arquitectura de red y de bastionado del servicio que realmente requiere este servicio? No hablo de restringir únicamente la petición de la versión empleada o las transferencias de zona, hablo de por qué permite que su DNS interno consulte directamente a un DNS externo, por qué el DNS de la red perimetral responde tanto a los servidores de la red perimetral como a las solicitudes de activos externos a su infraestructura, por qué permite que los activos de la red internan puedan solicitar cualquier dominio, por qué su servidor DNS público permite consultas recursiva a solicitudes externas… ¿Por qué? Mourinho, ahora te entiendo :)

Su infraestructura debe disponer de al menos tres DNS, los cuales se recomienda que estén replicados para alta disponibilidad (es decir, seis servidores DNS):

• El primer DNS es el encargado de responder a las peticiones externas que pregunten sobre un dominio de nuestra infraestructura y por tanto es el encargado de resolver las IP públicas de nuestra red. Éste debe estar en una zona dedicada y propia de la infraestructura, y dicho DNS no debe permitir peticiones recursivas y por supuesto peticiones desde nuestra infraestructura.

• El segundo DNS se encontrará en la red perimetral o DMZ. Contiene las IP privadas de los servidores de DMZ y a su vez será el encargado de consultar a los DNS externos de la infraestructura si recibe peticiones, si y solo si, de activos pertenecientes a la red perimetral o del DNS interno.

• El tercer DNS será el interno, que responderá única y exclusivamente a peticiones de los activos de la red interna y en caso de no disponer de la respuesta, siempre deberá preguntar al DNS de la red perimetral de la infraestructura y jamás, repito, JAMÁS, a un DNS externo de Internet.

Con este entorno dispondremos de una arquitectura de red para los DNS segura, dentro de lo seguro que pueda ser un servicio que se comunica mediante UDP (si la petición es inferior a 512 bytes). Pero lógicamente este diseño debe ser acompañado por dos herramientas: un IPS que sea capaz de entender a nivel de aplicación el protocolo DNS y añadir la capacidad de Sinkhole al DNS interno.

En lo referido al IPS es crucial que éste sea capaz de entender a nivel de aplicación el protocolo DNS puesto que éste emplea un formato muy especifico para contener los dominios. Si por ejemplo queremos detectar conexiones hacia el dominio de malware “counter.yadro.ru” no se le puede decir al IPS que intente buscar esa cadena porque no la va a encontrar. Si vemos a bajo nivel una consulta de dicho dominio vemos que lo que se manda es lo siguiente: “0763 6f75 6e74 6572 0579 6164 726f 0272 7500”, es decir, por cada registro se indica primero el número de caracteres del subdominio y posteriormente se envían los valores ASCII del subdominio. Para terminar el dominio se emplea el carácter “00”:

07	63	6f	75	6e	74	65	72	05	79	61	64	72	6f	02	72	75	00
	c	o	u	n	t	e	r		y	a	d	r	o		r	u

Estas construcciones pueden complicarse cuando se emplean punteros, que permiten legítimamente al protocolo DNS ahorrar espacio al poder saltar a cualquier posición del payload, dificultando la obtención del dominio solicitado, así como pudiendo generar bucles infinitos. Los punteros se identifican porque el valor del número de caracteres que le preceden es superior a 63. Recuerden que un dominio y subdominio no pueden superar los 63 caracteres, por tanto, si el valor es superior a 63 (0×40 o superior) esto indica que es un puntero y tras él, se indica la posición del payload donde se desea saltar.

La segunda herramienta básica a la que hacíamos referencia es Sinkhole, de Guy Bruneau, necesaria y prácticamente obligatoria en cualquier infraestructura. Lo que hace esta herramienta es detener la actualización y comunicación del malware con su controlador si emplean para ello Fast Flux (la gran mayoría del malware actual).

Sinkhole es un servidor DNS (BIND) al cual se le ha añadido un listado de dominios conocidos que distribuyen malware; en lugar de apuntar a la IP real del malware, se apunta a un servidor interno vacio y de esta forma cuando los usuarios reciban un correo con un enlace a un dominio que contenga malware, si pincha en el enlace correspondiente, Sinkhole impedirá que se infecten al redireccionarle al servidor vacio, de la misma forma que impedirá que el malware se actualice y que el atacante obtenga el control del equipo. Una política acertada es monitorizar las conexiones al servidor vacio para emplearlo como una herramienta de detección de malware. Es importante tener claro que para que esta estructura funcione todos los equipos de usuarios sólo pueden resolver dominios pasando por el DNS Sinkhole y que el DNS Sinkhole debe redireccionar, una vez pasado el filtro, al DNS interno.

Existen muchas otras configuraciones a tener en cuenta, como por qué aceptamos respuestas de DNS con un TTL inferior a un día o por qué algunos DNS no seleccionan de forma aleatoria su ID y su puerto origen para evitar envenenamiento de la cache de tipo Kaminsky, pero esto ya requeriría más de una entrada :)

Para finalizar les muestro un diagrama básico de una arquitectura más o menos segura de implantación de un DNS, que seguro que a todos nos sonará por tenerla implantada en nuestra empresa al ser un requisito indispensable de la norma ISO 27002… ¿verdad? :) Bromas aparte, ahí va:

 

Pd: entrada publicada en securityartwork

Primeros resultados del preprocesador de geolocalización

Hace un par de semanas definimos cuales eran las principales limitaciones que presentan los IDS/IPS actuales y como era necesario aportar algo más de conocimiento para poder detectar amenazas y riesgos en la infraestructura.

Como ejemplo de requisito adicional se desarrolló un preprocesador dinámico de geolocalización para Snort que permitía poder generar alertas en función del origen o destino de la IP de un paquete de red. El concepto era totalmente distinto a lo que se había desarrollado actualmente con la geolocalización, puesto que nuestro objetivo no era, una vez generada una alerta obtener la procedencia o destinatario con fines únicamente estadístico, sino ser capaces de generar la alerta por la procedencia o el destino de un paquete de red.

Una vez comprobado el correcto comportamiento de esta nueva funcionalidad en distintos entornos de preproducción, se procedió a desplegarla en varios IDS de producción para comprobar su funcionamiento, analizando la información obtenida para comprobar si realmente podría ayudar a detectar amenazas y riesgos en la infraestructura. Las reglas de detección que se han empleado para esta primera fase corresponden a nuevas conexiones hacia países de China y Rusia a los servicios SSH y HTTPS ( puerto destino 22, 2222 y 443).

Los resultados fueron buenos, y aunque lógicamente se pueden mejorar y trabajaremos en ello la primera versión supero las estimaciones previstas. Del conjunto de alertas totales que se generaron en los IDS, el 2.4% fueron del preprocesador de geolocalización. De dichas alertas el 49% correspondían a IP’s ya conocidas de Malware puesto que se trataban principalmente de RBN’s y servidores comprometidos conocidos.

De las 51% de las alertas restantes que no correspondían a IPs de Malware conocido se procedió a realizar un muestreo para comprobar aproximadamente cuales de dichas alertas correspondían a falsos positivos y por tanto, conexiones legítimas a dichos países y en cuales no había ningún motivo para que se hubiera efectuado dicha conexión, identificando posible Malware desconocido.

Los resultados fueron que el 30% de ese 51% correspondía a falsos positivos mientras que el 70% correspondían con IP’s para las cuales no existía ningún motivo aparente de que se realizará dicha conexión, y por tanto, es más que probable que el equipo estuviera infectado con Malware. De hecho es en este punto en donde se está trabajando actualmente.

El resumen de los primeros resultados se muestra en la siguiente gráfica donde conocido corresponde a IP’s que ya eran conocidas como fuente de malware, desconocido implica aquellas IP’s para las cuales no se conoce un motivo aparente para que se hubiera establecido una conexión a un puerto cifrado mientras que falso positivo indica conexiones legítimas a China o Rusia que generaron alerta:

Por tanto, pese a tratarse de conexiones en su gran mayoría al puerto 443 (HTTPS) y cifradas, las cuales nunca hubieran generado alerta en los IDS tradicionales, se generó alertas que identificaron Malware no detectado previamente.

PD: entrada publicada también para securityartwork

Filtros BFP con Tcpdump

Tcpdump, Windump en Windows, es un analizador de red en modo consola bastante básico que permite ver el tráfico de red empleando la biblioteca libpcap/winpcap.

Esta herramienta permite analizar de forma sencilla y resumida el tráfico de red, ya que es capaz de leer las cabeceras de los protocolos de red mostrando la información tratada de forma que sea sencilla de entender. A su vez permite mostrar el payload en crudo (hexadecimal) y en texto (ASCII) y permitiendo crear filtros BFP (berkley filter packet) para mostrar únicamente los paquetes que nos interese. La estructura de opciones que permite tcpdump es la siguiente:

tcpdump [-i interfaz/-r fichero] [opciones] ['filtro']

Interfaz será el nombre de la interfaz de red donde se desee leer el tráfico, por ejemplo eth0. Mientras que fichero será el fichero "pcap" que contiene el tráfico guardado con anterioridad.

Opciones son las opciones que soporta tcpdump, principalmente las siguientes:

-n: no resuelve las ip's.
-nn: no resuelve las ip's de los host y muestre el valor númerico de los puertos y no su nombre, por ejemplo 21 en vez de ftp.
-vv: más información de las cabeceras, como por ejemplo el Identificador de la cabecera IP.
-S: muestra los valores reales del Seq de los paquetes TCP y no el valor relativo sobre el Syn inicial.
-e: muestra la MAC.
-x: muestra el payload en hexadecimal.
-X: muestra el payload en hexadecimal y en ASCII.
-A: muestra el payload en ASCII.
-sX: muestra X bytes del payload incluido las cabeceras de los protocolos a partir de la capa de red. En las versiones antiguas de tcpdump se muestra un máximo de 68 bytes. Para mostrar todo el payload se usa -s0.
-w fichero: permite guardar el tráfico leido en un fichero Pcap.
-c X: leer los X primeros paquetes del fichero leido con -r fichero.

Filtro corresponde a los filtros BFP que permite mostrar solo aquellos datos que cumplan una serie de condiciones. Estos filtros pueden ser de dos tipos: macros o a bajo nivel.

Los macros son palabras reservadas que permite poder realizar filtros a más alto nivel. Por ejemplo si queremos mostrar solo el tráfico del host 192.168.0.1 se puede usar el macro "host 192.168.0.1" o emplear un filtro a bajo nivel y acceder a la cabecera IP donde se encuentra la IP de origen y destino comparandola con su valor hexadecimal.

Los macros más usados son los siguientes:

host IP: host origen o destino IP.
dst host IP: host destino IP.
src host IP: host origen IP.
port X: puerto origen o destino X.
src port X: puerto origen X.
dst port X: puerto destino X.
net Clase: subred "Clase" donde clase es el valor numérico de la red que no varía. Es decir 192.168.0.0/24 sería "net 192.168".
src net Clase: igual que el anterior pero solo origen.
dst net Clase: igual que el anterior pero solo destino.
icmp: paquetes ICMP
tcp: paquetes TCP.
udp: paquetes UDP.

Se pueden relacionar más de un macro mediante las ordenes "or" o "and". Con "Or" con que se cumpla una de las condición se muestra el paquete mientras que "and" indica que deben cumplirse todas las condicones.

Por ejemplo si se quiere decir que quiero ver todo el tráfico hacia el host 10.0.0.1 o el tráfico ICMP sería:

'icmp or dst host 10.0.0.1'

Otro ejemplo sería que el host sea 10.0.0.1 y que el paquete sea ICMP o UDP:

'host 10.0.0.1 and (icmp or udp)'

Pese a que los macros son muy comodos es posible que nos encontremos en ocasiones con que es necesario acceder a algun campo de las cabeceras para las cuales no se dispone de macros, por lo que es necesario usar filtros a nivel bajo. Para ello se emplea la siguiente sintaxis:

'protocolo[posicion] comparador valor'

• Donde protocolo es la cabecera del protocolo buscado: IP, ICMP, UDP y TCP.
• Posición es el byte, empezando a contar en 0, que buscamos dentro de la cabecera.
• Comparador es la operación a comparar con valor. Soporta igual "=", distinto "!=", mayor ">" y menor "<" (entre otros). 
• Valor es el valor en decimal o hexadecimal con que se compara el dato de la cabecera. 

Si por ejemplo queremos ver todos los paquetes cuyo TOS (type of service), situado en el segundo byte de la cabecera IP, seá distinto de 0 se emplearía el siguiente filtro:  

'ip[1] != 0'

Para acceder a más de un byte seguido se puede realizar mediante "posicion_ini:cantidad_bytes", por ejemplo para buscar aquellos paquetes cuyo tamaño sea menor de 40 bytes podemos consultar el byte 2 y 3 de la cabecera IP: 

'ip[2:2] > 40'

Otro ejemplo sería un filtro que muestre el checksum de la cabecera IP (bytes 10 y 11) cuyo valor sea igual a 0:

'ip[10:2] = 0'

Como vemos de esta forma podemos acceder a los bytes de las cabeceras de distintos protocolos. ¿Pero que ocurre si quiero acceder a un solo bit o un nibble(medio byte)? Es necesario usar mascaras.

El objetivo de las mascaras es realizar la operación binaria and sobre el byte obteniendo únicamente aquellos valores que nos interese, donde los bits de la mascara valdrán 0 en aquellos bits que no nos interesa y 1 en los que nos interesa. Sobre el resultado de la operación binaria se realiza la comparación que se buscaba inicialmente, veamoslo con un ejemplo:

Queremos leer solo los paquetes con el flag Syn activado (inicio de conexión), el cual es el segundo bit del byte 13 TCP (EEUAPRSF). Por tanto nos interesa obtener el 2 bit únicamente y luego indicar que ese bit tiene que ser distinto de 0. La mascara para poner a 0 todos los bits de un byte menos el segundo es 0x02 (0000 0010), por tanto el filtro será el siguiente:

tcpdump -i eth0 'tcp[13] & 0x02 !=0'

Una alterantiva al filtro anterior sería cualquiera de los siguientes:

tcpdump -i eth0 'tcp[13] & 0x02 = 0x02'

tcpdump -i eth0 'tcp[13] & 0x02 = 2'

En los casos expuestos con anterioridad buscamos aqueños paquetes que tenga el bit Syn activado pero los paquetes pueden tener otros bits activados a parte del Syn, como por ejemplo Syn + Ack. Si queremos solo mostrar los paquetes con únicamente el bit Syn se realizaría de la siguiente forma:

tcpdump -i eth0 'tcp[13] = 2'

tcpdump -i eth0 'tcp[13] = 0x02'

PD: existen macros para el acceso a los flags TCP con tcpflags.

Es importante tener en cuenta que no es lo mismo explorar el nibble alto que bajo. Por ejemplo si se quiere visualizar únicamente los paquetes que contenga el flag ACK, el cual es el primer bit del nibble alto del byte 13 de la cabecera TCP(EEUAPRSF), se realizaría de la siguiente forma:

tcpdump -i eth0 'tcp[13] & 0x10 = 0x10'

tcpdump -i eth0 'tcp[13] & 0x10 = 16'

Puede parecer que sea lo mismo, ¿verdad? Veamos un ejemplo más claro. El nibble alto del byte 12 del protocolo TCP contiene el tamaño de la cabecera TCP en tamañp palabra (4 bytes), es por ello que de normal el nibble vale 5 y por tanto 5 * 4 igual a 20 bytes. Imaginemos que queremos obtener aquellos paquetes cuyo tamaño de cabecera TCP sea superior a 20 bytes:

tcpdump -i eth0 '((tcp[12] & 0xf0)*4) > 20'

Aparentemente sería lo correcto ¿verdad?... no, hay que tener en cuenta que al tratarse del nibble alto donde Tcpdump leé los datos en byte y no en nibble, cuando le indicamos que leá el valor del byte 12 no está leyendo "5" representado como "0101", sino "0101 0000". Por tanto es necesario dividir entre 16 para obtener el "5" y no el "96" que obtuvimos con anterioridad:

tcpdump -i eth0 '(((tcp[12] & 0xf0)/16) *4) > 20'

O lo que es lo mismo:

tcpdump -i eth0 '((tcp[12] & 0xf0)/4) > 20'

Como vemos, con un conocimiento básico de las cabeceras IP, TCP, UDP y ICMP se pueden realizar filtros realmente complejos que nos pueden ayudar durante un incidentes. Espero que os sea de utilidad.

Network Tap en NIDS

Uno de los problemas que surgen a la hora de implantar las sondas para la detección de intrusos a nivel de red (NIDS) es el lugar de conexión de ésta. Normalmente se suele conectar en las interfaces span o puerto espejo del Switch (conmutador) de la red donde queremos detectar las alertas, incluso para aquellas soluciones donde se dispone de un presupuesto reducido se emplean Hub (concentrador).

Pero dichas soluciones presentan un problema de perdidas de paquetes. En caso de un Hub es debido a las colisiones que se genera en el tráfico, donde en una red 10/100 la interfaz del NIDS puede llegar a tratar un máximo de 40 mbits/segundo. En caso de los Switch el problema surge con el coste computacional adicional de tener que procesar y replicar los paquetes de una o varias interfaces sobre la interfaz espejo, así como, no ser capaces de inyectar en una única interfaz el tráfico total que circula por las interfaces replicadas.

Es por ello que en el puerto espejo de un Switch 10/100 un NIDS es capaz de analizar un máximo de 60 a 80 mbits/segundo, mientras que en una red a giga el máximo estará entre 400 y 600 mbits/segundo.

Para solucionar estos problemas en entornos de carga elevada y críticos con full duplex se emplean Copper Test Access Ports o Taps, permitiendo obtener el tráfico que circula por un cable y replicarlo a a la interfaz del NIDS sin que el tráfico se vea afectado. 

¿Como hacer esto? imaginemos que se desea leer el tráfico que va entre dos dispositivos de red al que llamaremos A y B. Esos dispositivos de red se conectan por un cable (Cobre/RJ45 o Fibra). En la interfaz A tendremos la señal de recepción RX la cual se conecta al de transmisión TX de B, y así mismo, la interfaz de B tendrá el RX conectado a la TX de A. El TAP  se sitúa en medio de los dos cables, teniendo dos bocas donde en una se conecta A y en la otra a B como si se tratara de una prolongación del cable. A su vez coge la señal TX de A y de B y las lleva a dos bocas adicionales.  Veámoslo en un diagrama sencillo:

Es importante comprender que no se puede conectar el TX de A y el TX de B en la misma interfaz del NIDS, puesto que la interfaz encargada de leer el tráfico (la sonda del NIDS) solo puede leer por su RX y no leer tráfico por su TX, ya que es de transmisión y no de recepción (gracias Jose Luis :P). 

Existen diagramas sencillos para crearnos nuestro propio Tap 10/100 (pieza indispensable de un análisis forenses), a un precio más que asequible empleando únicamente cuatro anclajes para RJ45 y un cable RJ45. Claro este en entornos críticos a giga los tap no son tan sencillos y son realmente caros, del entorno de 2000 a 5000 euros.

Como se habrán dado cuenta el tráfico capturado por el Tap se encuentra dividio en las dos interfaces (TXA y TXB) donde una dirección del tráfico está en una interfaz y el de otra dirección en la otra. Por tanto es necesario juntar el tráfico de esas dos interfaces para poder leerlo como si lo estuviéramos haciendo directamente sobre el cable. Para ello se emplean Switch que permiten "unir" el tráfico de ambas interfaces en una única interfaz. Se puede pensar que es lo mismo que poner un Switch directamente sin el Tap como se comento al principio, pero no, por que en este caso el Switch solo tiene que replicar el tráfico en una única interfaz, así mismo, dicho proceso no influye en el funcionamiento del Switch de producción.

El problema de está solución es que en la tarjeta span puede recibir la mitad del tráfico máximo que puede circular en ambas interfaces, por ejemplo si el TX de A es a Giga y el TX de B es a Giga, si tengo que inyectar ese tráfico en una tarjeta a Giga en el peor de los casos podría llegar a perder la mitad del tráfico: TXA + TXB en TXSpan.

Para ello existe dos soluciones. La primera y más económica, pero nos obliga a emplear NIDS por software, es por software empleando para ello un servidor con dos interfaces que soporten el mismo tráfico, o más, que las interfaces TXA y TXB del Tap. El servidor deberá usar el sistema operativo linux y emplear bonding, mediante el comando ifenslave que permite agregar el tráfico de ambas interfaces en una. Si por ejemplo tenemos un tráfico a giga necesitaríamos un Tap que sea a Giga, un servidor con al menos 2 interfaces a giga y una tercera de gestión, donde conectaremos cada interfaz del Tap (TXA y TXB) a cada una de las interfaces giga del servidor y una vez conectado activaremos el Bonding. Si por ejemplo las interfaces a giga son Eth0 y Eth1 los comandos a ejecutar serán los siguientes:

# ifconfig bond0 promisc up
# ifconfig eth0 promisc up
# ifconfig eth1 promisc up
# ifenslave bond0 eth0
# ifenslave bond0 eth1

De esta forma podemos invertir en un servidor potente con fuente redundante que se encargue de la agregación por bonding y a su vez, del análisis de tráfico al instalar  alguna herramienta de detección de intrusos a nivel de red por software como puede ser Suricata o Snort, que hará la función de la sonda de detección de intrusos al leer el tráfico de la interfaz bond0.

Tal como hemos comentado, existe una segunda alternativa al bonding, mucho más cara y algo mejor, que es emplear el balanceador de tráfico de Top Layer, la cual se puede emplear con sondas por hardware como por software. Este dispositivo funciona conectando las dos interfaces del Tap al dispositivo y éste se encarga de balancear el tráfico de red a diferentes interfaces  manteniendo la sesión de la comunicación y siendo capaz de transmitir a las interfaces de red casi/la totalidad del tráfico que circule por la red (¡sin perdidas!). A su vez es capaz de asignar interfaces dedicadas a cierto tráfico como es el HTTP o SMTP permitiendo asegurar que no se producen perdidas en protocolos críticos. El funcionamiento sería el siguiente:
 

 

Por tanto, la solución para entornos de carga elevada sería emplear un Tap a giga o fibra, a poder ser de doble fuente redundante, y hacer la agregación por bonding empleando un NIDS por software como Snort o Suricata. Lógicamente usar el balanceador sería lo ideal, pero el precio se dispara, ya que, debemos tener en cuenta que el precio del Tap a Giga, del servidor para bonding + sonda tiene un precio aproximado ente 4000 y 7000 euros. 

Nos vemos en la próxima entrada.