Захист сервера DNS — Налаштування безпеки

Защита серверу 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 internet 323.111.200.11.

jersild 323.111.200.25 comp1 323.111.200.1 comp3 323.111.200.3 parasit3 323.111.200.20.

internet 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:

mkdirp /root-dns mkdirp /root-dns/etc mkdirp /root-dns/var/run/named.

mkdirp /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.

chownR named. named /root-dns/var/named/*.

Нам ще знадобиться файл localtime для правильної роботи серверу DNS зі временем:

cp /etc/localtime.

/root-dns/etc/.

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

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

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

Удалим каталоги /var/named і /var/run/named — вони нам большє нє нужны:

rmrf /var/named/ rmrf /var/run/named/.

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

ROOTDIR= «/root-dns/ «.

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

service named start.

Выполните команду p. sax | grep named. Якщо ви і побачите приблизно следующее:

? P. S 0:00 namedu namedt /root-dns/ 5381? P. S 0:00 namedu namedt /root-dns/.

5382? P. S 0:00 namedu namedt /root-dns/ 5383? P. S 0:00 namedu namedt /root-dns/.

значит, ви все зробили правильно.

Мы запустили сервер DNS в chroot-окружении, але цьому дана стаття не закінчується. У дев’ятій версії BIND з’явилася можливість створювати підписи транзакцій (TSIG — Transaction SIGnatures). Механізм TSIG працює так: сервер отримує повідомлення, підписаний ключем, потім підпис перевіряється, якщо вона «правильна », сервер відправляє відповідь, підписаний тим самим ключом.

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

Итак, приступимо до настроюванні. Зупинимо сервіс named, коли він запущено:

service.

named stop.

Сгенерируем загальні ключі кожної пари вузлів. Загальні ключі використовуються при «спілкуванні «первинного і вторинного серверів DNS.

[root@dns]# dnssec-keygena hmac-md5 -b 128 -n HOST ns1-ns2 Kns1-ns2.+157+49 406.

Мы використовуємо алгоритм HMAC-MD5, 128-битное шифрування, ns1-ns2 — це ключа. По виконанні цієї команди буде створено файл Kns1-ns2.+176+40 946.private. Відкрийте їх у будь-якому текстовому редакторі. Ви побачите приблизно таке:

Private-key-format:

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

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

rmf Kns1-ns2.+157+49 406.key rmf Kns1-ns2.+157+49 406.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.

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

Для підготовки даної роботи було використані матеріали із російського сайту internet.