Response policy zones (rpz) на страже сети / хабр

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю ), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

Формирование ключей

Создаем каталог, в котором будем хранить ключи и сразу переходим в него.

На CentOS / Red Hat:

mkdir /var/named/keys

cd /var/named/keys

На Ubuntu / Debian:

mkdir /etc/bind/keys

cd /etc/bind/keys

* месторасположение каталога может быть любым. Если в системе активирован SELinux, необходимо также настроить контексты безопасности или отключить его.

Генерируем мастер ключ (KSK):

dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE -r /dev/urandom dmosk.ru

* где:

-f KSK — флаг, который говорит, что формируется мастер ключ.
-a RSASHA1 — используемый алгоритм шифрования.
-b 2048 — размер ключа в битах.
-n ZONE — для DNS-зоны.
-r /dev/urandom — путь к файлу со случайными данными. В различных версиях системы путь может отличаться. Если упустить этот ключ в CentOS, процесс генерации сертификата может зависнуть.
dmosk.ru — домен, для которого предназначен ключ.

* подробное описание ключей можно посмотреть командой dnssec-keygen -help или man dnssec-keygen.

Генерируем ключ для зоны (ZSK):

dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -r /dev/urandom dmosk.ru

Задаем владельца для сгенерированных файлов.

На CentOS / Red Hat:

chown -R named:named /var/named/keys

На Ubuntu / Debian:

chown -R bind:bind /etc/bind/keys

Автоматическое подписывание зоны

Каждый раз после редактирования зоны не очень удобно ее переподписывать командой dnssec-signzone.

Для автоматизации процесса в конфигурационном файле bind редактируем:

options {
…
key-directory «/var/named/keys»;
sig-validity-interval 20 10;
};

* где key-directory — каталог для хранения сгенерированных ключей, необходимо прописать тот, в котором мы формировали последние командой dnssec-keygen; sig-validity-interval — период действия ключей: дней / период обновления.

Для зоны редактируем:

zone «dmosk.ru» {
…
file «master/dmosk.ru»;
inline-signing yes;
auto-dnssec maintain;
};

* где inline-signing — включение или отключение прозрачного формирования подписей (без необходимости менять файл зоны); auto-dnssec — уровень автоматической настройки DNSSEC для зоны

Также обращаем внимание, что мы убрали в пути .signed

Проверяем, что у пользователя named/bind есть права на запись в каталог хранения зоны. При необходимости, меняем владельца, например:

chown -R named:named /var/named/master

Удаляем старый файл подписанной зоны:

rm -f /var/named/master/dmosk.ru.signed

Открываем на редактирование файл зоны и меняем серийный номер.

Перезапускаем bind.

На CentOS / Red Hat:

systemctl restart named

На Ubuntu / Debian:

systemctl restart bind

В каталоге зоны должны появиться дополнительные 3 файла: dmosk.ru.jbk, dmosk.ru.signed, dmosk.ru.signed.jnl

Готово. Проверяем настройку командой dig.

Общие сведения

Named – это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен. Демон named может реализовывать функции серверов любого типа: master, slave, cache. На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND. Бинарник, который выполняет основную работу, расположен в /usr/sbin/named. Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind. В основном конфиге описывается рабочий каталог асервера, зачастую это каталог /var/cache/bind, в котором лежат файлы описания зон и другие служебные файлы. Соответствиеназвания зоны и файла описания зоны задает раздел zone с параметром file. Раздел zoneтак же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров сборки сервера из исходников).

Эта общая схема работы, которая поможет в дальнейшем не запутаться, при рассмотрении конкретных конфигураций.

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND. Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Перенаправление пользователей на локальные ресурсы

для предупреждение пользователей, что их компьютеры заражены malware, botnet-агентами или при обращении к сайтам, которые распространяют вредоносное ПО. Дополнительно провайдеры могут показать рекламу антивируса, а администраторы на предприятиях указать телефон и email IT-службы;
для предупреждение пользователей, что данный ресурс заблокирован. Провайдеры могут указать причину блокировки (ФЗ), а для корпоративных пользователей можно вывести список заблокированных доменов и образец заявления по собственному желанию (для несогласных) ;
перенаправление пользователей на локальные ресурсы или локальные (серые) IP-адреса серверов (пример приведен в этой хабра-статье).

Создание файла зоны DNS

