Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

DNSSEC



План:


Введення

DNSSEC ( англ. Domain Name System Security Extensions ) - Набір специфікацій IETF, що забезпечують безпеку інформації, що надається засобами DNS в IP -мережах. Він забезпечує DNS-клієнтам (резолверам) аутентифікацію даних DNS або аутентифікацію інформації про факт відсутності даних та їх цілісність. Не забезпечується доступність даних і конфіденційність запитів.

Забезпечення безпеки DNS критично важливо для інтернет-безпеки в цілому. Поширенню DNSSEC в значній мірі перешкоджали:

  1. Розробка назад сумісного стандарту, який можна масштабувати до розміру інтернету
  2. Застосування реалізацій DNSSEC у величезній кількості DNS серверів і клієнтів
  3. Розбіжності між ключовими гравцями з приводу того, хто повинен володіти доменами верхнього рівня (. com,. net)
  4. Подолання передбачуваної складності та застосування DNSSEC

Більша частина цих проблем вирішена технічним інтернет-спільнотою.


1. Опис

Спочатку Domain Name System (DNS) розроблявся не в цілях безпеки, а для створення масштабованих розподілених систем. З часом система DNS стає все більш вразливою. Зловмисники без праці перенаправляють запити користувачів по символьному імені на підставні сервери і таким чином отримують доступ до паролів, номерів кредитних карт і іншої конфіденційної інформації. Самі користувачі нічого не можуть з цим поробити, тому що в більшості випадків навіть не підозрюють про те, що запит був перенаправлений. DNSSEC є спробою забезпечення безпеки при одночасній зворотної сумісності.

DNSSEC була розроблена для забезпечення безпеки клієнтів від фальшивих DNS даних, наприклад, створюваних DNS cache poisoning. Усі відповіді від DNSSEC мають цифровий підпис. При перевірці цифрового підпису DNS распознаватель перевіряє вірність та цілісність інформації. Хоча захист адресних записів є безпосередньою проблемою для багатьох користувачів, DNSSEC може захистити іншу інформацію, таку як криптографічні сертифікати загального призначення, що зберігаються в CERT record DNS. RFC 4398 описує, як розподілити ці сертифікати, в тому числі по електронній пошті, що дозволяє використовувати DNSSEC в якості глобальної розподіленого сховища сертифікатів ключів підпису.

DNSSEC не забезпечує конфіденційність даних; зокрема, всі DNSSEC відповіді аутентіфіцірованни, але не шифруються. DNSSEC не захищає від DoS атак безпосередньо, хоча в деякому роді робить це побічно. Інші стандарти (не DNSSEC) використовуються для забезпечення великої кількості даних, що пересилаються між серверами DNS.

DNSSEC специфікації (DNSSEC-bis) докладно описують поточний протокол DNSSEC. Див RFC 4033, RFC 4034 і RFC 4035.


2. Історія

DNS є одним з найважливіших і основних інтернет-сервісів. Однак в 1990 Стів Белловін (Steve Bellovin) виявив серйозні недоліки в безпеці. Дослідження в цій області почалися і проводилися повним ходом з часів публікації доповіді у 1995. [1]

RFC 2065 був опублікований IETF в 1997. Перші спроби реалізації цієї специфікації призвели до нової специфікації RFC 2535 у 1999. Було заплановано реалізовувати DNSSEC, грунтуючись на IETF RFC 2535.

На жаль, у специфікації IETF RFC 2535 були дуже серйозні проблеми з масштабуванням на весь інтернет. До 2001 року стало ясно, що ця специфікація була непридатна для великих мереж. При нормальній роботі DNS сервери часто десинхронизированном зі своїми батьками. Зазвичай це не було проблемою, але при включеному DNSSEC десінхронізованние дані могли нести мимовільний DoS ефект. Дійсний DNSSEC вимагає складного протоколу з шести повідомлень і велику кількість даних для здійснення змін спадкоємця (всі DNS зони спадкоємця повинні бути повністю передані батькам, батько вносить зміни і відправляє їх назад спадкоємцю). Крім того, зміни в публічному ключі можуть мати абсурдний ефект. Наприклад, якщо зона ". Com" змінить свій ключ, доведеться відправити 22000000 записів (тому доведеться оновити всі записи у всіх спадкоємців). Таким чином, DNSSEC у вигляді RFC 2535 не може бути масштабувати до розміру інтернету.

