
Сетевой пассивный регистратор DNS, захватывающий и регистрирующий DNS-запросы из живого трафика или файлов pcap, выводящий JSON для интеграции с платформами SIEM и threat intelligence.
DNS-логгер на основе захвата сетевого трафика в Go
DNS-логгер на основе захвата сетевого трафика, вдохновлённый проектом https://github.com/gamelinux/passivedns. Он использует gopacket для работы с libpcap и обработки пакетов, а также выводит логи в формате JSON. Предназначен для обработки большого объёма запросов в средах с количеством DNS-резолверов от одного до сотен.
Это хороший выбор. Я создал этот инструмент, потому что считаю, что задачи, связанные с обработкой больших объёмов непроверенных данных с множеством плохо задокументированных крайних случаев, должны выполняться управляемой средой выполнения для предотвращения атак, связанных с повреждением памяти. Я развернул PassiveDNS в нескольких организациях и создал gopassivedns для решения нескольких конкретных проблем, с которыми столкнулся: мне нужно было инструментировать множество мест, масштабировать уровень хранения для обработки ОГРОМНОГО количества запросов, и я хотел иметь набор тестов с хорошим покрытием всех крайних случаев DNS.
Тоже хороший выбор. Системы, такие как Bro, обычно развёртываются на сетевых выходах, что приводит к сокрытию реального источника запроса за вашими рекурсивными резолверами. Это означает, что вам обычно нужно развернуть Bro и вести логирование запросов резолверов (если это возможно), а затем интегрировать логи из обеих систем в центральную систему логирования для отслеживания запроса до клиента. gopassivedns был спроектирован для развёртывания на ваших резолверах без изменений их конфигурации и/или на сетевых выходах, для централизованного логирования по надёжному протоколу и простого разбора в любую систему логирования.
Поддержка резолверами логирования запросов, включая как вопрос, так и ответ, в лучшем случае неравномерная. Один из самых распространённых DNS-серверов, BIND, вообще его не поддерживает. Другие, например Windows DNS, имеют ужасные форматы логов. Кроме того, сетевое логирование позволяет перехватывать запросы, отправленные напрямую на удалённые серверы (например, Google DNS) от ваших клиентов.
Параметры конфигурации можно указать через переменные окружения, в файле .env или в командной строке. Приоритет: флаги командной строки, файл .env, затем переменные, уже определённые в окружении. Параметры конфигурации перечислены ниже.
Вы должны указать либо -dev, либо -pcap.
Существуют известные проблемы с горутинами и стандартным процессом демонизации (https://github.com/golang/go/issues/227), поэтому я настоятельно рекомендую использовать один из методов, описанных здесь: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu, чтобы запустить этот процесс как демон с помощью системных инструментов.
Если вы решите использовать логирование через syslog, мы используем пакет golang "log/syslog", который требует, чтобы UNIX-сокет для связи с syslog находился в одном из следующих мест: /dev/log, /var/run/log или /var/run/syslog.
У вас есть 3 варианта: развернуть его на ваших резолверах, на ваших шлюзах или и там, и там. Развёртывание на резолверах хорошо тем, что вы получите IP-адрес клиента, отправившего исходный запрос. Вы также сможете видеть восходящий участок запроса (от резолвера к следующему резолверу в цепочке), если не настроите BPF-фильтр на игнорирование этого участка. Развёртывание на шлюзах означает, что вы не видите участок клиент -> внутренний резолвер, поэтому может быть сложно связать запрос с конкретным клиентом. С другой стороны, вы увидите запросы, которые обходят ваши внутренние резолверы. Вы также, конечно, увидите запросы, идущие от резолвера к вышестоящему резолверу, который он использует. В идеальном мире я бы развернул этот инструмент на каждом из моих внутренних резолверов и на ответвлении от шлюзов. Внутренние резолверы имели бы BPF-фильтр, игнорирующий восходящий участок запроса, а шлюз не игнорировал бы ничего.
На данный момент я рекомендую использовать logstash для отправки логов в кластер elasticsearch. Все логи в формате JSON, так что это должно быть довольно просто. Я также предлагаю использовать что-то вроде HDFS для долгосрочного хранения и массового анализа. DNS-запросы — это удивительный источник внутренних данных!