Создание систем DNS Sinkhole и DNS Logs Monitoring

Pi-hole, все более популярный блокировщик сетевой рекламы, предназначенным для работы на Raspberry Pi. Pi-hole функционирует как DNS-сервер вашей сети, позволяя ему блокировать рекламные домены, вредоносные домены и другие домены (или подстановочные знаки TLD), которые вы добавляете в свои списки блокировки, что фактически превращает его в облегченную дыру DNS с открытым исходным кодом. Эта блокировка происходит на сетевом уровне, то есть заблокированные ресурсы даже не достигают браузера вашей конечной точки. Наряду с кэшированием это может повысить производительность загрузки веб-сайта и заблокировать рекламу, которую сложно заблокировать на стороне клиента, например рекламу в приложении на устройстве Android или iOS. Здесь мы разберем создание систем DNS Sinkhole и DNS Logs Monitoring.

Pi-hole

Pi-Hole — это DNS-сервер/сетевой блокировщик рекламы/DNS-приемник, который предназначен для работы на минимальном оборудовании, включая Raspberry Pi. Я установил Pi-hole на серверную виртуальную машину Ubuntu 16.04.3. Обычно Pi-hole отлично работает только с 1 ядром ЦП и 512 МБ ОЗУ, хотя я выделил больше, чтобы учесть накладные расходы на доставку журналов. Pi-hole подходит для сетей SOHO и SMB с отчетами об успешном использовании в сетях, содержащих сотни конечных точек.

