1. Введення

DNSSEC (DomainNameSystemSecurityExtensions)являє собою групу специфікацій з InternetEngineeringTaskForce(IETF), які забезпечують автентифікацію походження DNS (DomainNameSystem)даних, заперечення существованияданных при перевірці їх достовірності та цілісності (необеспечивает доступність і конфіденційність даних).

Метою DNSSEC є захист DNS посредствомиспользования цифрових підписів. DNSSEC за сутипредставляет собою зібрання нових компонентів, доданих у взаємодію між клієнтом і сервером DNS, яке допоможе підвищити безопасностьосновных протоколів DNS.

Коректне функціонування DNS є критично важливим для мережі підприємства, подсоединеннойк Інтернету, і для Інтернету в цілому. Дійсно,якщо зловмиснику вдасться зробити так, щоб атакується хост отримав з DNS сфальсифицированнуюинформацию, то хост буде відправляти дані на підроблений IP-адреса (InternetProtocol). У кращому случаерезультатом буде відмова в обслуговуванні, в гіршому —зловмисник отримає можливість перехоплення трафикасо усіма витікаючими наслідками.

Принцип роботи DNSSEC можна порівняти з цифровим підписом. Використовується два типи ключів, закрытымключом дані підписуються, а відкритим звіряються.Але головна відмінність у тому, що одним подписываетсязона (ZSK, zonesigningkey), іншим підписується наборключей (KSK, keysigningkey). Зроблено це з следующихсоображений: зона може бути досить великий,щоб вдалося підібрати закритий ключ ZSK, поэтомуего необхідно частіше міняти, і можна зробити його менеедлинным, щоб зони підписувалися швидше; відкритий ключ KSK використовується для невеликих объемовданных, тому його можна зробити довшим і режеизменять. Тим більше, що хеш від відкритої частини КЅКтребуется відправити в батьківську зону, що слишкомчасто робити не доцільно.

Вся інформація про захищеному домені системеDNSSEC певним чином зашифрована, поэтомуможет бути змінена тільки за допомогою закритого ключа шифрування. В процесі захищеного делегування домену генерується пара ключів. Інформація про ключі зберігається на первинному DNS-сервері.Закритий ключ використовується для підпису зони після кожної зміни. Цифровий підпис закрытогоключа (DS-запис) передається адміністратору батьківського зони і підписується його закритим ключем.Таким чином, організовується ланцюжок довіри. Знаяоткрытый ключ адміністратора батьківського зони,можна перевірити валідність відкритого ключа любойиз дочірніх зон.

Кожен вузол в дереві DNS пов’язаний з деяким відкритим ключем. Кожне повідомлення від DNS-серверовподписывается під відповідним закритим ключем.Ці ключі використовуються для генерації сертификатовили підписів, які зберігають идентификационныеданные про кожному домені верхнього рівня на відповідний відкритий ключ.

Такі криптографічні підпису обеспечиваютцелостность за рахунок обчислення криптографическогохэша (тобто унікальної контрольної суми) даних, потім, захисту обчисленої величини від несанкціонованих змін допомогою її шифрування.Хеш шифрується за допомогою особистого ключа з парыключей, щоб будь-який бажаючий міг воспользоватьсяоткрытым ключем для дешифрування. Якщо дешифрованное одержувачем хеш-значення збігається з чисельним, то дані достовірні (не подвергалисьнесанкционированному зміни).

Цифрові підписи зберігаються в зоні DNS в новыхзаписях ресурсів RRSIG (підпис запису ресурсу). Когдасопоставитель видає запит на ім’я, у відповіді повертаються одна або кілька RRSIG-записів. Для проверкиподписи використовується відкритий криптографическийключ, який зберігається в DNSKEY-запису ресурсу.В ході перевірки DNS-сервер витягає DNSKEY-запис.

KSK означає ключ підпису ключа (ключ довгострокового користування), а ZSK означає ключ подписизоны (ключ короткочасного користування).

