Защита сервера DNS - Настройка безопасности - реферат

Денис Колисниченко

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

До этого, чем приступить к взлому сети либо отдельной системы злодей (либо группа злоумышленников) пробует собрать как можно больше инфы: имена компов сети, имена юзеров, версии установленного программного обеспечения. Целой кладовой полезной для взломщика инфы станет некорректно настроенная Защита сервера DNS - Настройка безопасности - реферат служба DNS (BIND). Разглядим маленький пример: запустите программку nslookup и введите команду:

ls server.com

Если админ запамятовал верно настроить трансфер зоны, то кто угодно получит перечень компов нашей сети:

[comp2.server.com] server.com. 323.111.200.2

server.com. server = comp1.server.com server.com. server = comp2.server.com Защита сервера DNS - Настройка безопасности - реферат server.com.

server = comp3.server.com mail 323.111.200.17 gold 323.111.200.22 www.ie 323.111.200.11

jersild 323.111.200.25 comp1 323.111.200.1 comp3 323.111.200.3 parasit3 323.111.200.20

www.press 323.111.200.30 comp1 323.111.200.1 www 323.111.200.2

Примечание. Чтоб не было недоразумений, указаны несуществующие Айпишники

Чтобы не случилось неисправимого, разрешите передачу зону только одному компу - вторичному серверу DNS вашей компании, если таковой, естественно, имеется. В файле конфигурации сервиса named - /etc Защита сервера DNS - Настройка безопасности - реферат/named.conf - измените секцию options последующим образом:

options{

allow-transfer { 192.168.1.2; }; };

Вторичный сервер DNS, обычно, не передает никакой инфы о зоне, потому непременно укажите последующую строчку в его файле конфигурации /etc/named.conf (в секции options):

allow-transfer

{ none; }

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

Как хоть какой неплохой админ, вы желаете, чтоб ваш сервер DNS стремительно обслуживал запросы клиентов. Но к вашему серверу могут подключаться юзеры не из вашей сети, к примеру, из сети конкурирующего провайдера. Тогда вас сервер будет обслуживать "чужих" клиентов. Непорядок! Функция allow-query позволяет Защита сервера DNS - Настройка безопасности - реферат указать адреса узлов и сетей, которым можно использовать наш сервер DNS:

allow-query { 192.168.1.0/24; localhost; };

В данном примере мы позволяем использовать наш сервер узлам из сети 192.168.1.0 и узлу localhost. Целенаправлено разрешить рекурсивные запросы только из сети 192.168.1.0 и узлу localhost:

allow-recursion { 192.168.1.0/24; localhost; };

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

version

"Мейд in USSR";

Все перечисленные выше функции должны быть указаны в секции options файла конфигурации named.conf:

options { allow-query

{ 192.168.1.0/24; localhost; }; allow Защита сервера DNS - Настройка безопасности - реферат-recursion { 192.168.1.0/24; localhost; };

allow-transfer { 192.168.1.2; }; version "Мейд in USSR"; }

Из суждений безопасности рекомендуется запускать все сетевые сервисы в так именуемом chroot-окружении. На данный момент объясню, что же все-таки это такое. Создается файловая система, повторяющая структуру корневой файловой системы, но на этой файловой системе будут только те файлы, которые Защита сервера DNS - Настройка безопасности - реферат нужны для пуска нашего сетевого сервиса. Взломав сетевой сервис и получив доступ к корневой файловой системе, злодей не сумеет разрушить всей системе в целом, так как он получит доступ только к файлам, которые принадлежат данному сетевому сервису. Одни сетевые сервисы могут работать в chroot-окружении, а другие - нет Защита сервера DNS - Настройка безопасности - реферат. Сервис BIND как раз относится к первой группе. Сейчас разберемся, как все это организовывается. Вам не надо создавать отдельный раздел на диске для каждого сетевого сервиса: необходимо только сделать каталог, к примеру, root-dns, в который вы скопируете все файлы, нужные для пуска сервера DNS. Позже, при запуске сервиса Защита сервера DNS - Настройка безопасности - реферат, будет выполнена команда chroot для этого сервиса, которая подменит файловую систему. А потому что в каталоге root-dns, который станет каталогом /, имеются все нужные файлы для работы bind, то для сервиса пуск и работа в chroot-окружении будет совсем прозрачным.

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

Начнем настраивать chroot-окружение для нашего сервера DNS. Сделаем сборники корневой файловой системы сервера DNS - root-dns:

mkdir -p /root-dns mkdir -p /root-dns/etc mkdir -p /root-dns/var/run/named

mkdir -p /root-dns/var/named

Остановим сервер DNS, если он запущен:

service named stop

Переместим файл конфигурации Защита сервера DNS - Настройка безопасности - реферат named.conf и файлы зон в каталог /root-dns:

mv /etc/named.conf /root-dns/etc/