Установка и настройка Pi-hole хорошо задокументированы в другом месте, поэтому я не буду останавливаться на деталях здесь. На самом деле вы можете установить Pi-hole с помощью 1-строчной команды (curl -sSL https://install.pi-hole.net | bash), хотя, конечно, всегда рекомендуется проверять сценарий перед его выполнением. Запуск сценария установки проведет вас через первоначальную настройку, где вы можете назначить статический IP-адрес серверу Pi-hole, выбрать службу разрешения DNS вышестоящего уровня (я рекомендую решение, ориентированное на безопасность и конфиденциальность, такое как OpenDNS или Quad9), и включить веб-интерфейс администратора.

http://pi-hole.net/

Пароль администратора отображается в конце сценария установки, хотя вы всегда можете изменить его позже. После установки вы можете просмотреть превосходную панель инструментов Pi-hole и выполнить большинство административных задач, войдя в ее веб-интерфейс по адресу http://pi.hole/admin/.

Веб-интерфейс и панель управления Pi-hole. Вы также можете подключиться к его серверу по SSH, чтобы вручную редактировать файлы конфигурации и управлять другими изменениями.

После того, как Pi-hole запущен, вам необходимо указать конечным точкам IP-адрес вашего сервера Pi-hole (который должен быть статическим), чтобы в будущем они использовали Pi-hole для разрешения DNS. Вы можете установить это вручную для каждого устройства. Вы также можете настроить большинство маршрутизаторов для использования Pi-hole в качестве DNS-сервера. Помимо работы в качестве DNS-сервера вашей сети, Pi-hole (опять же благодаря dnsmasq) также может быть DHCP-сервером. Существуют различные плюсы и минусы, такие как видимость IP-адресов конечных точек, которые применяются к этим различным вариантам развертывания, поэтому ознакомьтесь с соответствующей документацией Pi-hole для получения более подробной информации. По умолчанию Pi-hole использует несколько списков блокировки рекламы, хотя вы можете добавлять свои собственные списки и домены или подстановочные знаки через веб-интерфейс или командную строку.

Пример ручного добавления zip gTLD в качестве подстановочного знака в черные списки Pi-hole через веб-интерфейс.

Конвейер журналов DNS

По умолчанию Pi-hole хранит свои журналы dnsmasq в /var/log/pihole.log. Помимо просмотра показателей и списков на панели инструментов, существует несколько способов просмотра этих журналов вручную, включая область «Журнал запросов» веб-интерфейса, «Tail pihole.log» в разделе «Инструменты» в веб-интерфейсе и напрямую через доступ по SSH. на базовый сервер, на котором работает Pi-hole (например, tail /var/log/pihole.log -f). Основываясь на метриках Dashboard, я знаю, что в большинстве дней развертывание моей лаборатории Pi-hole блокирует в среднем около 10% от общего числа разрешений домена, а поддомены телеметрии Windows 10 часто являются наиболее блокируемыми DNS-запросами (что здорово, потому что это в противном случае отключить такую ​​телеметрию Win10 где-то между чрезвычайно сложным и невозможным). Хотя такая информация полезна, мы можем отправить эти ценные журналы DNS в централизованное место для пополнения журналов и целей мониторинга, включая аналитику безопасности и поиск угроз.

Необработанные журналы dnsmasq показаны в следующем фрагменте из pihole.log:

Feb 2 11:09:26 dnsmasq[19413]: query[A] ocos-office365-s2s.msedge.net from 192.168.2.48

Feb 2 11:09:26 dnsmasq[19413]: forwarded ocos-office365-s2s.msedge.net to 9.9.9.9

Feb 2 11:09:26 dnsmasq[19413]: query[A] config.edge.skype.com from 192.168.2.148

Feb 2 11:09:26 dnsmasq[19413]: forwarded config.edge.skype.com to 9.9.9.9

Feb 2 11:09:26 dnsmasq[19413]: query[A] client-office365-tas.msedge.net from 192.168.2.48

Feb 2 11:09:26 dnsmasq[19413]: forwarded client-office365-tas.msedge.net to 9.9.9.9

Feb 2 11:09:26 dnsmasq[19413]: reply ocos-office365-s2s.msedge.net is <CNAME>

Feb 2 11:09:26 dnsmasq[19413]: reply ocos-office365-s2s-msedge-net.e-0009.e-msedge.net is <CNAME>

Feb 2 11:09:26 dnsmasq[19413]: reply e-0009.e-msedge.net is 13.107.5.88

Feb 2 11:09:26 dnsmasq[19413]: reply config.edge.skype.com is <CNAME>

Feb 2 11:09:26 dnsmasq[19413]: reply s-0001.s-msedge.net is 13.107.3.128

Feb 2 11:09:26 dnsmasq[19413]: reply client-office365-tas.msedge.net is <CNAME>

Feb 2 11:09:26 dnsmasq[19413]: reply afdo-tas-offload.trafficmanager.net is <CNAME>

Feb 2 11:09:26 dnsmasq[19413]: reply vip5.afdorigin-prod-ln02.afdogw.com is 51.140.98.69

Feb 2 11:09:28 dnsmasq[19413]: query[PTR] 69.98.140.51.in-addr.arpa from 192.168.2.48

Feb 2 11:09:28 dnsmasq[19413]: forwarded 69.98.140.51.in-addr.arpa to 9.9.9.9

Feb 2 11:09:28 dnsmasq[19413]: reply 51.140.98.69 is NXDOMAIN

Из примеров журналов видно, что одна из моих лабораторных машин использует IP-адрес 192.168.2.48, что я использую относительно новый Quad9 (9.9.9.9, понятно?) в качестве восходящего DNS-провайдера в Pi-hole, и что там — это несколько DNS-запросов, которые, вероятно, связаны с программным обеспечением Microsoft.

Это не самые красивые типы журналов, которые я когда-либо видел — по сути, есть несколько строк для каждого типа события DNS — но они выполняют свою работу и имеют стандартизированную отметку времени в стиле системного журнала для каждой строки, которую мы необходимо для нашего конвейера доставки журналов в стек ELK.

На высоком уровне это представляет собой конвейер доставки журналов, который я создал для прототипа:

Endpoints (клиентские DNS-запросы) > Pi-hole (DNS-сервер/sinkhole) > Filebeat (доставщик журналов) > Logstash (формирователь журналов) > Elasticsearch (сервер хранения и индексирования журналов) и Kibana (интерфейс для анализа журналов)

По сути, конечные точки используют Pi-hole в качестве своего DNS-сервера. Pi-hole регистрирует события dnsmasq, включая разрешения домена и совпадения черного списка, в локальный файл журнала. Я решил использовать Filebeat, один из облегченных поставщиков журналов Elastic, непосредственно на сервере Pi-hole, чтобы отправлять эти журналы dnsmasq в режиме реального времени на сервер Logstash. Я создал несколько пользовательских конфигураций для Logstash, чтобы реализовать базовые сопоставления полей, внедрить точную временную метку и обогатить журналы, добавив поиск местоположения GeoIP для внешних IP-адресов из разрешенных доменов. Затем Logstash отправляет эти обработанные журналы на отдельный сервер Elasticsearch для хранения и индексации, а Kibana служит интерфейсом на том же сервере для ручного поиска, визуализации и информационных панелей.

Кроме того, одна из причин, по которой я нашел этот проект интересным, заключается в том, что в Интернете много говорят о работе с журналами BIND и Microsoft DNS, но не так много о журналах dnsmasq. Тем не менее, хотя описанный здесь конвейер журналов DNS предназначен для журналов dnsmasq Pi-Hole, его можно легко адаптировать для других типов журналов DNS, таких как BIND и Microsoft.

Вернемся к делу. Давайте рассмотрим каждую из основных частей конвейера журналов DNS более подробно. В этом руководстве не рассматривается установка и базовая настройка самого стека ELK, так как это хорошо задокументировано в другом месте. Для тестирования я установил Logstash на виртуальную машину Ubuntu 16.04.3 Server, а Elasticsearch и Kibana — на отдельную виртуальную машину Ubuntu Server. Мой главный совет по развертыванию ELK — убедиться, что вы выделяете достаточно оперативной памяти. Прежде чем продолжить, убедитесь, что все ваши серверы Logstash, Elasticsearch и Kibana работают, и вы знаете их статические IP-адреса. Для этого проекта я использую версии 6.1.x компонентов стека ELK.

Filebeat

Во-первых, нам нужно установить Filebeat на сервер Pi-hole. Обратите внимание, что, хотя у самой Pi-hole минимальные системные требования (обычно нормально работает с 1 ядром и 512 МБ ОЗУ), запуск Filebeat на том же сервере приведет к некоторым потерям производительности. В моем случае я ошибся из-за осторожности и выделил 2 ядра и 2 ГБ ОЗУ для сервера Pi-hole, чтобы учесть добавление FileBeat, но даже это, вероятно, излишне для небольшого развертывания. Использование ЦП незначительно, а общее использование ОЗУ обычно составляет <10% на моем сервере Pi-hole.

Типичная нагрузка на мой сервер Pi-hole, не потеет.

Поскольку я использую Ubuntu Server, я могу вручную получить и установить 64-битный пакет DEB или следовать инструкциям Elastic по установке из официального репозитория. Процесс будет таким же для других дистрибутивов на базе Debian.

После установки Filebeat мне нужно настроить его файл конфигурации filebeat.yml для отправки журналов Pi-hole на мой сервер Logstash. Вы можете либо использовать проводник Filebeat по умолчанию, который включает расположение по умолчанию /var/log/*.log (все файлы журналов по этому пути), либо указать /var/log/pihole.log, чтобы отправлять только журналы dnsmasq Pi-hole.

Фрагмент старателей Filebeat из файла filebeat.yml

Нам также нужно указать Filebeat IP-адрес сервера Logstash. Я придерживаюсь порта Logstash по умолчанию 5044.

Замените значение hosts на статический IP-адрес вашего сервера Logstash.

Поскольку я использую сервер Ubuntu 16.04.3 в качестве базовой ОС для всего, правильная команда для запуска Filebeat вручную: sudo systemctl start filebeat. Filebeat немедленно начнет отправлять определенные журналы в Logstash. Вы также можете настроить Filebeat (а также компоненты стека ELK) для автоматического запуска при загрузке.

Logstash

В то время как Filebeat требует минимальной настройки для начала работы, настройка Logstash требует гораздо больше усилий. Для конвейера журналов DNS я установил Logstash на выделенную виртуальную машину Ubuntu Server. Я назвал свой пользовательский файл конфигурации dnsmasq.conf и в итоге написал свои собственные фильтры шаблонов grok, чтобы они соответствовали интересным журналам dnsmasq, чтобы правильно обрабатывать и обогащать их.

Во-первых, мы указываем ввод Logstash в нашем пользовательском файле конфигурации, который просто прослушивает порт 5044 по умолчанию для журналов, отправленных из Filebeat:

input {

beats {

port => 5044

type => "logs"

}

}

Затем нам нужно создать собственный фильтр grok для сопоставления с конкретными интересующими нас журналами dnsmasq. Это была самая трудоемкая часть этого проекта, поскольку существует несколько форматов, которые принимают журналы dnsmasq, и, по сути, одно событие DNS получает разбит на несколько строк. Здесь я впервые узнал о https://grokconstructor.appspot.com/, чрезвычайно полезном веб-инструменте для создания и тестирования шаблонов регулярных выражений grok. Путем проб и ошибок я получил несколько основных совпадений, работающих для журналов запросов и ответов DNS. Очевидно, что предстоит еще много работы; например, домен из черного списка и исходный IP-адрес клиента регистрируются dnsmasq в отдельных строках (по сути, это отдельные журналы), поэтому адресация остается в моем списке дел.

 

filter { grok { patterns_dir => ["./patterns"] match=> { "message" => ["^%{logdate:LOGDATE} dnsmasq\[[\d]+\]\: query\[[\w]+\] %{domain:DOMAIN} from %{clientip:CLIENTIP}", "^%{logdate:LOGDATE} dnsmasq\[[\d]+\]\: reply %{domain:DOMAIN} is %{ip:IP}", "^%{logdate:LOGDATE} dnsmasq\[[\d]+\]\: %{blocklist:BLOCKLIST} %{domain:DOMAIN} is %{ip:IP}"]

} }

Приведенный выше пример шаблонов grok соответствует трем типам журналов dsnmasq, включая первоначальные DNS-запросы, ответы и запросы из черного списка.

Вы можете видеть в моем фильтре, что я также указываю «patterns_dir». Чтобы использовать пользовательские шаблоны (которые я назвал так же, как и соответствующие поля, написанные ЗАГЛАВНЫМИ БУКВАМИ) в grok match, вы должны перечислить их в файле шаблонов, расположенном в указанном каталоге.

Содержимое моего файла шаблонов, который я просто сохранил в \patterns\dnsmasq:

logdate [\w]{3}\s[\s\d]{2}\s\d\d\:\d\d\:\d\d

blocklist [\/\w\.]+

domain [\w\.\-]+

clientip \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}

ip \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}

Обратите внимание, что я еще не закончил писать и совершенствовать шаблоны grok для всех возможных типов и полей журнала dnsmasq. Есть несколько типов журналов dnsmasq, которые мне все еще нужно решить, и я уверен, что нужны уточнения для несколько грубых, но эффективных шаблонов, которые я написал, для учета таких вещей, как нечетные символы в именах доменов. Тем не менее, с тремя шаблонами, которые я написал и протестировал, их достаточно, чтобы начать работу с нашим конвейером журналов DNS, предназначенным для интересного анализа журналов в ELK.

Одна проблема, с которой я быстро столкнулся во время тестирования, заключалась в том, что поле @timestamp не соответствовало моему полю LOGDATE после того, как журналы поступили в Elasticsearch для индексации. LOGDATE представляет исходную метку времени события dnsmasq, а @timestamp, добавленный в Elasticsearch, представляет время, когда журнал был успешно отправлен в Elasticsearch, что обычно немного отстает от LOGDATE. К счастью, плагин фильтра даты Logstash позволяет легко исправить это следующим образом:

date {

match => [ "LOGDATE", "MMM dd HH:mm:ss", "MMM d HH:mm:ss" ]

}

По сути, журналы dnsmasq имеют 2 возможных представления для своего поля временной метки в стиле системного журнала, которое я назвал LOGDATE, состоящее из двухзначных дней и однозначных дней, которым предшествует дополнительный пробел. Приведенный выше фильтр даты нормализует это так, чтобы поле @timestamp точно соответствовало исходному соответствующему полю LOGDATE, а также добавляло текущий год.

При поиске разрешения домена у вас есть полученные IP-адреса, регистрируемые Pi-hole. Соответственно, мы хотим обогатить наши журналы данными о местоположении GeoIP. Плагин фильтра геоip от Logstash значительно упростил эту задачу:

geoip {

source => "IP"

}

Что это дает? Всякий раз, когда этот фильтр идентифицирует IP-адрес для разрешимого домена, он обогащает документ данными о местоположении GeoIP, добавляя различные поля (исходя из включенной базы данных Maxmind Lite), например:

Как видно из Kibana, данные GeoIP добавляются в документ на основе его поля IP.

С помощью этих данных GeoIP можно будет выполнять поиск и создавать визуализации Kibana, такие как карты, на основе геолокации IP-адресов.

Наконец, нам нужно настроить Logstash для отправки этих обновленных и дополненных журналов на сервер Elasticsearch. В моем образце конфигурации Logstash это выглядит так (обязательно укажите свой собственный IP-адрес и предпочтение соглашения об именах индексов):

output {

elasticsearch {

hosts => ["192.168.2.52:9200"]

index => "logstash-dnsmasq-%{+YYYY.MM.dd}"

}

}

Когда я отлаживаю свою конфигурацию, я часто нахожу полезным также включить вывод на экран через плагин Logstash stdout.

output {

elasticsearch {

#protocol => "http"

hosts => ["192.168.2.52:9200"]

index => "logstash-dnsmasq-%{+YYYY.MM.dd}"

}

stdout {

codec => rubydebug

}

}

Как только файл конфигурации будет готов, запустите Logstash и укажите, что он загружает наш файл конфигурации: sudo bin/logstash -f dnsmasq.conf

Не расстраивайтесь, если Logstash выдает ошибку, связанную с вашим конфигурационным файлом; внимательно прочитайте сообщение об ошибке и соответствующим образом исправьте конфигурацию. По моему опыту, обычно виноват ошибочный или отсутствующий символ скобки или другая опечатка.

После запуска Logstash вы должны увидеть что-то вроде следующего, указывающее, что он успешно прослушивает свой порт по умолчанию для журналов:

Logstash работает со своим прослушивателем по умолчанию на порту 5044.

И если вы включили фильтр stdout, обработанные журналы будут выводиться на экран в режиме реального времени. Это часто полезно для отладки проблем с фильтром grok или другими частями вашего общего конвейера журналов.

Фильтр Logstash stdout подтверждает успех! Журналы формируются, обогащаются и отправляются, как и ожидалось.

Прежде чем перейти к этому моменту, вы должны установить и запустить Elasticsearch и Kibana на отдельном сервере с большим количеством выделенной оперативной памяти. Чтобы убедиться, что наш конвейер журналов работает правильно от начала до конца, запросите Elasticsearch из командной строки или веб-браузера, чтобы получить список соответствующих индексов Logstash:

Индексы Logstash в Elasticsearch.

Как только это будет сделано, вы можете завершить настройку своего индекса в Kibana и приступить к просмотру журналов. В Kibana перейдите в «Управление» > «Шаблоны индексов» и завершите создание нового шаблона индекса, соответствующего соглашению об именовании индексов, которое вы настроили в Logstash.

Создайте шаблон индекса для журналов Logstash.

Обязательно используйте поле @timestamp в качестве «имени поля фильтра времени», нажмите «Создать шаблон индекса», и все готово для начала работы с журналами в Kibana.

Kibana Discover, показывающий, что наш конвейер журналов DNS работает должным образом. Журналы имеют соответствующие сопоставления полей и поля GeoIP в соответствии с нашей конфигурацией Logstash.

Заключение

В своем следующем посте я поделюсь некоторыми примерами поиска, визуализаций и информационных панелей Kibana, которые эффективно используют наши новые и улучшенные журналы DNS Pi-hole для мониторинга безопасности и аналитики. Я также поделюсь дополнительными извлеченными уроками и рекомендациями по следующим шагам для этого проекта. А пока вы можете найти мои примеры конфигураций на GitHub, с оговоркой, что на данный момент они все еще должны рассматриваться в основном на стадии бета-тестирования.