Захист DNS-сервера - Налагодження безпеки

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

Конфігуріруя сервер, адміністратори часто забувають правильно настроїти DNS. Після такого налаштування служба DNS працює коректно: IP-адреси вирішуються в імена комп'ютерів, а символьні імена без проблем перетворюються в IP-адреси. На цьому більшість адміністраторів і зупиняються: головне, щоб працювало. Працювати-то воно працює, але неправильно налаштований 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 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

Примітка. Щоб не було непорозумінь, вказані неіснуючі IP-адреси

Щоб не сталося непоправного, дозвольте передачу зону тільки одного комп'ютера -- вторинного DNS-сервера вашої компанії, якщо такий, звичайно, є. У файлі конфігурації сервісу named -/etc/named.conf - змініть секцію options наступним чином:

options (

allow-transfer (192.168.1.2;););

Вторинний DNS-сервер, як правило, не передає ніякої інформації про зону, тому обов'язково вкажіть такий рядок у його файлі конфігурації/etc/named.conf (в секції options):

allow-transfer

( none;)

Якщо у вас немає вторинного DNS-сервера, додайте вищезгадану рядок у файл конфігурації основного DNS-сервера.

Як будь-який хороший адміністратор, ви хочете, щоб ваш DNS-сервер швидко обслуговував запити клієнтів. Але до вашого сервера можуть підключатися користувачі не з вашої мережі, наприклад, з мережі конкуруючого провайдера. Тоді вас сервер буде обслуговувати "чужих" клієнтів. Непорядок! Опція allow-query дозволяє вказати адреси вузлів і мереж, яким можна використовувати наш 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-сервер повідомляти не номер своєї версії, а довільне повідомлення:

version

"Made in USSR ";

Всі вищеперелічені опції повинні бути вказані в секції options файлу конфігурації named.conf:

options (allow-query

(192.168.1.0/24; localhost;); allow-recursion (192.168.1.0/24; localhost;);

allow-transfer (192.168.1.2;); version "Made in USSR";)

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

Відразу потрібно сказати, що настроювати chroot-оточенні ми будемо для дев'ятій версії BIND, оскільки це значно простіше, ніж для восьмий версії. На відміну від восьмий версії, де для налаштування chroot-оточення потрібно було копіювати все бінарні файли або бібліотеки, необхідні для запуску BIND, для роботи дев'ятого версії достатньо скопіювати тільки файли конфігурації і зон, що обслуговуються сервером.

Почнемо настроювати 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

Перемістивши файл конфігурації 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-сервера з часом:

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 - вони нам більше не потрібні:

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 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 з'явилася можливість створювати підпису транзакцій (TSIG - Transaction SIGnatures). Механізм TSIG працює так: сервер отримує повідомлення, підписане ключем, потім підпис перевіряється, якщо вона "правильна", сервер відправляє відповідь, підписаний тим же ключем.

Механізм TSIG дуже ефективний при передачі інформації про зону, повідомлень про зміну зони і рекурсивних повідомлень. Погодьтеся, перевірка підпису надійніше, ніж перевірка IP-адреси. Зловмисник може вивести вторинний сервер DNS банальної атакою на відмову, і, поки адміністратор буде "піднімати" вторинний сервер, він замінить свою IP-адресу адресою вторинного сервера. При використанні TSIG завдання зловмисника значно ускладнюється: адже йому доведеться "підібрати" 128-бітний MD5-ключ, а ймовірність такого підбору прагне до нуля.

Отже, приступимо до налаштування. Зупинимо сервіс 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 - це ім'я ключа. Після виконання цієї команди буде створено файл Kns1-ns2. +176 +40946. Private. Відкрийте його в будь-якому текстовому редакторі. Ви побачите приблизно наступне:

Private-key-format:

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

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

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 hmac-md5;

secret "ms7dfts87Cjhj7FD9lk7a3 ==";);

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

Лістинг 1. Фрагмент файла named.conf первинного DNS-сервера

key ns1-ns2 (algorithm hmac-md5; secret "ms7dfts87Cjhj7FD9lk7a3 ==";); # прописуємо

вторинний 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 (

# нікому не передаємо зону allow-transfer (none);? );?.

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

allow-transfer (192.168.1.2;);

рядком

allow-transfer (key ns1-ns2;);

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

chmod 600 named.conf

Запускаємо сервіс named:

service named start

Тепер про безпеку вашого BIND подбає TSIG.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.soch.imperium.by