Дальнейшие примеры будут для Ubuntu/Debian, но также подходят и для Centos/RedHat, только директория с настройками зон в CentOS будет находиться в , а основной файл конфигурации . Для начала нам потребуется создать новый файл зоны для домена itproffi.ru. Перейдите в директорию . создайте в ней поддиректорию и перейдите в нее, выполнив следующую последовательность команд:

cd /etc/bind
mkdir -p zones/master
cd zones/master/

Директория будет содержать файл зоны для домена itproffi.ru. При желании можно использовать другую директорию. Файл зоны db.itproffi.ru будет содержать запись DNS, которая поможет серверу имен установить соответствие полного доменного имени IP-адресу. Создайте этот файл со следующим содержимым:

;
; Файл данных BIND для itproffi.ru
;
$TTL 3h
@ IN SOA ns1.itproffi.ru. admin.itproffi.ru. (
1 ; серийный номер
3h ; обновление каждые 3 часа
1h ; повторная попытка через час
1w ; срок годности – 1 неделя
1h ) ; хранение кэша отказов 1 час;
@ IN NS ns1.itproffi.ru.
@ IN NS ns2.itproffi.ru.

itproffi.ru. IN MX 10 mail.itproffi.ru.
itproffi.ru. IN A 172.31.1.10
ns1 IN A 172.31.1.10
ns2 IN A 172.31.1.11
www IN CNAME itproffi.ru.
mail IN A 172.31.1.10
ftp IN CNAME itproffi.ru.

Рассмотрим ключевые строки этого файла:

Запись SOA: авторитативный сервер имен для itproffi.ru – это ns1.itproffi.ru, адрес ответственного за зону DNS администратора – [email protected]
Записи NS: два сервера имен для зоны itproffi.ru – ns.itproffi.ru
Запись MX: почтовый сервер для itproffi.ru. Число 10 означает уровень приоритета
Записи A: A означает «адрес» (address). Другими словами, ns1 в зоне itproffi.ru будет иметь адрес 172.31.1.10
Запись CNAME (Canonical Name – каноническое имя): привязывает одно доменное имя к другому (каноническому), например, устанавливает соответствие mail.itproffi.ru и itproffi.ru.

Настройка файла конфигурации bind

На данный момент у нас должно быть два файла:

/etc/bind/zones/master/db.itproffi.ru
/etc/bind/zones/master/db.172.31.1

Теперь требуется вставить имена обоих файлов зоны в файл конфигурации bind . Для этого добавьте в файл следующие строки:

zone "itproffi.ru" {
type master;
file "/etc/bind/zones/master/db.itproffi.ru";
};

zone "1.31.172.in-addr.arpa" {
type master;
file "/etc/bind/zones/master/db.172.31.1";
};

Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.

Замените следующий блок текста в файле named.conf.options:

// forwarders {
// 0.0.0.0;
// };

на блок текста с адресом стабильного DNS-сервера

forwarders {
8.8.4.4;
};

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

listen-on port 53 { any; };
allow-query { any; };

А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение

listen-on port 53 { 192.168.0.0/24; };
allow-query { 192.168.0.0/24; };

Если этого не сделать, то при попытке обращения к серверу с другого компьютера вы получите ошибку

Query refused

25.6.1. Обзор

По умолчанию во FreeBSD используется одна из версий программы BIND (Berkeley Internet Name Domain), являющейся самой распространенной реализацией протокола DNS. DNS — это протокол, при помощи которого имена преобразуются в IP-адреса и наоборот. Например, в ответ на запрос о www.FreeBSD.org будет получен IP-адрес веб-сервера Проекта FreeBSD, а запрос о ftp.FreeBSD.org возвратит IP-адрес соответствующей машины с FTP-сервером. Точно также происходит и обратный процесс. Запрос, содержащий IP-адрес машины, возвратит имя хоста. Для выполнения запросов к DNS вовсе не обязательно иметь в системе работающий сервер имён.

FreeBSD в настоящее время поставляется с сервером DNS BIND9, предоставляющим расширенные настройки безопасности, новую схему расположения файлов конфигурации и автоматические настройки для chroot(8).

В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, серверов доменов первого уровня (Top Level Domain, TLD) и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.

25.6.2. Используемая терминология

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

