Конфигурация зоны политик ответов (RPZ) в разрешающем сервере BIND на системах Debian/Ubuntu

Это руководство демонстрирует процесс изменения общедоступных DNS записей в вашем DNS сервере BIND с использованием механизма зон политики ответов (RPZ) на операционных системах Debian/Ubuntu.

Что представляет собой область политики ответов?

Зона политик ответов (RPZ) предоставляет DNS-разрешателю возможность изменять записи DNS. Она была изначально создана для блокировки доступа к опасным веб-ресурсам. К примеру, когда компьютер запрашивает IP-адрес сайта, известного распространением вредоносного ПО, DNS-разрешатель может вернуть 127.0.0.1 в ответ, что предотвратит подключение к этому небезопасному ресурсу. Это и есть основной сценарий использования. Поэтому зону политик ответов также называют DNS-файрволом.

RPZ можно применять и другими методами. Например,

• Если у вас есть свои собственные сервисы, например, Nextcloud, работающие в локальной сети, вы можете применить RPZ для перенаправления домена вашего Nextcloud (nextcloud. your-domain.com) на локальный IP-адрес. Это позволит вам избежать выхода в Интернет и последующего возвращения в локальную сеть для доступа к серверу Nextcloud.
• Родители способны применять RPZ для ограничения доступа своих детей к сайтам с порнографическим контентом.
• Вы имеете возможность отключать рекламу, которая вам не интересна.
• Я устанавливаю множество веб-приложений на своем VPS. Если веб-приложение не предназначено для публичного доступа, я добавляю DNS-запись только в RPZ BIND и не публикую ее у регистратора доменов, чтобы избежать взлома.

Конечно, вы можете добавить запись DNS в файл /etc/hosts на своем локальном компьютере для замены публичных DNS-записей, однако это решение не подходит для масштабного использования. Кроме того, на iOS и Android нет возможности создавать локальные DNS-записи. Не было бы здорово, если бы DNS-резолвер BIND мог переопределять публичные записи, позволяя всем устройствам в сети, использующим этот резолвер, использовать индивидуальные DNS-записи?

Начальные условия

Для использования данного руководства предполагается, что на вашем сервере с Debian или Ubuntu уже установлен и запущен DNS-резолвер BIND. Если это не так, рекомендуем ознакомиться с одним из следующих руководств по установке BIND.

• Конфигурация персонального DNS-разрешателя BIND9 на Debian 10 Buster
• Установка и конфигурация собственного DNS-резолвера BIND9 на Ubuntu 16.04/18.04.
• Конфигурация персонального DNS-разрешателя BIND9 на Ubuntu 20.04.

После запуска вашего разрешателя BIND выполните следующие шаги.

Настройка зоны политики ответов BIND на серверах Debian и Ubuntu.

Первым делом внесите изменения в файл named.conf.options.

sudo nano /etc/bind/named.conf.options

Включите указанные строки в раздел параметров.<. >Чтобы активировать область ответной политики.

//включить зону политики ответов. response-policy < zone "rpz. local"; >;

Сохраните изменения и закройте файл. После этого откройте файл с именем named.conf.local.

sudo nano /etc/bind/named.conf.local

Включите область RPZ в данный файл.

zone "rpz. local" < type master; file "/etc/bind/db. rpz. local"; allow-query < localhost; >разрешить передачу< 12.34.56.78; >; >;

• Необходимо применять абсолютный путь вместо простого имени файла в директиве file, иначе BIND воспримет файл как находящийся в каталоге /var/cache/bind/.
• Зоны RPZ должны принимать запросы исключительно от localhost. Добавление локальных сетевых клиентов не требуется.
• Поменяйте 12.34.56.78 на IP-адрес резервного BIND DNS-резолвера, которому разрешен перенос зоны. Если имеется только один DNS-резолвер, можно использовать localhost следующим образом: allow-transfer.< localhost; >;

Сохраните и закройте документ. После этого необходимо создать файл зоны. Вместо того чтобы начинать его создание с нуля, мы можем воспользоваться шаблоном файла зоны. Скопируйте содержимое файла db. empty в новый документ.

sudo cp /etc/bind/db. empty /etc/bind/db. rpz. local

После этого внесите изменения в файл db. rpz.

sudo nano /etc/bind/db. rpz. local

