{"id":2997,"date":"2015-12-16T08:00:00","date_gmt":"2015-12-16T11:00:00","guid":{"rendered":"http:\/\/www.radians.com.ar\/blog\/?p=2997"},"modified":"2018-01-16T16:49:34","modified_gmt":"2018-01-16T19:49:34","slug":"network-forensics-con-windows-dns-analytical-logging","status":"publish","type":"post","link":"https:\/\/www.radians.com.ar\/blog\/?p=2997","title":{"rendered":"Network Forensics con Windows DNS Analytical Logging"},"content":{"rendered":"<p align=\"justify\">Hoy vamos a ver como realizar un chequeo exaustivo de red (network forensics) de nuestros DNSs utilizado los logs anal\u00edticos (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\u00ed como para descubrir una intrusi\u00f3n. Si se recopilan estas transacciones para el procesamiento y an\u00e1lisis de un sistema de datos grande, que pueden permitir a un an\u00e1lisis de numerosos y valiosos escenarios de seguridad. Un ejercicio para este fin se llev\u00f3 a cabo con los sistemas DNS internos de Microsoft, por ejemplo.<\/p>\n<h4>Motivaci\u00f3n<\/h4>\n<p align=\"justify\">El procesamiento en escala y an\u00e1lisis 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\u00e1lisis y descubrimiento de intrusiones. A continuaci\u00f3n veremos una selecci\u00f3n de escenarios que est\u00e1n habilitados &#8211;<\/p>\n<h4><b>Detecci\u00f3n IOC<\/b><\/h4>\n<p align=\"justify\">Nombres de dominio y direcciones IP son una de las fuentes m\u00e1s comunes de Indicadores de Compromiso (IOC), a menudo refiri\u00e9ndose a los servidores Comando y Control de la infraestructura del atacante. La recolecci\u00f3n, 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\u00f3n r\u00e1pida y precisa de si la red ha sido impactada por una intrusi\u00f3n. La colecci\u00f3n en curso de estos datos tambi\u00e9n permite una poderosa b\u00fasqueda retrospectiva de las IOCs en redes inform\u00e1ticas.<\/p>\n<h4><b>Protocolo de detecci\u00f3n Agn\u00f3stico<\/b><\/h4>\n<p align=\"justify\">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\u00f3n DNS proporciona una detecci\u00f3n de mayor fidelidad de \u00e9stos, donde el protocolo implementado por el Comando atacante y la infraestructura de control no implica HTTP, o donde DNS en s\u00ed est\u00e1 siendo utilizado como un canal secreto.<\/p>\n<h4><b>Detecci\u00f3n Canal Covert<\/b><\/h4>\n<p align=\"justify\">DNS puede ser utilizado por adversarios como un canal secreto para proporcionar capacidad de configuraci\u00f3n o la transferencia de datos a distancia para el malware dentro de una red inform\u00e1tica. En el an\u00e1lisis de escala de los paquetes de respuesta anormales se pueden utilizar para identificar este tipo de canales encubiertos. <b><\/b><\/p>\n<h4><b>Adversary Tracking<\/b> <\/h4>\n<p align=\"justify\">El registro hist\u00f3rico de la consulta y los datos de respuesta y el an\u00e1lisis asociado permite el seguimiento del uso de la infraestructura de comando y control utilizado por adversarios a trav\u00e9s del tiempo, en donde se utilizan varios dominios y direcciones IP y la infraestructura est\u00e1 la transici\u00f3n tras el descubrimiento de la actividad.<\/p>\n<h4><b>Registro Anal\u00edtica en DNS de Windows<\/b><\/h4>\n<p align=\"justify\">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.<\/p>\n<h4><b>Impacto de rendimiento insignificante de Habilitaci\u00f3n<\/b><\/h4>\n<p><i>Un servidor DNS que se ejecuta en el hardware moderno que recibe 100.000 consultas por segundo (QPS) puede experimentar una degradaci\u00f3n del rendimiento del 5% cuando los registros anal\u00edticos est\u00e1n habilitadas.<\/i> <i>No hay impacto en el rendimiento aparente para las tasas de consulta de 50.000 QPS e inferior<\/i><\/p>\n<p>Si queres mas informaci\u00f3n sobre este tema podes consultar el siguiente art\u00edculo de TechNet para obtener informaci\u00f3n detallada sobre esta funci\u00f3n, incluyendo c\u00f3mo habilitarlo en su infraestructura: <a href=\"https:\/\/technet.microsoft.com\/en-us\/library\/dn800669.aspx\">https:\/\/technet.microsoft.com\/en-us\/library\/dn800669.aspx<\/a> <\/p>\n<h4><b>Detalles de Registro de Datos<\/b><\/h4>\n<p>El tipo de registro <b>anal\u00edtico<\/b> aplicado a trav\u00e9s de esta funci\u00f3n contiene gran parte del d\u00eda a d\u00eda 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\u00e1micas, de los forenses y de an\u00e1lisis de amenazas nos centraremos en tipos de datos QUERY_RECEIVED y RESPONSE_SUCCESS en este ejemplo. Estos forman el n\u00facleo de la colecci\u00f3n interna actual y representan el mayor reto en la colecci\u00f3n debido a los vol\u00famenes de datos.<\/p>\n<p>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 <\/p>\n<p>QUEY_RECEIVED y RESPONSE_SUCCESS que se registran contienen un n\u00famero de los campos que componen una consulta y la respuesta, pero fundamentalmente tambi\u00e9n contienen los datos de paquete completo recibido permitiendo el procesamiento de cualquier aspecto de una de estos objetos. Aqu\u00ed podemos ver un caso ejemplo respuesta de las <b>aplicaciones y servicios Logs \\ Microsoft \\ Windows \\<\/b> log anal\u00edtica <b>DNS-Servidor<\/b> <b><\/b>\u2013 &#8211;<\/p>\n<p><a href=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a01.jpg\"><img loading=\"lazy\" decoding=\"async\" title=\"www.radians.com.ar\" style=\"border-top: 0px; border-right: 0px; border-bottom: 0px; float: none; margin-left: auto; border-left: 0px; display: block; margin-right: auto\" border=\"0\" alt=\"www.radians.com.ar\" src=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a01_thumb.jpg\" width=\"540\" height=\"214\" \/><\/a>&#160;<\/p>\n<h4><b>Implementaci\u00f3n<\/b><\/h4>\n<p align=\"justify\">El registro de estos datos se implement\u00f3 como un ETW (seguimiento de eventos para Windows) proveedor. Muchos tipos de eventos de Windows est\u00e1n habilitados a trav\u00e9s de este mecanismo, y permiten un alto registro de rendimiento de los datos, y la suscripci\u00f3n a estos proveedores a trav\u00e9s de sus GUID \u00fanicos. En el caso de que el proveedor Microsoft-Windows-ServidorDNS, GUID <strong>{EB79061A-A566-4698-9119-3ED2807060E7}<\/strong> se utiliza como su identidad. <\/p>\n<p align=\"justify\">Windows viene con muchas herramientas para grabar muestras de estos datos, como <em>tracelog,<\/em> que registrar\u00e1 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\u00f3n al presentar al administrador con una vista de estos acontecimientos, la escritura de la muestra recogida a una ubicaci\u00f3n de archivo temporal. Como ejemplo, aqu\u00ed es la ubicaci\u00f3n de los datos subyacentes a la funci\u00f3n de registro de DNS mejorado &#8211;<\/p>\n<p><font face=\"OCR A Std\"><font color=\"#ff8000\"><b>%SystemRoot%\\System32\\Winevt\\Logs\\Microsoft-Windows-DNSServer%4Analytical.etl<\/b> <b>% <\/b><\/font><\/font><\/p>\n<p><a href=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a02.png\"><img loading=\"lazy\" decoding=\"async\" title=\"www.radians.com.ar\" style=\"border-top: 0px; border-right: 0px; border-bottom: 0px; float: none; margin-left: auto; border-left: 0px; display: block; margin-right: auto\" border=\"0\" alt=\"www.radians.com.ar\" src=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a02_thumb.png\" width=\"540\" height=\"405\" \/><\/a> El visor de eventos act\u00faa como un navegador para este archivo.<\/p>\n<h4><strong>Recolecci\u00f3n de Datos<\/strong><\/h4>\n<p align=\"justify\">Uno de los m\u00e9todos de recopilaci\u00f3n de eventos de los servidores de Windows es Windows Event Collection (WEC). WEC es un mecanismo integrado en Windows que enviar\u00e1 una representaci\u00f3n XML de un evento a un servidor de recopilaci\u00f3n configurado, basado en un filtro especificando un criterio identificador de evento y de selecci\u00f3n. <\/p>\n<p align=\"justify\">WEC, sin embargo, s\u00f3lo se puede configurar para los tipos de registro de <b>&#8216;Operacional&#8217;. <\/b>Estos eventos operacionales se almacenan en una ubicaci\u00f3n permanente enrollado dentro de un archivo .evtx en el host. Cuando se crean estos eventos tambi\u00e9n se escriben a trav\u00e9s del servicio de sucesos de Windows Collector, que realiza el reenv\u00edo de acogida. <\/p>\n<p align=\"justify\">Si deseas mas informaci\u00f3n sobre la colecci\u00f3n de eventos de Windows, consulte el art\u00edculo siguiente en MSDN: <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/windows\/desktop\/bb427443(v=vs.85).aspx\">https:\/\/msdn.microsoft.com\/en-us\/library\/windows\/desktop\/bb427443(v=vs.85).aspx<\/a> <\/p>\n<p align=\"justify\">Hay una sobrecarga inherente a registrar un evento de esta manera, y es el registro de consultas DNS raz\u00f3n y la respuesta se implementa como un &quot;anal\u00edtico&quot;. Tipos de registros anal\u00edticos no escribir eventos a trav\u00e9s del servicio de WEC y como tales tienen un impacto en el rendimiento m\u00e1s bajo. Esto ayuda a darnos la victoria rendimiento insignificante mencionamos anteriormente en un alto QPS en el orden de 100 mil consultas por segundo.<\/p>\n<p align=\"justify\">Para los servidores que no cuentan con este tipo de necesidades altas QPS, utilizando WEC desde un canal operativo se convierte en una opci\u00f3n m\u00e1s 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\u00f3n sobre WEC se convierte en un escenario m\u00e1s realista. Adem\u00e1s, desde un punto de vista de an\u00e1lisis de seguridad de la mayor\u00eda 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\u00fan m\u00e1s la efectiva QPS registra para WEC.<\/p>\n<p align=\"justify\">Para el proyecto interno de Microsoft, un colector de eventos de alto rendimiento se implement\u00f3 que consume los eventos QUERY_RECEIVED y RESPONSE_SUCCESS del canal ETW en los servidores DNS.Este consumidor filtra los dominios de gran reputaci\u00f3n que son menos valiosos para nosotros para el an\u00e1lisis de seguridad y escribe \u00e9stos en un registro equivalente operativo listo para la recolecci\u00f3n a trav\u00e9s de canales WEC normales. Este esquema le ofrece una visi\u00f3n general de alto nivel de la funcionalidad de esta herramienta &#8211;<\/p>\n<p><a href=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a03.jpg\"><img loading=\"lazy\" decoding=\"async\" title=\"www.radians.com.ar\" style=\"border-top: 0px; border-right: 0px; border-bottom: 0px; float: none; margin-left: auto; border-left: 0px; display: block; margin-right: auto\" border=\"0\" alt=\"www.radians.com.ar\" src=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a03_thumb.jpg\" width=\"540\" height=\"261\" \/><\/a> <\/p>\n<h4>Query Volume Modelling<\/h4>\n<p align=\"justify\">Selecci\u00f3n 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\u00e9s de la escritora evento puede resultar en volumen un-necesario y los costos de almacenamiento asociados.<\/p>\n<p align=\"justify\">Los clientes pueden recoger una muestra de datos de consulta y respuesta de la tala anal\u00edtica 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\u00e9rminos de dominio de segundo nivel (SLD). <\/p>\n<p align=\"justify\">Tomando los mejores SLD, con exclusi\u00f3n del condado TLD como clientes .co.uk puede modelar la reducci\u00f3n del volumen de consultas por la aplicaci\u00f3n 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\u00f3n de una soluci\u00f3n 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.<\/p>\n<p align=\"justify\">En nuestro prototipo, un valor de 100 SLD fue elegido para la aplicaci\u00f3n sobre la base de datos de la muestra registrados en la red. Esto dio lugar a una reducci\u00f3n 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\u00e1cilmente manejable por grandes datos y la infraestructura de WEC.<\/p>\n<h4><b>Resultados de la prueba Piloto<\/b><\/h4>\n<p align=\"justify\">Se ha trabajado para realizar un piloto con el registro anal\u00edtico, 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\u00e9 de DNS. Una peque\u00f1a instant\u00e1nea del volumen de consultas que este proyecto estaba tratando con es:<\/p>\n<p><a href=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a04.jpg\"><img loading=\"lazy\" decoding=\"async\" title=\"www.radians.com.ar\" style=\"border-top: 0px; border-right: 0px; border-bottom: 0px; float: none; margin-left: auto; border-left: 0px; display: block; margin-right: auto\" border=\"0\" alt=\"www.radians.com.ar\" src=\"http:\/\/www.radians.com.ar\/Articulos\/Images2014\/NetworkForensicsconWindowsDNSAnalyticalL_182\/a04_thumb.jpg\" width=\"540\" height=\"241\" \/><\/a><\/p>\n<p align=\"justify\">El tama\u00f1o total de la filtraci\u00f3n posterior almacenamiento de datos en bruto de los 29 servidores DNS de Microsoft corporativa picos a aprox. 100GB \/ d\u00eda en las horas de m\u00e1s afluencia, y desciende a alrededor de 15 GB \/ d\u00eda durante los per\u00edodos de menor afluencia, como los fines de semana. <strong>Esto permite una nueva forma de utilizar la informaci\u00f3n relacionada con los dominios comprometidos, la identificaci\u00f3n de las transacciones maliciosos, m\u00e1quinas infectadas y por lo tanto que nos permite controlar y fortalecer nuestra red.<\/strong><\/p>\n<p align=\"justify\">Espero que les sea de inter\u00e9s. Saludos. Roberto Di Lello.<\/p>\n<p><strong>Pueden leer mas sobre este tema en: <a title=\"https:\/\/blogs.technet.microsoft.com\/teamdhcp\/2015\/11\/23\/network-forensics-with-windows-dns-analytical-logging\/\" href=\"https:\/\/blogs.technet.microsoft.com\/teamdhcp\/2015\/11\/23\/network-forensics-with-windows-dns-analytical-logging\/\">Blogs TechNet<\/a><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hoy vamos a ver como realizar un chequeo exaustivo de red (network forensics) de nuestros&#8230;<\/p>\n","protected":false},"author":1,"featured_media":4291,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[158],"tags":[217,230,243],"class_list":["post-2997","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows-server-2012","tag-ad-domain-services","tag-seguridad","tag-windows-server-2012-r2"],"_links":{"self":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2997","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2997"}],"version-history":[{"count":1,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2997\/revisions"}],"predecessor-version":[{"id":2998,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2997\/revisions\/2998"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/media\/4291"}],"wp:attachment":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2997"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2997"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2997"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}