Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

Защита DNS: общие настройки.

Рубрика: Безопасность -> Защита сервисов
Метки: |
Вторник, 25 августа 2009 г.
Просмотров: 5855
Подписаться на комментарии по 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:

  options {

     version "unknown";

  }

     He надо использовать в качестве версии строку, привлекающую внимание крекера или провоцирующую его. Спровоцировать может, к примеру, строка «facki, xaker». Более уместной в качестве версии будет строка «unknown» или вообще пустая строка « ».

     Второй метод использует относительно новую для BIND концепцию видов (представлений). Виды (представления) дают возможность предоставлять пользователям различную информацию о зоне, основанную на их IP-адресе:

view "chaos" chaos { match-clients { ;};

allow-query { none; };

zone "." {

  type hint;

  file "/dev/null";

};

     Если использовать директиву view для ограничения chaos-запросов, то нужно употреблять ее для запросов зоны. В этом случае просто переопределяется вся информация о зоне внутри вида.

     Также можно указать, к каким пользователям относится данный вид. Это надо сделать с помощью директивы match-clients. Если будет только одно представление, то нужно установить значение any.

view "default" in {

match-clients { any; };

zone "example.com" IN {

  type master;

  file "zone.example.com";

  allow-update { none; }; };

  zone "example.org" IN { type master};

  file "zone.example.org"; allow-update { none; ); };

};

     Ограничение ресурсов.

     Как и Apache, BIND позволяет ограничивать употребление разных ресурсов. Опции ограничения ресурсов помещаются в блок options {}. Наиболее важными опциями являются:

  • Datasize <размер> - контролирует максимальный размер сегмента данных процесса. Если не задано единиц измерения, считается, что размер задан в байтах. Разрешено применения единиц к (килобайт), m (мегабайт) или g (гигабайт).
  • Stacksize <размер> - максимальный размер стека.
  • Coresize <размер> - максимальный размер файла core, который генерируется при крахе демона named (core-файлы изрядно большие, поэтому лучше их ограничить).
  • Files <число> - максимальное число вместе открытых файлов.

    К примеру:

options {

   coresize 5m;

   files 50;

};

     Передача зоны.

     Первичные (авторитетные) серверы домена (зоны) должны периодически синхронизировать свои записи с вторичными серверами имен. Этот процесс называется передачей зоны. Этот процесс нуждается в жестком контролировании: первичный сервер имен должен принимать запросы на трансфер зоны только от своих вторичных серверов, а вторичные серверы должны принимать данные только от своего первичного сервера.

     Первичный сервер не должен принимать входящие передачи от какой угодно другой машины, то же самое и со вторичными серверами: только от первичного сервера - и все. Но по умолчанию BIND разрешает входящие/исходящие передачи с любого узла. Это надо исправить.

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

options {

allow-transfer { 10.0.0.7; 10.0.0.8;};

     На каждом вторичном сервере нужно указать первичный сервер (master) и запретить передачу зоны другим узлам:

options {

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-адресов, разделенных точкой с запятой или поле для отключения функции. Примеры:

zone "example.com" IN {

  type master;

  file "zone.exaraple.com"; allow-update { none; };

};

options {

  allow-update { 192.168.7.1; 192.168.34.7 ;} ;

}

     Надо иметь в виду, что DNS-трафик передается с помощью UDP, где подделать IP-адрес очень просто. Поэтому защита, основанная на IP - небезопасна, позже будут рассмотренны альтернативные решения.

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена.

Если вы уже зарегистрированы как комментатор или хотите зарегистрироваться, укажите пароль и свой действующий email.
(При регистрации на указанный адрес придет письмо с кодом активации и ссылкой на ваш персональный аккаунт, где вы сможете изменить свои данные, включая адрес сайта, ник, описание, контакты и т.д.)



(обязательно)