Термин	Определение
Прямой запрос к DNS (forward DNS)	Преобразование имён хостов в адреса IP
Ориджин (origin)	Обозначает домен, покрываемый конкретным файлом зоны
named, bind, сервер имён	Общеупотребительные названия для обозначения пакета BIND, обеспечивающего работу сервера имён во FreeBSD.
Резолвер	Системный процесс, посредством которого машина обращается к серверу имён для получения информации о зоне
Обратный DNS (reverse DNS)	Операция, обратная прямому запросу к DNS; преобразование адресов IP в имена хостов
Корневая зона	Начало иерархии зон Интернет. Все зоны находятся под корневой зоной, подобно тому, как все файлы располагаются ниже корневого каталога.
Зона	Отдельный домен, поддомен или часть DNS, управляемая одним сервером.

Примеры зон:

. является корневой зоной
org. — домен верхнего уровня (TLD) в корневой зоне.
example.org. является зоной в домене верхнего уровня (TLD) org..
1.168.192.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 192.168.1.*.

Настраиваем DNS сервер bind

Переходим в консоль root:

sudo -i

Установка bind

Сначала нам надо обновить систему:

dnf --refresh upgrade

Далее устанавливаем сам Bind:

dnf install bind

Пакет называется bind, а вот служба systemd называется named.

Настраиваем sytemd-resolved

В сервере ROSA 12 используется systemd-resolved в качестве резолвера dns. Если мы хотим настроить свой DNS сервер, то для этого, надо настроить systemd-resolved:

Посмотрим, кто у нас прослушивает 53 порт:

lsof -i :53

Открываем файл /etc/systemd/resolved.conf

Правим следующие строки:

DNS=127.0.0.1
FallbackDNS=
DNSSEC=no
LLMNR=resolve
DNSStubListener=no

где:

DNS=127.0.0.1 — это локальный ip адрес, на котором будет работать наш DNS сервер будущий
FallbackDNS= — оставляем пустым, чтобы systemd-resolved не переключался на fallback dns сервера
DNSStubListener=no — чтобы наш systemd-resolved не прослушивал порт 53

Остальные опции в этом файле, оставим как есть. Перезапускаем systemd-resolved:

systemctl restart systemd-resolved

Еще раз смотрим:

lsof -i :53

Если вывод пустой, значит всё нормально, можно приступать к настройке и запуску bind.

Базовая настройка bind

Пакет называется bind, но сервис называется named. И все конфигурационные файлы/сервисы будут называться на named

Основной конфигурационный файл: named.conf

Открываем этот конфигурационный файл named.conf и для минимальной работы DNS сервера, правим следующие строки:

options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { any; };
        . . . . .
        allow-query     { any; };

где:

listen-on port 53 { any; }; — ставим any для прослушивания на всех ip хоста
listen-on-v6 port 53 { any; }; — ставим any для прослушивания на всех ip хоста
allow-query { any; }; — разрешаем запросу отовсюду к нашему серверу

После правки конфигурационного файла, можем запустит наш bind:

systemctl start named.service

Смотрим кто у нас прослушивает 53 порт:

lsof -i :53

Если named, то все настроили правильно. Но мы проверили только то, что и кто слушает 53 порт.

Проверим как работает наш DNS сервер.

dig @127.0.0.1 yandex.ru

Или

nslookup yandex.ru

Должны быть выведены IP адреса yandex.ru.

Включаем наш DNS сервис в автозагрузку.

systemctl enable named.service

Настройка Forward DNS сервера bind

Чтобы настроить bind для перенаправления (forward) запросов к другим DNS серверам, сделаем следующее:

Открываем этот конфигурационный файл named.conf и для минимальной работы DNS сервера, правим/добавляем следующие строки:

options {
        . . . . .
        recursion yes;
        . . . . .
        forward only;
        forwarders {
                77.88.8.8;
                77.88.8.1;
        };

где:

forward — режим перенаправления
1. forward only; — если ставим only указывая, тем самым, что все запросы на наш DNS сервер будут перенаправляться на другие DNS сервера, прописанные в следующей опции forwarders {}
2. forward first; — если ставим first указывая, тем самым, что все запросы на наш DNS сервер будут перенаправляться на другие DNS сервера, прописанные в следующей опции forwarders {}, и если с помощью них не удастся разрешить запрос, то запрос будет пытать разрешаться нашим DNS сервером локально
forwarders { 77.88.8.8; 77.88.8.1; }; — список DNS серверов, для перенаправления запросов

Настройка кеширующего DNS сервера bind

Чтобы настроить bind как кеширующий сервер DNS, сделаем следующее:

Открываем этот конфигурационный файл named.conf и для минимальной работы DNS сервера, правим следующие строки:

acl my_allowed {
        192.168.100.0/24;
        217.71.222.0/24;
        localhost;
};
options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { any; };
        directory       "/var/named";
        . . . . .
        allow-recursion { my_allowed; };
        allow-query     { my_allowed; };
        allow-transfer { none; };
        recursion yes;
        . . . . .

где:

allow-recursion { my_allowed; }; — Определяет хосты, с которых разрешаются рекурсивные запросы
allow-query { my_allowed; }; — Указывает, каким хостам разрешено делать запросы у сервера DNS
allow-transfer { none; }; — Указывает, каким вторичным серверам разрешено делать запросы в нашей зоне.

После правки конфигурационного файла, запускаем наш DNS сервер:

systemctl start named.service

Тестирование сервера bind

Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):

dig @172.31.0.122 www.itproffi.ru

Теперь проверим обратную зону:

dig @172.31.0.122 -x 172.31.1.10

Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.

nslookup itproffi.ru 172.31.0.122

nslookup 172.31.1.10 172.31.0.122

DoT — DNS поверх TLS

TLS

MitM, или «человек посередине»: без шифрования промежуточная система, находящаяся между клиентом и авторитетным DNS-сервером, может потенциально отправить клиенту в ответ на запрос ложную или опасную информацию
Шпионаж и отслеживание: без шифрования запросов промежуточным системам легко просматривать, к каким сайтам обращается конкретный пользователь или приложение. Хотя из одного лишь DNS нельзя будет узнать конкретную посещаемую страницу на сайте, простого знания запрашиваемых доменов достаточно для формирования профиля системы или отдельного человека

University of California Irvine

Общая информация о BIND

BIND (Berkeley Internet Name Domain) — это опенсорсная реализация протокола DNS и DNS-сервера. Разработку поддерживает организация ISC (Internet Systems Consortium), цель которой — создавать эталонные решения в области ПО, нужного для функционирования интернета. Это один из наиболее распространенных DNS-серверов в интернете: «Википедия» гласит, что «10 из 13 корневых серверов DNS работают на BIND».

В состав BIND, помимо самого сервера DNS, входят библиотека DNS-резолвера и разные утилиты для управления сервером. Текущая, девятая ветка дистрибутива была релизнута аж в 2000 году. За это время было найдено огромное количество багов, и один из них мы сегодня разберем. Ему присвоены два бюллетеня с номерами CVE-2017-3142 и CVE-2017-3143.

Тестовый стенд

Чтобы в полной мере насладиться изучением проблемы, нужно эмулировать идеальные условия ее возникновения. Для этого по старинке возьмем Docker.

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

Первое, что нужно сделать после установки BIND, — это сконфигурировать новую зону в DNS-сервере. В этом нам поможет файл .

Создаем TSIG-ключ, даем ему произвольное имя и указываем алгоритм, который будет использоваться для генерации сигнатур при общении клиента с сервером DNS (и наоборот).

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

Далее настраиваем саму зону (я задал ) и определяем, для каких запросов нужно использовать валидацию через протокол TSIG и соответствующий ключ.

Помимо прочего, нам понадобится какой-нибудь сниффер, например tcpdump.

Если не хочешь со всем этим возиться, то просто скачивай готовый файл Docker из моего репозитория. В нем используется уязвимая версия BIND 9.10.5. Запускай скрипт , он сделает все необходимое, тебе останется только запустить сам сервер командой .

Go-go-go!

Информация об уязвимости

В начале июня 2017 года исследователи безопасности из компании Synacktiv обнаружили брешь в реализации протокола TSIG в BIND. Уязвимость позволяет атакующему, который знает название ключа TSIG, обойти проверку протокола и вычислять легитимную сигнатуру для произвольных сообщений к DNS-серверу.

Проблема заключается в том, что, когда клиент отправляет пакет, который содержит TSIG-дайджест заведомо неверной длины, в ответ сервер все равно вернет валидно подписанный пакет, используя переданный дайджест в качестве префикса. Это позволяет атакующему узнать сигнатуру валидного запроса и тем самым пройти проверки легитимности.