Не требуется вносить изменения в текущее содержимое. Мы просто добавим собственные DNS-записи. Например, если у вас имеется сервер Nextcloud в локальной сети с IP-адресом 192.168.0.103, добавьте следующую DNS-запись, чтобы пользователям Nextcloud не пришлось выходить в Интернет для доступа к серверу.

nextcloud. your-domain.com A 192.168.0.103

Чтобы предотвратить доступ ваших детей к порно-сайтам, таким как pornhub.com, внесите следующую строку в этот файл для блокировки всего домена pornhub.com.

*.pornhub.com CNAME .

Если вы предпочитаете не видеть рекламу Google Adsense на своих веб-страницах, можно добавить следующую строку, чтобы заблокировать домен doubleclick.net, используемый для показа рекламы Adsense.

*.doubleclick.net CNAME .

Вот ещё несколько доменов рекламных серверов, которые вы можете заблокировать.

*.pubmatic.com CNAME . *.mopub.com CNAME . *.eskimi.com CNAME . *.adcolony. xyz CNAME . *.adsrvr. org CNAME . *.adsymptotic.com CNAME . *.servedby-buysellads.com CNAME . srv. buysellads.com CNAME . *.powerinboxedge.com CNAME . *.defof.com CNAME . *.licasd.com CNAME . *.liadm.com CNAME .

Для изменения MX-записи домена добавьте строку, аналогичную приведенной ниже.

example.com MX 0 mail.example.com.

Учтите, что имена, расположенные слева, не должны содержать точку в конце, в то время как имена справа должны обязательно заканчиваться точкой.

Если вам необходимо обеспечить балансировку нагрузки для хоста, создайте запись с несколькими значениями, как показано ниже. DNS-клиенты будут случайным образом использовать два IP-адреса, что позволит распределить трафик между ними.

host. example.com A 12.34.56.78 A 12.34.56.79

Закройте и сохраните файл. Рекомендуется создавать отдельный лог-файл для RPZ, чтобы упростить анализ. Для настройки внесите изменения в главный конфигурационный файл BIND.

sudo nano /etc/bind/named.conf

Внесите указанные строки в файл.

logging < channel rpzlog < file "/var/log/named/rpz.log" versions unlimited size 100m; print-time yes; print-category yes; print-severity yes; severity info; >Конечно! Пожалуйста, предоставь текст, который ты хочешь перефразировать.< rpzlog; >; >;

Закройте файл после сохранения. Затем создайте директорию /var/log/named/ и назначьте владельцем bind.

sudo mkdir /var/log/named/ sudo chown bind:bind /var/log/named/ - R

Выполните следующую команду для проверки синтаксиса основного конфигурационного файла. Если ошибок нет, вывод будет пустым.

sudo named-checkconf

Проверьте корректность синтаксиса файлов зоны RPZ.

sudo named-checkzone rpz /etc/bind/db. rpz. local

Если ошибок не найдено, выполните перезапуск BIND9.

sudo systemctl restart bind9

Теперь вы можете воспользоваться командой dig на сервере BIND, чтобы проверить, функционирует ли RPZ. Например, выполните запрос DNS-записи для доменного имени, которое добавлено в зону политики ответов.

dig A nextcloud. your-domain.com @127.0.0.1

В выводе команды вы должны обнаружить нечто подобное, указывающее на то, что ответ DNS был извлечён из локального RPZ.

;; AUTHORITY SECTION: rpz. local 86400 IN NS localhost.

Вы можете также просмотреть журнал запросов BIND9.

sudo tail /var/log/named/rpz.log

Вы столкнетесь с аналогичным сообщением, что указывает на то, что ответ был извлечен из локального RPZ.

(example.com): rpz QNAME Local-Data rewrite example.com via example.com. rpz. local

Клиент Fedora не применяет RPZ?

В Fedora RPZ не активирован по умолчанию. Чтобы определить IP-адрес хоста в зоне RPZ, можно воспользоваться командной утилитой dig, однако при попытке выполнить ping на имя хоста, IP-адрес не будет обнаружен.

Для решения данной проблемы необходимо изменить настройку hosts в файле /etc/nsswitch.conf на клиенте Fedora.

sudo nano /etc/nsswitch.conf

Параметр hosts по умолчанию устанавливается следующим образом:

hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname mymachines

Сохраните изменения в файле и закройте его. Теперь RPZ должен функционировать.

Применение RPZ в сочетании с форвардерами

В случае добавления директивы forwarders в секцию options файла /etc/bind/named.conf.options, ваш резолвер BIND будет настроен как форвардер, который будет отправлять DNS-запросы на верхний DNS-резолвер, например, 8.8.8.8.

