phillipmartin/gopassivednsRegistrador de DNS pasivo basado en red que captura y registra consultas DNS desde tráfico en vivo o archivos pcap, generando JSON para integración con plataformas SIEM y de inteligencia de amenazas.
Registro de DNS basado en red en Go
Un registrador de DNS basado en captura de red, inspirado en https://github.com/gamelinux/passivedns. Utiliza gopacket para manejar libpcap y el procesamiento de paquetes. Genera registros en JSON. Está diseñado para manejar capturas de consultas de alto volumen en entornos con cualquier cantidad de resolutores DNS, desde uno hasta cientos.
Es una buena opción. Construí esto porque creo que tareas que implican procesar grandes cantidades de datos no confiables con muchos casos límite mal documentados deben ser manejadas por un runtime administrado para prevenir ataques de corrupción de memoria. He implementado PassiveDNS en varias organizaciones y construí gopassivedns para resolver algunos puntos débiles específicos que observé: necesitaba instrumentar muchas ubicaciones, necesitaba escalar la capa de almacenamiento para manejar MUCHAS búsquedas y quería un conjunto de pruebas con buena cobertura para todos los casos límite de DNS.
También es una buena opción. Sistemas como Bro generalmente se implementan en las salidas de red, lo que tiene la consecuencia de ocultar la fuente real de la consulta detrás de sus resolutores recursivos. Esto significa que generalmente necesitas implementar Bro y realizar el registro de consultas del resolutor (si es posible), e integrar los registros de ambos en un sistema de registro central para rastrear una consulta hasta un cliente. gopassivedns fue diseñado para implementarse en sus resolutores sin cambios en la configuración del resolutor y/o en las salidas de red, registrar de manera centralizada a través de un protocolo confiable y analizarse simplemente en cualquier sistema de registro.
El soporte de los resolutores para el registro de consultas, que incluya tanto la pregunta como la respuesta, es irregular en el mejor de los casos. Uno de los servidores DNS más implementados, BIND, no lo soporta en absoluto. Otros, como Windows DNS, tienen formatos de registro realmente horribles. Además, el registro basado en red capturará consultas enviadas directamente a servidores remotos (por ejemplo, Google DNS) desde sus clientes.
Las opciones de configuración se pueden especificar como variables de entorno, en un archivo .env o en la línea de comandos. La prioridad es: banderas de línea de comandos, archivo .env y finalmente variables ya definidas en el entorno. Las opciones de configuración son las siguientes:
Debe proporcionar -dev o -pcap.
Existen problemas conocidos con goroutines y el proceso estándar de daemonización (https://github.com/golang/go/issues/227), por lo que recomiendo encarecidamente que use uno de los métodos detallados aquí: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu para ejecutar este proceso como un demonio utilizando herramientas del sistema.
Si elige usar el registro de syslog, usamos el "log/syslog" de Go, que requiere un socket Unix para comunicarse con syslog, ubicado en /dev/log, /var/run/log o /var/run/syslog.
Tiene 3 opciones: implementarlo en su(s) resolutor(es), en su(s) puerta(s) de enlace o en ambos. Implementarlo en sus resolutores es bueno porque obtendrá la dirección IP del cliente que envió la solicitud original. También puede ver el tramo ascendente de la solicitud (del resolutor al siguiente resolutor en la cadena), a menos que ajuste su filtro BPF para ignorar ese tramo. Implementarlo en sus puertas de enlace significa que no ve el tramo cliente -> resolutor interno, por lo que puede ser difícil vincular una solicitud a un cliente específico. Por otro lado, verá solicitudes que eluden sus resolutores internos. También, por supuesto, verá las consultas que provienen del resolutor hacia el resolutor ascendente que utiliza. En un mundo ideal, implementaría esta herramienta en cada uno de mis resolutores internos y en un punto de acceso (tap) en mis puertas de enlace. Los resolutores internos tendrían un filtro BPF que ignore el tramo ascendente de la consulta, y la puerta de enlace no ignoraría nada.
Por ahora, recomendaría usar logstash para enviar los registros a un clúster de elasticsearch. Todos los registros están en JSON, por lo que esto debería ser bastante fácil. También sugeriría usar algo como HDFS para almacenamiento a largo plazo y análisis masivo. ¡Las consultas DNS son una fuente increíble de datos internos!