У випадку асиметричної криптографії або шифрування з відкритим ключем, що використовується в DNSSEC,атакуючому необхідно визначити, за допомогою прямого перебору або інших методів, закриту половину в парі відкритий-закритий ключ, используемойдля створення підпису, що підтверджує достоверностьDNS-запису. Це дозволить йому обійти захист DNSSEC.DNSSEC запобігає ці спроби злому, используяключ короткочасного користування — ключ подписизоны (ZSK) — для регулярного обчислення подписейDNS-записів і ключ довготривалого користування —ключ підпису ключа (KSK) — для обчислення підпису ZSK, що дає можливість перевірки. Ключ ZSKчасто змінюється, щоб атакуючому було важче «вгадати», у той час, як більш довгий ключ КЅКизменяется набагато рідше (краще всього — раз у рік).Так як ключ KSK підписує ключ ZSK, который
подписывает DNS-записи, для перевірки DNS-записуу зоні необхідно знати тільки ключ KSK. Ключ КЅКв формі запису DelegationSigner (DS) передається вышепо дереву записів — батьківської зоні. Родительскаязона (наприклад, корінь) підписує дочірню записьDS (наприклад, .org) своїм ключем ZSK, який підписується своїм ключем KSK.

Це означає, що якщо DNSSEC повністю принялаключ KSK для кореневої зони, то вона стає частьюцепочки перевірки для кожного перевіряється доменногоимени DNSSEC (або розроблювального додатка).

2. Уразливості DNS

DNS-протокол може працювати як поверх TCP (TransmissionControlProtocol),так і поверх UDP (UserDatagramProtocol),причому в 99 % випадків используетсяименно UDP — як більш швидкий, менш вибагливий,але, водночас, і менш захищений. Щоб послатьподложный пакет, який буде сприйнятий жертвойкак правильний, досить вгадати (підібрати) ідентифікатор послідовності і номер порту-відправника.

У найпростішому випадку зловмисник може відправити підроблений DNS-відповідь з підробленими IP-адресомнекоторого вузла, на який жертва намагається зайти.Складність реалізації атак подібного роду в тому, чторабочие станції кешують DNS запити. Більш того,система не приймає DNS-відповідей, які не запитували. Хакер повинен дочекатися моменту, коли жертвапошлет DNS-запит, і згенерувати підроблений ответпрежде, ніж це зробить справжній DNS-сервер. Насамом справі, обидві проблеми мають рішення. DNS-кэшобычно невеликий, а тому, пославши жертві HTML-письмос купою картинок, що лежать на зовнішніх серверах з різними доменними іменами, хакер може витіснити изкэша всі старі записи. Після чого, остання ссылкав листі, ведуча на сервер оновлень, гарантированнопошлет позначений запит в Мережу. Предшествующаяей посилання на Web-сервер, підконтрольна хакеру, підкаже точний час, коли слід починати генерациюподложных пакетів. Якщо хоча б один з них будетвоспринят як правильний, DNS-кеш потрапить «лівий»адреса сервера з оновленнями, має всі шанси«дожити» до чергової сесії оновлень.Атаки на DNS можна умовно розділити на два види:

— Пасивні — атакуючий отримує необходимуюинформацию без помітного впливу на систему; система при цьому продовжує функціонувати какпрежде.

— Активні — атакуючий реалізує некотороевоздействие на систему, в результаті якого змінюється її поведінка. Така зміна може буття невизначним для атакується системи, але криптоаналітик в змозі визначити і использоватьэту інформацію.

3. Реалізація атак на DNS

Тестова середовище являє собою два сервера з розгорнутій операційній системою WindowsServer 2008R2и клієнтських ПК на базі windows xp. Тестированиезащиты DNS сервера проводиться шляхом организацииразного роду атак при стандартній захисту DNS сервера і додатково при розгорнутій системі захисту DNSSEC.

3.1. Приклад 1. Організація MITM-атак за допомогою«dsniff». Служба DNS використовує прості UDP-пакети,обмін якими відбувається через порт 53. Так какUDP є протоколом, не орієнтованим наустановление сполук, то можна підмінити інформацію його пакетів.