IETF здійснила принципову зміну DNSSEC, яке називається DNSSEC-bis (назва була дана щоб відрізняти DNSSEC-bis від первісного підходу DNSSEC в RFC 2535). Нова версія використовує принцип DS ( англ. Delegation Signer ) Для забезпечення додаткового рівня непрямої делегації при передачі зон від батька до спадкоємця. У новому підході при зміні відкритого ключа адміністратору вищестоящого домена відсилається тільки одне-два повідомлення замість шести: спадкоємець посилає дайджест (fingerprint, хеш) нового відкритого ключа батькові. Батько просто зберігає ідентифікатор відкритого ключа для кожного із спадкоємців. Це означає, що зовсім невелика кількість даних буде відправлено батькові замість обміну величезною кількістю даних між спадкоємцем і батьком. Це також означає, що клієнтам доведеться здійснювати додаткові дії для перевірки ключів. Більшість інженерів, які брали участь в розробці стандарту, вважає, що це невелика плата за можливість більш практичного застосування DNSSEC.


3. Принцип роботи

Перевірка достовірності даних в DNSSEC

В основі дії протоколу DNSSEC лежить метод цифрового підпису відповідей на запит DNS lookup, який забезпечує недоторканність даних в системі DNS. Для цього було створено кілька типів DNS записів, в їх числі RRSIG, DNSKEY, DS і NSEC. Вся інформація про захищеному домені (COM, NET, RU ...) в системі DNSSEC певним чином зашифрована, тому може бути змінена тільки за допомогою закритого ключа шифрування. У процесі захищеного делегування домену відбувається генерація пари ключів. Інформація про ключі зберігається на первинному DNS-сервері. Закритий ключ використовується для підпису зони після кожної зміни. За допомогою DS-записи ( англ. Designated Signer ) Цифровий підпис відкритого ключа зберігається у батьківській зоні. Сам же відкритий ключ зберігається в підписується (дочірньої) зоні в запису DNSKEY. Таким чином організується ланцюжок довіри. Знаючи відкритий ключ адміністратора батьківської зони, можна перевірити валідність відкритого ключа будь-який з дочірніх зон.

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


4. Застосування

В основі мережі Інтернет лежить принципово вразлива система доменних імен DNS, і існує великий стимул до підвищення її безпеки. Впровадження DNSSEC сильно затрималося у часі в зв'язку з тим, що вимагає ряд заходів:

  1. DNS сервери повинні підтримувати DNSSEC
  2. TCP / IP повинні використовувати оновлений DNS Resolver, що вміє працювати з DNSSEC
  3. Кожен клієнт повинен отримати хоча б один довірений відкритий ключ до того моменту, як він почне використовувати DNSSEC

5. Підпис кореневої зони

Для повноцінної валідації всіх даних, передавамих за допомогою DNSSEC, потрібна ланцюжок довіри, що йде від кореневої зони (.) DNS. Впровадження підписаної коректним чином кореневої зони на всі кореневі сервери DNS могло викликати крах сучасного Інтернету, тому IETF разом з ICANN була розроблена поступова процедура впровадження підписаної кореневої зони і механізму поширення ключів. Процедура затяглася більш, ніж на 8 місяців і включала в себе покрокове впровадження на сервери DNS спочатку кореневої зони, підписаної недійсним ключем електронного підпису. Цей крок був необхідний для того, щоб забезпечити тестування серверів під навантаженням, зберегти зворотну сумісність зі старим програмним забезпеченням і залишити можливість відкоту до попередньої конфігурації.