Сама уязвимость была протестирована в версиях BIND 9.9.10, 9.10.5 и 9.11.1. Однако ISC в бюллетене безопасности указывает, что уязвимы следующие версии продуктов:

от 9.4.0 до 9.8.8;
от 9.9.0 до 9.9.10P1;
от 9.10.0 до 9.10.5P1;
от 9.11.0 до 9.11.1P1;
от 9.9.3S1 до 9.9.10S2;
от 9.10.5S1 до 9.10.5S2.

Так что если ты счастливый обладатель одной из них, то скорее обновляйся.

Настройка RPZ на BIND 9.10

блокировать доступ к другим DNS;
автоматически перенаправлять все запросы на DNS с включенным механизмом RPZ.

given – выполняются действия определенные в зоне (значение по умолчанию);
disabled – зона отключена;
passthru – ответ DNS-сервера не модифицируется, но попадание в зону отражается в лог-файлах;
drop – сервер игнорирует запрос (не отвечает);
nxdomain – сервер отвечает NXDOMAIN (не существующий домен);
nodata – сервер отвечает NODATA (нет записи);
tcp-only – отсылается обрезанное сообщение, что вынуждает клиента выполнить запрос по TCP (защита от DrDoS);
cname domain-name – сервер переписывает все ответы на указанный домен.

Атаки на DNS

подмена DNS или «отравление» кэша: использование уязвимости системы для управления кэшем DNS с целью перенаправления пользователей в другое место
DNS-туннелирование: в основном используется для обхода средств защиты от удаленных подключений
перехват DNS: перенаправление обычного трафика DNS на другой целевой DNS-сервер путем изменения регистратора домена
атака NXDOMAIN: проведение DDoS-атаки на авторитетный сервер DNS путем отправки неправомерных доменных запросов для получения принудительного ответа
фантомный домен: заставляет DNS-преобразователь (DNS resolver) ждать ответа от несуществующих доменов, что приводит к снижению производительности
атака на случайный субдомен: взломанные хосты и ботнеты проводят DDoS-атаку на действующий домен, но сосредотачивают огонь на ложных субдоменах, чтобы принудить DNS-сервер выполнять поиск записей и захватить управление над службой
блокировка домена: представляет собой отправку множества спам-откликов для блокировки ресурсов DNS-сервера
ботнет-атака с абонентского оборудования: совокупность компьютеров, модемов, роутеров и других устройств, концентрирующих вычислительную мощность на определенном веб-сайте для его перегрузки запросами трафика

Протокол TSIG

TSIG (Transaction SIGnature) — это протокол, который обеспечивает идентификацию и целостность данных. Для этого в нем реализована технология подписи транзакций. Для всех запросов, ответов и прочих сообщений к DNS при помощи механизма проверки целостности информации (HMAC) высчитывается сигнатура на основе общего секретного ключа (shared key).

При правильно работающем механизме TSIG и сервер, и клиент добавляют TSIG в раздел дополнительных данных пакета с запросом к DNS. Тем самым они подтверждают, что обладают верным секретным ключом, что сообщение не изменилось по пути и ему можно доверять.

Протокол TSIG поддерживают все популярные серверы DNS, такие как NSD, PowerDNS, Knot и, разумеется, BIND.

WARNING

Вся информация носит только ознакомительный характер. Ни автор, ни редакция не несут ответственности за ее ненадлежащее использование.

Информация об уязвимости

от 9.4.0 до 9.8.8;
от 9.9.0 до 9.9.10P1;
от 9.10.0 до 9.10.5P1;
от 9.11.0 до 9.11.1P1;
от 9.9.3S1 до 9.9.10S2;
от 9.10.5S1 до 9.10.5S2.

Так что если ты счастливый обладатель одной из них, то скорее обновляйся.

Тестовый стенд

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

Помимо прочего, нам понадобится какой-нибудь сниффер, например tcpdump.

Go-go-go!

Общие детали

Для начала посмотрим, как выглядит легитимный запрос на zone transfer. Это делается утилитой dig, но сначала поставим tcpdump в режим мониторинга трафика DNS. Чтобы включить TSIG в запросах, нужно указать ключ с помощью опции . Формат такой: .

Снифаем трафик запроса AXFR

Поймалось несколько пакетов, давай посмотрим на них.