До складу пакету «dsniff» (http://www.monkey.org/~dugsong/dsniff), входить засіб під назвою «dnsspoof». Ця програма містить в собі простий аналізатор пакетів, який відслідковує запити DNSотносительно інформації записів «А» або «PTR». При використанні параметра -f, запушенная на комп’ютері хакера програма «dnsspoof» буде выполнятьчтение локального файлу, який записаний у стандарт-ному форматі /etc/hosts, і буде відповідати на всі перехоплені «А» або «PTR» DNS-запити.

testb$ host www.victim.com

www.victim.com address has 192.168.1.25

c rackerbox# cat /ete/dnssnifff.hosts

crackerbox# dnssniff -f /etc/dnssniff.hosts

testb$ host www.victim.com

www.victim.com address has 192.168.1.3

Якщо параметр -f не вказаний, відповіддю на всі «А»і «PTR» запити DNS буде IP-адресу або ім’я хоста,на якому запущена «dnsspoof». Це призведе до того,що всі запити на пошук IP-адрес будуть проходитьчерез хост порушника, тобто можна виконувати перехваттрафика, маршрутизацію або зміну даних, ще до того, як вони потраплять по дійсному адресуназначения.

Суть атаки полягає в тому, що якщо пакет від«dnsspoof» надійде раніше, ніж пакет від реальногоDNS-сервера, то перевагу отримає перший, фальшивий пакет, а дійсний відповідь буде відкинутий.Тому успіх роботи програми «dnsspoof» зависитот швидкості передачі пакета запит вузла. Таккак «dnsspoof» не потребує виконання пошуку дійсної інформації за запитом, то найімовірніше,що її пакет надійде першим.

3.2. Приклад 2. DNShijacking. Ця атака також частоиспользуется для зміни принципу роботи системDNS. В даному випадку не вноситься ніяких змін кеш DNS клієнта, але відбуваються зміни в настройках, після яких всі запити дозволу именадресуются особовому DNS-сервера зломщика. Обычноданная атака ставить своєю метою не викрадення даних, а збір статистичної інформації з компьютераклиента. Всі запити дозволу імен, відправляються сервера зломщика, виконуються коректно, але при цьому зломщик отримує інформацію про сайти, що відвідуються клієнтом.

Пакет для проведення атаки «DNSHijacker» являє собою поєднання sniffer& DNS spoofed.Розглянемо приклад проведення атаки.

1. Зловмисник запускає набір для проведенияатаки «DNSHijacker».

./dnshijacker —i eth0 —v —f ftable

2. Зловмисник прослуховує DNS запити вихідні від жертви до DNS серверу.

3. Жертва відправляє запит DNS сервера на отримання адреси www.ххххх.com.

13:59:20.042628 192.168.1.2732839 > 192.168.1.60.

domain: [udp sum ok] 24959+ A? www.ххххх.com [|domain](DF) (ttl 64, id 30800, len 61)

Запит містить у собі наступні частини:

1. 192.168.1.27: адресWeb-сайту.

2. 192.168.1.60: IP адреса внутрішнього DNS.

3. 24949:DNSID запиту відправленого жертвою навнутренний DNS.

4. (DF): Прапор.

5. Time to live64.

6. IPID 30800.

7. length61.

Внутрішній DNS сервер намагається обробити відповідь, не знаходячи запиту в свій базі, він посилає запроск вищестоящому DNS-сервера.

4. «Dnshijackertool» надсилає відповідь з подмененнойинформацией про IP адресу DNS сервера IP-адресезапрашиваемого ресурсу, до того як внутрішній DNSсервер отримає відповідь.Результатом цієї атаки є перенаправлениежертвы на підроблений веб-ресурс.

3.3. Приклад 3. Підміна DNS ID (DNS ID Spoofing).Заголовок пакета DNS-протоколу містить ідентифікаційне поле для відповідності запитів і відповідей.Метою підміни DNS ID є здійснення своєї відповіді на DNS-запит до того, як відповість настоящийDNS-сервер. ID — це єдиний спосіб различитьразличные запити DNS. Сервери DNS використовують ID,щоб визначити який був початковий запит.Для виконання цього, потрібно спрогнозувати ідентифікатор запиту. Локально це реалізується простымпрослушиванием мережевого трафіку, але віддалено виконати це завдання можна шляхом перевірки всіх доступныхзначений ідентифікаційного поля (загальне количествовозможных значень становить 65535), або ж посилкою декількох сотень DNS-запитів в правильномпорядке. Очевидно, що цей метод не дуже надійний.Ще одним завданням для зловмисника є те,що він повинен мати можливість прослуховувати пакети,які йдуть від довільного DNS, для чого злоумышленникдолжен контролювати DNS-сервер, який являетсяавторитетным для цієї зони.

Для цього типу атаки буде використаний пакет «ADMIDtools,який зазв
ичай використовується для тестування рівня захисту DNS.

Утиліта «ADMkill» прослуховує відповіді, надіслані DNS сервером, і відсилає невірні відповіді з підробленим IP-адресою уповноваженого сервера імен.

Для проведення атаки, потрібно вгадати DNSID. Інструмент «dnshijackertool» може бути використаний дляпрослушивания DNS трафіку, після чого зловмисник може оцінити діапазон ID для запитів сервераимен. Атакуючий повинен виконати следующиедействия:

1. Зловмисник посилає DNS-запит на дозвіл імені www.test.com цільовим серверуns.dnstest.com.

2. Цільовий DNS-сервер перенаправляє полученныйзапрос до сервера доменаns.test.com.

3. Зловмисник прослуховує запити, одержувані ns.test.com і визначає ID.

4. Зловмисник посилає DNS-запит на дозвіл імені www.victim.com сервера ns.dnstest.com.І відразу ж шле групу фальсифікованих DNS-відповідей (передаючи в якості IP-адреси, один з адресовзлоумышленника — 10.0.0.1) на свій запит з подмененным IP-адресою джерела на адресу одного з DNS-серверів victim.com. В кожній відповіді ID увеличиваетсяна 1 порівняно з ідентифікатором, полученнымво час другого етапу атаки, для збільшення ймовірності знаходження правильного номери ID. Сервер ns.dnstest.com міг відповісти на запити інших клиентови, відповідно, збільшити свій DNS ID. Для этогоможет бути використана утиліта «ADMkill», котораябудет відсилати серію підроблених відповідей з IP-адресомс заданим діапазоном ID (тобто ми відсилаємо пакетыс ID від 27300 до 27330):

# ./ADMkillDNS 10.0.0.1 192.168.1.60 ns2.victim.com27300 27330

В результаті такої атаки за підробленими IP-адресамбудет ходити не окремий клієнт-жертва, а всі користувачі будуть звертатися до машини зловмисника.

4. DNSSEC і навантаження на мережу

Як вже згадувалося вище, в основі протоколаDNSSEC лежить метод цифрового підпису відповідей назапросы, в результаті чого пакети DNSSEC несуть більше інформації, що збільшує навантаження на пам’ять,процесор і смугу пропускання сервера. ВнедрениеDNSSEC збільшує обсяг переданих даних, за рахунок використання цифрового підпису. Для того, чтобыэто перевірити, були прослухані запити отправляемыепользователями. Проанализаровав їх можна однозначносделать висновок, що обсяг трафіку збільшується приразвернутом DNSSEC майже на 20 %. Також следуетзнать, що якщо пакет перевищить 512 байт, то можуть вооз-виникнути проблеми з його прийомом. Звичайно, у цієї проблеми є рішення. Згідно з протоколом DNS клиентдолжен повідомити про це серверу, який, в свою чергу, намагатиметься вмістити відповідь установленные512 байт. При цьому частина інформативних даних може бути обрізана. У разі, якщо навіть необходимаяинформация не поміщається, сервер повідомить про этомклиенту установкою біта «обрізання» (truncationbit).Однак, стиск не безмежне, і якщо після нього розмір пакета все ще великий, то клієнт автоматично перемикається з транспортного протоколу UDP в TCP,в якому немає подібних обмежень. Некоторыемаршрутизаторы або пристрою безпеки могутработать на правилі про обмеження пакету 512 байт,що в свою чергу вимагає переконфігурації.

5. Висновки

У цій статті були досліджені та реалізовані атакина сервер імен, в результаті чого було з’ясовано, чтооригинальный DNS стандарт не піклується про безпеку. При проведенні атак на сервер з развернутымDNSSEC методи, які використовувалися при атакена «чистий» DNS, виявилися безуспішними. Причинойэтого є те, що в основі протоколу DNSSECлежит метод цифрового підпису відповідей на запити.В ході аналізу проведених атак, було з’ясовано, чтоDNSSEC може боротися з таким уразливими DNSкак «отруєння кеша» або «людина посередині». Этообъясняется тим, що DNSSEC захищає DNS путемпроверки автентичності та цілісності системи DNS-повідомлень. Атаки, орієнтовані на DNS повідомлення, неможливі при використанні DNSSEC, так какклиенты перевіряють цифровий підпис предоставляемуюв відповідь. Розширення безпеки DNS SecurityExtensionsзащищают клієнтів і сервера від атак, при яких модифікується кеш DNS, шляхом підписання записис використанням шифрування з відкритим ключем.

В ході роботи було виявлено, що впровадження DNSSECувеличивает обсяг переданих даних, навантаження напам’ять, процесор і смугу пропускання сервера на20 %, що не є критичним, з урахуванням рівня здійснюється безпеки.