mv /var/named/* /root-dns/var/named/ chown named.named /chroot/etc/named.conf

chown -R named.named /root-dns/var/named/*

Нам еще пригодится файл localtime для правильной работы сервера DNS с Защита сервера DNS - Настройка безопасности - реферат течением времени:

cp /etc/localtime

/root-dns/etc/

Защитим от редактирования и удаления файл конфигурации named.conf:

chattr +i /root-dns/etc/named.conf

Примечание. Не забудьте снять атрибут "i" перед редактированием файла конфигурации (chattr -i /root-dns/etc/named.conf)

Удалим сборники /var/named и /var/run/named - они нам Защита сервера DNS - Настройка безопасности - реферат больше не необходимы:

rm -rf /var/named/ rm -rf /var/run/named/

Добавим в файл /etc/sysconfig/named строчку:

ROOTDIR="/root-dns/"

Все, сейчас можно запустить сервер named:

service named start

Сделайте команду ps -ax | grep named. Если вы увидите приблизительно последующее:

5380

? S 0:00 named -u named -t /root-dns/ 5381 ? S Защита сервера DNS - Настройка безопасности - реферат 0:00 named -u named -t /root-dns/

5382 ? S 0:00 named -u named -t /root-dns/ 5383 ? S 0:00 named -u named -t /root-dns/

означает, вы все сделали верно.

Мы запустили сервер DNS в chroot-окружении, но на этом данная статья не завершается. В девятой версии BIND появилась возможность создавать подписи транзакций Защита сервера DNS - Настройка безопасности - реферат (TSIG - Transaction SIGnatures). Механизм TSIG работает так: сервер получает сообщение, подписанное ключом, потом подпись проверяется, если она "верная", сервер посылает ответ, подписанный этим же ключом.

Механизм TSIG очень эффективен при передаче инфы о зоне, извещений об изменении зоны и рекурсивных сообщений. Согласитесь, проверка подписи надежнее, чем проверка Айпишника. Злодей может Защита сервера DNS - Настройка безопасности - реферат вывести вторичный сервер DNS очевидной атакой на отказ, и, пока админ будет "поднимать" вторичный сервер, он поменяет собственный Айпишник адресом вторичного сервера. При использовании TSIG задачка злодея существенно усложняется: ведь ему придется "подобрать" 128-битный MD5-ключ, а возможность такового подбора стремится к нулю.

Итак, приступим к настройке. Остановим сервис Защита сервера DNS - Настройка безопасности - реферат named, если он запущен:

service

named stop

Сгенерируем общие ключи для каждой пары узлов. Общие ключи применяются при "общении" первичного и вторичного серверов DNS.

[root@dns]# dnssec-keygen -a hmac-md5 -b 128 -n HOST ns1-ns2 Kns1-ns2.+157+49406

Мы используем метод HMAC-MD5, 128-битное шифрование, ns1-ns2 - это имя Защита сервера DNS - Настройка безопасности - реферат ключа. После выполнения этой команды будет сотворен файл Kns1-ns2.+176+40946.private. Откройте его в любом редакторе текста. Вы увидите приблизительно последующее:

Private-key-format:

v1.2 Algorithm: 157 (HMAC_MD5) Key: ms7dfts87Cjhj7FD9lk7a3==

Ключ "ms7dfts87Cjhj7FD9lk7a3==" и будет тем секретом, который будет Защита сервера DNS - Настройка безопасности - реферат передаваться меж серверами. Запишите данный ключ на бумаге (которую позже необходимо будет убить) и удалите файлы:

rm -f Kns1-ns2.+157+49406.key rm -f Kns1-ns2.+157+49406.private

Добавим в файл /etc/named.conf (либо /root-dns/etc/named.conf) первичного и вторичного серверов DNS последующие строчки:

key ns1-ns2 { algorithm Защита сервера DNS - Настройка безопасности - реферат hmac-md5;

secret "ms7dfts87Cjhj7FD9lk7a3=="; };

Укажем серверу BIND использовать ключ ns1-ns2. Для этого в файле named.conf первичного сервера DNS добавим опцию server:

Листинг 1. Кусок файла named.conf первичного сервера DNS

key ns1-ns2 { algorithm hmac-md5; secret "ms7dfts87Cjhj7FD9lk7a3=="; }; # прописываем

вторичный сервер Защита сервера DNS - Настройка безопасности - реферат DNS - 192.168.1.2: server 192.168.1.2 { keys { ns1-ns2; }; };

options { # разрешаем передачу зоны вторичному серверу DNS allow-transfer { 192.168.1.2;

}; ? }; ?. Листинг 2. Кусок файла named.conf ВТОРИЧНОГО сервера DNS key ns1-ns2

{ algorithm hmac-md5; secret "ms7dfts87Cjhj7FD9lk7a3=="; }; # прописываем первичный

сервер DNS - 192.168.1.1: server 192.168.1.1 { keys { ns1-ns2; }; }; options {

# никому не передаем зону Защита сервера DNS - Настройка безопасности - реферат allow-transfer { none }; ? }; ?.

Можно также настроить передачу зоны "по ключу". Для этого в файле конфигурации первичного сервера DNS поменяйте строчку

allow-transfer { 192.168.1.2; };

строчкой

allow-transfer { key ns1-ns2; };

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

chmod 600 named.conf

Запускаем сервис named Защита сервера DNS - Настройка безопасности - реферат:

service named start

Сейчас о безопасности вашего BIND позаботится TSIG.


zashita-elektrodvigatelej-promishlennogo-naznacheniya-doklad.html
zashita-gornih-dorog-ot-snezhnih-lavin-snegozanosov-i-kamnepadov-kak-vozmozhnih-prichin-dtp.html
zashita-i-davnost-vladeniya.html