Защита DNS: общие настройки.
Метки: DNS | UDP
Вторник, 25 августа 2009 г.
Просмотров: 2124
Подписаться на комментарии по RSS
Сервер имен BIND стал стандартом де-факто на DNS-серверы, иногда слово BIND применяется как синоним DNS. BIND применяется повсюду: и в маленькой сети с выходом в Интернет, и в немалой корпоративной закрытой сети, и в сети интернет-провайдера...
Также BIND прославился в плане уязвимостей. Подробное описание всех исправленных багов во всех версиях BIND доступно по адресу:
http://www.isc.org/sw/bind/bind-security.php
Версия BIND.
Если используется BIND версии 4.9 или более поздней, его версию удаленный пользователь может получить с помощью запроса:
dig @example.com txt chaos version.bind
Это знает не каждый пользователь, но будьте уверены - крекер, атакующий систему, это точно знает. Получения версии BIND недопустимо с точки зрения безопасности. Если крекер узнает версию BIND, все, что ему останется сделать, - это подобрать правильный эксплоит, и дело будет сделано. Чтобы BIND не отправлял версию в ответ на вышеприведенный вопрос, нужно поместить директиву version в блок options файла конфигурации /etc/named.conf:
version "unknown";
}
He надо использовать в качестве версии строку, привлекающую внимание крекера или провоцирующую его. Спровоцировать может, к примеру, строка «facki, xaker». Более уместной в качестве версии будет строка «unknown» или вообще пустая строка « ».
Второй метод использует относительно новую для BIND концепцию видов (представлений). Виды (представления) дают возможность предоставлять пользователям различную информацию о зоне, основанную на их IP-адресе:
allow-query { none; };
zone "." {
type hint;
file "/dev/null";
};
Если использовать директиву view для ограничения chaos-запросов, то нужно употреблять ее для запросов зоны. В этом случае просто переопределяется вся информация о зоне внутри вида.
Также можно указать, к каким пользователям относится данный вид. Это надо сделать с помощью директивы match-clients. Если будет только одно представление, то нужно установить значение any.
};
Ограничение ресурсов.
Как и Apache, BIND позволяет ограничивать употребление разных ресурсов. Опции ограничения ресурсов помещаются в блок options {}. Наиболее важными опциями являются:
- Datasize <размер> - контролирует максимальный размер сегмента данных процесса. Если не задано единиц измерения, считается, что размер задан в байтах. Разрешено применения единиц к (килобайт), m (мегабайт) или g (гигабайт).
- Stacksize <размер> - максимальный размер стека.
- Coresize <размер> - максимальный размер файла core, который генерируется при крахе демона named (core-файлы изрядно большие, поэтому лучше их ограничить).
- Files <число> - максимальное число вместе открытых файлов.
К примеру:
files 50;
};
Передача зоны.
Первичные (авторитетные) серверы домена (зоны) должны периодически синхронизировать свои записи с вторичными серверами имен. Этот процесс называется передачей зоны. Этот процесс нуждается в жестком контролировании: первичный сервер имен должен принимать запросы на трансфер зоны только от своих вторичных серверов, а вторичные серверы должны принимать данные только от своего первичного сервера.
Первичный сервер не должен принимать входящие передачи от какой угодно другой машины, то же самое и со вторичными серверами: только от первичного сервера - и все. Но по умолчанию BIND разрешает входящие/исходящие передачи с любого узла. Это надо исправить.
На первичном узле можно задать список узлов, которым допускается совершать запросы на передачу зоны - это будут вторичные серверы имен:
allow-transfer { 10.0.0.7; 10.0.0.8;};
На каждом вторичном сервере нужно указать первичный сервер (master) и запретить передачу зоны другим узлам:
masters { 10.0.0.1; }
allow-transfer { none; } };
В этом случае 10.0.0.1 — это первичный сервер.
Динамические обновления.
В 8-й версии BIND появилась новая функция - динамические обновления (dynamic updates), подробно описанная в RFC 2136. Динамические обновления позволяют удаленному пользователю (с помощью команды nsupdate) добавлять и удалять записи с зоны, для которой сервер представляется авторитетным.
Такая гибкость очень полезна для сервисов вроде DHCP, разрешая им обновлять файлы зон для внесения данных о динамически распределенных IP-адресах. Но данная функция может тоже применяться как приглашение для хакера, поэтому нужно строго ограничить узлы, которым допускается производить динамические обновления, а еще лучше - отключить эту функцию.
Динамические обновления контролируются опцией allow-update, которая помещается в блок zone «имя зоны» или в блок options. В первом случае она используется только для явственной зоны, а во втором - глобально для всего сервера. В качестве параметров данной опции можно указать список IP-адресов, разделенных точкой с запятой или поле для отключения функции. Примеры:
type master;
file "zone.exaraple.com"; allow-update { none; };
};
options {
allow-update { 192.168.7.1; 192.168.34.7 ;} ;
}
Надо иметь в виду, что DNS-трафик передается с помощью UDP, где подделать IP-адрес очень просто. Поэтому защита, основанная на IP - небезопасна, позже будут рассмотренны альтернативные решения.