До червня 2010 всі кореневі сервери коректно працювали з зоною, підписаної невалідним ключем. У липні ICANN провів міжнародну конференцію, присвячену процедурі генерації ключів електронного підпису, яким згодом була підписана коренева зона.

15 липня 2010 року відбулося підписання кореневої зони і почалося впровадження підписаної зони на сервери. 28 липня ICANN повідомив [2] про завершення цього процесу. Коренева зона була підписана електронним підписом і поширилася в системі DNS.

31 березня 2011 була підписана найбільша зона в Інтернеті (90 млн. доменів) - . Com [3].


6. Інфраструктура ключів

ICANN вибрав таку модель, коли управління підписанням зони відбувається під контролем представників інтернет-співтовариства (Trusted community representative, TCR). Представники вибиралися з числа не пов'язаних з управлінням кореневої зоною DNS. Вибрані представники обіймали посади крипто-офіцерів (Crypto Officer, CO) і утримувачів частин ключа відновлення (Recovery key shareholder, RKSH). CO були вручені фізичні ключі, що дозволяють активувати генерацію ключа ЕЦП ZSK, а RKSH володіють смарт-картами, що містять частини ключа (KSK), використовуваного всередині криптографічного обладнання. Деякими ЗМІ був зроблений висновок, що процедури, які потребують присутності CO або RKSH, будуть проводитися в разі надзвичайних ситуацій в мережі [4]. Однак у відповідності з процедурами ICANN, CO будуть залучатися кожен раз при генерації ключа підписання зони (ZSK), до 4 разів на рік, а RKSH - ймовірно, ніколи або у разі втрати ключів CO або скомпрометованої кореневої зони [5].


7. Поточний стан

На листопад 2012 року в кореневій зоні присутні 67 національних доменів і 13 загальних доменів, підписаних DNSSEC і забезпечують таким чином ланцюжок довіри доменах другого рівня. У 2011 році за допомогою DNSSEC (NSEC3 opt-out) була підписана зона . Su, що має відношення до Росії, а в кінці жовтня 2012 року в ній почалася публікація DS-записів, створених користувачами. [6] У 2012 році очікується підписання російського домену . Ru. [7]


8. Програмне забезпечення DNSSEC

Використання DNSSEC вимагає програмного забезпечення як на серверної, так і на клієнтській стороні.

  • BIND ( англ. Berkeley Internet Name Domain ).
  • Drill це інструмент з підтримкою DNSSEC входить в набір інструментів ldns.
  • DNSSEC-Tools проект SourceForge, спрямований на забезпечення простого у використанні набору інструментів для роботи з DNSSEC.
  • Unbound резолвер написаний з нуля, грунтуючись на принципах роботи DNSSEC.
  • підтримка DNSSEC була надана в Windows 7 і Windows Server 2008 R2. [8]
  • mysqlBind
  • OpenDNSSEC

Примітки

  1. "Using the Domain Name System for System Break-Ins" - citeseer.ist.psu.edu/bellovin95using.html by Steve Bellovin, 1995
  2. DNSSEC Root Signing Announcement - icann.org/en/news/releases/release-28jul10-en.pdf
  3. Deploying Security Extensions in. Com Top Level Domain
  4. Шести програмістам роздали "ключі для перезавантаження інтернету" - podrobnosti.ua/internet/2010/07/28/704415.html
  5. DNSSEC for the Root Zone - www.root-dnssec.org/wp-content/uploads/2010/08/rootsign-ietf78-update.pdf
  6. DNSSEC в RU-CENTER
  7. А. Ільїн, ТЦИ. Досвід створення пілотної зони DNSSec для RU - www.ripe.net/ripe/meetings/regional-meetings/moscow-2010/dnssecforru.pdf
  8. DNSSEC in Windows Server

Цей текст може містити помилки.

Схожі роботи | скачати
© Усі права захищені
написати до нас