options < directory "/var/cache/bind"; // Если между вами и DNS-серверами есть брандмауэр, // возможно, вам потребуется настроить брандмауэр для разрешения // работы нескольких портов. Смотрите http://www. kb. cert. org/vuls/id/800113 // Если ваш ISP предоставил один или несколько IP-адресов для стабильных // DNS-серверов, вы, вероятно, захотите использовать их в качестве форвардеров. // Раскомментируйте следующий блок и вставьте адреса, заменив // все нули на реальные. forwarders < 8.8.8.8; 8.8.4.4; >; . >;

Зона ответов политики функционирует с этой конфигурацией форвардера. Сначала BIND будет проверять локальную зону ответов политики. Если в RPZ не удастся найти DNS-запись, запрос будет отправлен к вышестоящему DNS-резолверу. Вы можете применить форвардер для ускорения процесса разрешения DNS, если ваш собственный резолвер BIND затрачивает слишком много времени на обработку DNS-имен.

Настройка области передачи.

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

Для начала необходимо внести изменения в файл /etc/bind/named.conf.local на основном DNS-резолвере.

sudo nano /etc/bind/named.conf.local

Включите IP-адрес слейв-резолвера DNS в параметр allow-transfer.

zone "rpz. local" < type master; file "/etc/bind/db. rpz. local"; allow-query < localhost; >разрешить передачу< 12.34.56.78; >Также уведомить< 12.34.56.78; >; >;

Если у вас имеется несколько слейв-резолверов DNS, добавьте несколько IP-адресов, как указано ниже.

allow-transfer < 12.34.56.78; 12.34.56.79; >;

Директива also-notify обеспечит отправку уведомления слейв-резолверу от главного резолвера DNS в случае изменения зоны RPZ. Не забудьте сохранить файл и закрыть его. Затем перезапустите BIND, чтобы изменения начали действовать.

sudo systemctl restart bind9

Если на основном DNS-резолвере установлен брандмауэр, необходимо разрешить слейв-резолверу доступ к порту 53. К примеру, при использовании брандмауэра UFW выполните следующую команду.

sudo ufw insert 1 allow in from 12.34.56.78 to any port 53

Затем внесите изменения в файл named.conf.options на DNS-слейв-резолвере.

sudo nano /etc/bind/named.conf.options

Включите указанные строки в раздел options.<. >Чтобы добавить область политик ответов.

//включить зону политик ответов. response-policy < zone "rpz. local"; >;

Сохраните файл и закройте его. После этого внесите изменения в файл named.conf.local.

sudo nano /etc/bind/named.conf.local

Включите слейв-зону RPZ в данный файл. Замените 11.22.33.44 на IP-адрес основного DNS-резолвера.

zone "rpz. local" < type slave; file "db. rpz. local"; masters < 11.22.33.44;>разрешить-уведомления< 11.22.33.44; >разрешить передачу< none; >Разрешить запросы.< localhost; >; >;

Сохраните файл и закройте его.

Необходимо также сконфигурировать брандмауэр слейв-резолвера для того, чтобы главный резолвер DNS мог отправлять уведомления.

sudo ufw insert 1 allow in from 11.22.33.44 to any port 53

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

sudo named-checkconf

Если ошибок не обнаружено, перезапустите BIND9.

sudo systemctl restart bind9

После перезапуска BIND9 начнется процесс передачи зон. Для проверки журнала BIND9 воспользуйтесь следующей командой.

sudo journalctl - eu bind9

sudo journalctl - eu named

Вы можете встретить сообщения, подобные следующим, которые свидетельствуют о том, что передача зоны была успешной.

transfer of 'rpz. local/IN' from xx. xx. xx. xx#53: Transfer status: success transfer of 'rpz. local/IN' from xx. xx. xx. xx#53: Transfer completed: 1 messages, 34 records, 899 bytes, 0.248 secs (3625 bytes/sec)

Важно: При каждом изменении зоны RPZ на основном резолвере необходимо обновить серийный номер. Увеличьте его, чтобы слэйв-резолверы могли узнать о произошедших изменениях в зоне RPZ.

Формирование нескольких областей RPZ.

В некоторых случаях может возникнуть необходимость ограничить передачу определённых DNS-записей слейв-резолверам. Для этого можно настроить отдельную зону RPZ. Необходимо внести изменения в файл named.conf.options.

sudo nano /etc/bind/named.conf.options

