Hoy vamos a ver como realizar un chequeo exaustivo de red (network forensics) de nuestros DNSs utilizado los logs analÃticos (DNS Analytical Logging). Generalmente las consultas y respuestas DNS son una fuente de datos clave utilizada por los sistemas de seguridad de la red en apoyo a respuestas de incidentes, asà como para descubrir una intrusión. Si se recopilan estas transacciones para el procesamiento y análisis de un sistema de datos grande, que pueden permitir a un análisis de numerosos y valiosos escenarios de seguridad. Un ejercicio para este fin se llevó a cabo con los sistemas DNS internos de Microsoft, por ejemplo.
Motivación
El procesamiento en escala y análisis de los datos de DNS en un sistema de Big Data es un alternativa potente que se puede utilizar para realizar las investigaciones de análisis y descubrimiento de intrusiones. A continuación veremos una selección de escenarios que están habilitados –
Detección IOC
Nombres de dominio y direcciones IP son una de las fuentes más comunes de Indicadores de Compromiso (IOC), a menudo refiriéndose a los servidores Comando y Control de la infraestructura del atacante. La recolección, procesamiento y almacenamiento de datos DNS permite a los dominios consultados, y los datos de respuesta de registro de los host dentro de la red que se han buscado estas IOCs, proporcionando una detección rápida y precisa de si la red ha sido impactada por una intrusión. La colección en curso de estos datos también permite una poderosa búsqueda retrospectiva de las IOCs en redes informáticas.
Protocolo de detección Agnóstico
Defensores de red a menudo tienen acceso a otras fuentes de datos que se pueden buscar por IP y dominio de las IOCs, como el proxy Web y los registros del servidor de seguridad. La colección DNS proporciona una detección de mayor fidelidad de éstos, donde el protocolo implementado por el Comando atacante y la infraestructura de control no implica HTTP, o donde DNS en sà está siendo utilizado como un canal secreto.
Detección Canal Covert
DNS puede ser utilizado por adversarios como un canal secreto para proporcionar capacidad de configuración o la transferencia de datos a distancia para el malware dentro de una red informática. En el análisis de escala de los paquetes de respuesta anormales se pueden utilizar para identificar este tipo de canales encubiertos.
Adversary Tracking
El registro histórico de la consulta y los datos de respuesta y el análisis asociado permite el seguimiento del uso de la infraestructura de comando y control utilizado por adversarios a través del tiempo, en donde se utilizan varios dominios y direcciones IP y la infraestructura está la transición tras el descubrimiento de la actividad.
Registro AnalÃtica en DNS de Windows
DNS de Windows Server (2012R2 en adelante) ha puesto en marcha una mayor tala de varias acciones del servidor DNS en Windows, incluyendo el registro de datos de consulta y respuesta con un enfoque de impacto en el rendimiento insignificante.
Impacto de rendimiento insignificante de Habilitación
Un servidor DNS que se ejecuta en el hardware moderno que recibe 100.000 consultas por segundo (QPS) puede experimentar una degradación del rendimiento del 5% cuando los registros analÃticos están habilitadas. No hay impacto en el rendimiento aparente para las tasas de consulta de 50.000 QPS e inferior
Si queres mas información sobre este tema podes consultar el siguiente artÃculo de TechNet para obtener información detallada sobre esta función, incluyendo cómo habilitarlo en su infraestructura: https://technet.microsoft.com/en-us/library/dn800669.aspx
Detalles de Registro de Datos
El tipo de registro analÃtico aplicado a través de esta función contiene gran parte del dÃa a dÃa los detalles operativos del servidor DNS, y aunque se registran muchos tipos de datos, incluidas las solicitudes de transferencia de zona, las respuestas y las actualizaciones dinámicas, de los forenses y de análisis de amenazas nos centraremos en tipos de datos QUERY_RECEIVED y RESPONSE_SUCCESS en este ejemplo. Estos forman el núcleo de la colección interna actual y representan el mayor reto en la colección debido a los volúmenes de datos.
QUEY_RECEIVED and RESPONSE_SUCCESS events that are logged contain a number of the fields that make up a query and response, but crucially also contain the full packet data received enabling the processing of any aspect of one of these objects. Eventos
QUEY_RECEIVED y RESPONSE_SUCCESS que se registran contienen un número de los campos que componen una consulta y la respuesta, pero fundamentalmente también contienen los datos de paquete completo recibido permitiendo el procesamiento de cualquier aspecto de una de estos objetos. Aquà podemos ver un caso ejemplo respuesta de las aplicaciones y servicios Logs \ Microsoft \ Windows \ log analÃtica DNS-Servidor – –
Implementación
El registro de estos datos se implementó como un ETW (seguimiento de eventos para Windows) proveedor. Muchos tipos de eventos de Windows están habilitados a través de este mecanismo, y permiten un alto registro de rendimiento de los datos, y la suscripción a estos proveedores a través de sus GUID únicos. En el caso de que el proveedor Microsoft-Windows-ServidorDNS, GUID {EB79061A-A566-4698-9119-3ED2807060E7} se utiliza como su identidad.
Windows viene con muchas herramientas para grabar muestras de estos datos, como tracelog, que registrará los eventos que ofrece el canal de ETW y escribirlos en un archivo. El visor de sucesos de Windows se replica en esencia este modelo de suscripción al presentar al administrador con una vista de estos acontecimientos, la escritura de la muestra recogida a una ubicación de archivo temporal. Como ejemplo, aquà es la ubicación de los datos subyacentes a la función de registro de DNS mejorado –
%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-DNSServer%4Analytical.etl %
El visor de eventos actúa como un navegador para este archivo.
Recolección de Datos
Uno de los métodos de recopilación de eventos de los servidores de Windows es Windows Event Collection (WEC). WEC es un mecanismo integrado en Windows que enviará una representación XML de un evento a un servidor de recopilación configurado, basado en un filtro especificando un criterio identificador de evento y de selección.
WEC, sin embargo, sólo se puede configurar para los tipos de registro de ‘Operacional’. Estos eventos operacionales se almacenan en una ubicación permanente enrollado dentro de un archivo .evtx en el host. Cuando se crean estos eventos también se escriben a través del servicio de sucesos de Windows Collector, que realiza el reenvÃo de acogida.
Si deseas mas información sobre la colección de eventos de Windows, consulte el artÃculo siguiente en MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/bb427443(v=vs.85).aspx
Hay una sobrecarga inherente a registrar un evento de esta manera, y es el registro de consultas DNS razón y la respuesta se implementa como un "analÃtico". Tipos de registros analÃticos no escribir eventos a través del servicio de WEC y como tales tienen un impacto en el rendimiento más bajo. Esto ayuda a darnos la victoria rendimiento insignificante mencionamos anteriormente en un alto QPS en el orden de 100 mil consultas por segundo.
Para los servidores que no cuentan con este tipo de necesidades altas QPS, utilizando WEC desde un canal operativo se convierte en una opción más viable. Los servidores DNS internos que sirven una red empresarial dedicada pueden tener requisitos significativamente menores QPS (alrededor de 10.000 QPS). En estos niveles, la colección sobre WEC se convierte en un escenario más realista. Además, desde un punto de vista de análisis de seguridad de la mayorÃa de las preguntas y respuestas para los dominios de renombre tales como * .microsoft.com, son menos valiosos para nosotros y puede ser disminuido, lo que reduce aún más la efectiva QPS registra para WEC.
Para el proyecto interno de Microsoft, un colector de eventos de alto rendimiento se implementó que consume los eventos QUERY_RECEIVED y RESPONSE_SUCCESS del canal ETW en los servidores DNS.Este consumidor filtra los dominios de gran reputación que son menos valiosos para nosotros para el análisis de seguridad y escribe éstos en un registro equivalente operativo listo para la recolección a través de canales WEC normales. Este esquema le ofrece una visión general de alto nivel de la funcionalidad de esta herramienta –
Query Volume Modelling
Selección de nombres de dominio para el filtrado puede ser un acto de equilibrio que requiere el modelado utilizando datos de la muestra. La carga de demasiados filtros de dominio de la herramienta puede causar el procesamiento de un-necesario, mientras que dejar que los dominios de alto volumen a través de la escritora evento puede resultar en volumen un-necesario y los costos de almacenamiento asociados.
Los clientes pueden recoger una muestra de datos de consulta y respuesta de la tala analÃtica en un archivo .etl de un servidor DNS en su red. Este archivo ETL puede ser analizado para el volumen consultado dominios superiores en términos de dominio de segundo nivel (SLD).
Tomando los mejores SLD, con exclusión del condado TLD como clientes .co.uk puede modelar la reducción del volumen de consultas por la aplicación de varios filtros SLD, y extrapolar estos para la cobertura de red de la empresa. Estas cifras se pueden utilizar para calcular los costes de almacenamiento aproximados de la implementación de una solución de este tipo. Por otra parte, datos como los Alexa Top 100 SLD se pueden tomar como punto de partida y refinadas como sea necesario para ajustarse a las necesidades de la empresa.
En nuestro prototipo, un valor de 100 SLD fue elegido para la aplicación sobre la base de datos de la muestra registrados en la red. Esto dio lugar a una reducción del volumen de 3.286 QPS de nuestro conjunto de datos de la muestra, a 136 QPS, 4,13% del volumen total. La tasa efectiva QPS extrapolarse para el conjunto de la red se reduce significativamente en este escenario, fácilmente manejable por grandes datos y la infraestructura de WEC.
Resultados de la prueba Piloto
Se ha trabajado para realizar un piloto con el registro analÃtico, y la herramienta de consumo / filtrado ETW a la infraestructura DNS corporativa de Microsoft. El proyecto piloto se puso en marcha a los 29 servidores de almacenamiento en caché de DNS. Una pequeña instantánea del volumen de consultas que este proyecto estaba tratando con es:
El tamaño total de la filtración posterior almacenamiento de datos en bruto de los 29 servidores DNS de Microsoft corporativa picos a aprox. 100GB / dÃa en las horas de más afluencia, y desciende a alrededor de 15 GB / dÃa durante los perÃodos de menor afluencia, como los fines de semana. Esto permite una nueva forma de utilizar la información relacionada con los dominios comprometidos, la identificación de las transacciones maliciosos, máquinas infectadas y por lo tanto que nos permite controlar y fortalecer nuestra red.
Espero que les sea de interés. Saludos. Roberto Di Lello.
Pueden leer mas sobre este tema en: Blogs TechNet
I always hear that Fire fox is better than Internet Explorer and its faster safer ect….But what are the bad things about firefox?.
Hello Johnsie, to be real it depends of what you want. I usually use IE any version and never have mayor issues. Or the issues that i have was the same that i got on chrome or firefox.
IE is faster with every new version, now im testing the Edge version and it’s excellent. All the browser requieres the same memory and works in very similar way. so, you can choose any of them. One of the good things that has the IE is that you can mange them with GPO & WSUS in your company environment.
Regards. Robert DL