Пакет с ответом на AXFR-запрос

На скрине видно TSIG, который сгенерировал сервер на основе нашего ключа. Формат ответа описан в . Согласно спецификации все запросы при общении должны быть подписаны. Сама подпись генерируется на основе следующих компонентов:

размер MAC (Message authentication code, дайджест) запроса. Под него выделяется два байта;
MAC-запрос;
DNS-сообщение ответа;
ключ TSIG-ответа.

Далее в этой же RFC в указано, что если запрос вызвал ошибку и эта ошибка не имеет отношения непосредственно к TSIG, то в ответ должен улететь пакет с подписью, которая будет сгенерирована в соответствии с указанными выше параметрами.

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Использование

Удаленное управление Unbound

В составе unbound присутствует утилита которая позволяет удаленно контролировать сервер unbound. Команды схожи с пакета .

Настройка unbound-control

Перед тем, как начать, необходимо выполнить следующие шаги:

1) Для начала выполните следующую команду

# unbound-control-setup

которая сгенерирует пару самоподписанных сертификатов и ключей для сервера и клиента. Они будут находится в директории .

2) После, отредактируйте используя следующий пример. Опция обязательная, остальное можете настроить как необходимо вам.

remote-control:
    # Включает удаленный доступ с помощью unbound-control(8).
    # настройте ключи и сертификаты с помощью команды unbound-control-setup.
    control-enable: yes
   
    # Интерфейс, с которого будет происходить управление
    # задайте 0.0.0.0 и ::0 для прослушивания всех интерфейсов.
    control-interface: 127.0.0.1
   
    # номер порта для удаленного доступа.
    control-port: 8953
   
    # ключ unbound сервера.
    server-key-file: "/etc/unbound/unbound_server.key"
   
    # сертификат unbound сервера.
    server-cert-file: "/etc/unbound/unbound_server.pem"
   
    # ключ для unbound-control.
    control-key-file: "/etc/unbound/unbound_control.key"
   
    # сертификат для unbound-control.
    control-cert-file: "/etc/unbound/unbound_control.pem"

Использование unbound-control

Список команд, которые вы можете использовать для unbound-control:

выводит статистику не сбрасывая ее

 # unbound-control stats_noreset

выводит кеш в стандартный вывод

 # unbound-control dump_cache

Очищает кеш и перезагружает настройки

 # unbound-control reload

Обратитесь к для подробностей и поддерживаемых команд.

25.6.3. Причины, по которым вам может понадобиться сервер имён

Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён.

Авторитетный сервер имён нужен, когда:

нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно.
зарегистрирован домен, такой, как example.org и в этом домене требуется поставить имена машин в соответствие с их адресами IP.
блоку адресов IP требуется обратные записи DNS (IP в имена хостов).
резервный (slave) сервер имён должен отвечать на запросы.

Кэширующий сервер имён нужен, когда:

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

Зоны bind

Для возможности искать соответствия в собственной базе доменов, необходимо создать и настроить зоны. Существуют следующие типы зон:

Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind.
Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind.
Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.

Итог

Как видно, совсем не сложно разбить клиенты DNS на группы сетей или отдельные узлы и обрабатывать их запросы или перенаправлять вышестоящему DNS-серверу в зависимости от адреса, с которого пришел запрос. Чтобы наши клиенты НЕ СМОГЛИ использовать внешние DNS-серверы на выходном шлюзе, добавляем правило «Разрешить DNS-запросы в интернет от ваших DNS-серверов и запретить для всех остальных». Делается это из-за того, что есть знающие пользователи, которые меняют настройки на своих устройствах. Или просто заворачиваем все запросы на наш DNS. Следует отметить, что если используется прокси, то для его клиентов запросы будет обрабатывать прокси-сервер, это нужно учитывать.

Служба DNS не менее важна, чем DHCP и другие. При правильном подходе она помогает решить довольно большой круг задач. Игнорируя этот сервис, перекладывая все заботы на публичные DNS-серверы, администраторы лишают себя очень гибкого инструмента для работы с сетью. Так, например, можно снизить нагрузку на канал, если описать зоны с сервисами, находящимися в локальной сети и имеющими доступ из сети Интернет, чтобы внутренние клиенты ходили только по локальной сети, а клиенты внешние — через внешний канал соответственно. Когда число клиентов переваливает за сотню, это особенно ощутимо.