Создайте новую зону RPZ.

//включить зону политик ответов. response-policy < zone "rpz. local"; zone "rpz. local. notransfer"; >;

Примечание: В случае конфликта DNS-записей между двумя зонами RPZ приоритет будет отдан первому значению. Чтобы изменить порядок приоритета, достаточно поменять их местами, как указано ниже:

//включить зону политики ответов. response-policy < zone "rpz. local. notransfer"; zone "rpz. local"; >;

Сохраните изменения и закройте файл. После этого откройте файл с именем named.conf.local.

sudo nano /etc/bind/named.conf.local

Включите описание новой зоны в данный файл.

zone "rpz. local. notransfer" < type master; file "/etc/bind/db. rpz. local. notransfer"; allow-query < localhost; >разрешить передачу< localhost; >; >;

Сохраните файл и закройте его. Далее необходимо создать файл зоны. Вместо того чтобы создавать его с нуля, можно воспользоваться шаблонным файлом зоны. Скопируйте данные из db. empty в новый файл.

sudo cp /etc/bind/db. empty /etc/bind/db. rpz. local. notransfer

После этого внесите изменения в файл db. rpz и добавьте записи DNS для пользователей.

sudo nano /etc/bind/db. rpz. local. transfer

Рекомендации по диагностике проблем

Если вторичный DNS-резолвер не в состоянии скопировать записи RPZ из первичного DNS-резолвера, возможно, на вторичном DNS-резолвере:

• Правила брандмауэра составлены неверно.
• Резолвер BIND не функционирует.
• BIND не принимает запросы на нужном сетевом интерфейсе.

Использование RPZ с представлениями в BIND.

Чтобы ограничить доступ к вашей RPZ исключительно для внутренних доверенных сетей, вы можете воспользоваться представлениями в BIND. Данная конфигурация будет совместима с передачей зон мастер-слейв.

Первым делом внесите изменения в файл named.conf.options.

sudo nano /etc/bind/named.conf.options

Настройте внутреннюю и гостевую сети с использованием директивы acl.

options < . . >внутренний acl< 10.10.10.0/24; >acl гость< 10.10.20.0/24; >;

Сеть 10.10.10.0/24 представляет собой внутреннюю доверенную сеть, в то время как 10.10.20.0/24 является гостевой сетью. Также необходимо исключить следующие строки из данного файла.

response-policy < zone "rpz. local"; >;

Сохраните файл и закройте его.

Затем внесите изменения в файл named.conf.local.

sudo nano /etc/bind/named.conf.local

Необходимо разместить определение зоны внутри блока представления, как показано ниже. Обратите внимание, что зона политики ответов должна быть включена в блок представления.

view "internal" < match-clients < internal; >Включите область, касающуюся политики ответов.< zone "rpz. local"; >зона "rpz. local"< type master; file "/etc/bind/db. rpz. local"; allow-query < localhost; >разрешить передачу< 12.34.56.78; >; >; >;

Сохраните файл и закройте его. После этого внесите изменения в файл named.conf.

sudo nano /etc/bind/named.conf.default-zones

Разместите стандартные области в представлении для гостей.

view guest < match-clients < guest; >Пожалуйста, предоставьте текст, который вы хотите, чтобы я перефразировал.< any; >К сожалению, вы не предоставили текст для перефразирования. Пожалуйста, укажите текст, который нужно изменить.< type hint; file "/usr/share/dns/root. hints"; >зона "localhost"< type master; file "/etc/bind/db. local"; >; . . >;

Сохраните и закройте документ. Затем выполните следующую команду, чтобы проверить конфигурационный файл на наличие синтаксических ошибок. Если вывод будет пустым, это значит, что ошибок нет.

sudo named-checkconf

Если ошибок не обнаружено, перезапустите BIND9 для применения изменений.

sudo systemctl restart bind9

Зона политики ответов больше не действительна.

Если в журнале слейв-сервера (sudo journalctl — eu named) вы обнаружите указанную ошибку, вероятно, это свидетельствует о том, что слейв-сервер не в состоянии установить соединение с мастер DNS-сервером.

zone rpz. local/IN: response-policy zone expired; policies unloaded

Заключение

Надеюсь, этот гид был полезен для настройки зоны ответов и DNS брандмауэра на системах Debian/Ubuntu. Если информация оказалась для вас полезной, не забудьте подписаться на нашу бесплатную рассылку для получения дополнительных советов и рекомендаций.