DNSSEC та безпека DNS у вашій локальній мережі

Інформатек Діджитал » Ресурси » DNSSEC та безпека DNS у вашій локальній мережі

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

Раніше пріоритетом було просто переконатися, що все працює; сьогодні ми знаємо, що цього недостатньо. DNS народився в 80-х роках без урахування масованих кібератак, але тепер нам потрібен не лише для розпізнавання імен, а й для перевірки автентичності та цілісності кожної відповіді . Саме тут з'являється DNSSEC, а нещодавно з'явилися такі пропозиції, як E-DNSSEC, які також спрямовані на додавання конфіденційності — ключового фактора, якщо ви стурбовані безпекою своєї локальної або корпоративної мережі.

Що таке DNS і чому він такий важливий для безпеки?

Система доменних імен (DNS ) – це телефонний довідник Інтернету: вона перетворює легкозапам’ятовувані імена (наприклад, www.example.com) на числові IP-адреси, які розуміють комп’ютери (наприклад, 192.168.2.15 або IPv6-адреса). Без цього механізму нам довелося б запам’ятовувати числа замість імен, що абсолютно непрактично.

Ця інфраструктура організована як розподілена база даних у деревоподібній структурі , з кореневою зоною на вершині, за якою йдуть домени верхнього рівня (TLD, такі як .es, .com, .org), а нижче – домени та піддомени. Кожна частина цієї бази даних називається «зоною » та розміщена на одному або кількох авторитетних серверах імен, які публікують «офіційну» інформацію для кожного домену.

Коли ваш комп’ютер, мобільний телефон або будь-який інший пристрій хоче отримати доступ до веб-сайту, він починає із запиту до stub resolver , який є частиною операційної системи. Цей resolver надсилає запит на рекурсивний DNS-сервер (зазвичай вашого інтернет-провайдера, вашої компанії або публічний, такий як Google Public DNS , OpenDNS або Quad9). Потім цей рекурсивний сервер шукає відповідь, запитуючи кілька авторитетних серверів, доки не знайде правильну IP-адресу.

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

Основна проблема полягає в тому, що за своєю початковою архітектурою DNS не має надійного способу перевірки автентичності відповідей . Резолвер, по суті, перевіряє, чи відповідь, здається, надходить з тієї ж IP-адреси, яку він запитував, але цю вихідну IP-адресу можна відносно легко підробити. Це дозволяє здійснювати атаки з прихованою переадресацією на шахрайські сайти, які імітують, наприклад, веб-сайт вашого банку.

Обмеження безпеки традиційного DNS

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

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

Уявіть, що ви заходите на веб-сайт вашого банку: ваш комп’ютер запитує IP-адресу домену банку у рекурсивного сервера, але зловмисник обманом змусив сервер прийняти фальшиву відповідь з IP-адресою ідентичного веб-сайту, який він контролює . Користувач вводить свої облікові дані, думаючи, що все нормально, а кіберзлочинець отримує їх у звичайному тексті для подальшого використання на реальному сайті.

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

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

Що таке DNSSEC і який внесок він робить у безпеку?

У відповідь на всі ці недоліки були розроблені розширення безпеки системи доменних імен (DNSSEC) . DNSSEC не замінює класичний DNS, а радше розширює його рівнем безпеки, який дозволяє перевірити, чи отримані дані є легітимними та не були змінені.

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

Коли рекурсивний сервер запитує домен за допомогою DNSSEC, разом зі звичайною інформацією (наприклад, IP-адресою, пов'язаною з іменем), він також отримує цифрові підписи та відкриті ключі, необхідні для перевірки . Рекурсивний сервер перевіряє підписи на відповідність опублікованим відкритим ключам; якщо перевірка успішна, дані вважаються автентичними та незмінними з моменту підписання.

Якщо перевірка не вдається, резолвер розуміє, що щось не так (наприклад, спроба підробки або втручання під час передачі) та відповідає клієнту кодом помилки, зазвичай SERVFAIL . Таким чином, користувач не отримує потенційно шкідливих даних, хоча з його точки зору, все, що він побачить, це те, що сторінка «не завантажується» або відображає помилку.

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

Ключі, записи та ланцюжок довіри KSK та ZSK

Для кращої організації безпеки DNSSEC використовує два різних типи ключів: ключ підпису ключа (KSK) та ключ підпису зони (ZSK) . Хоча технічно вони однакові (з криптографічної точки зору), їхня функція в системі різна.

Ключ ZSK використовується для підписання всіх записів ресурсів у зоні (A, AAAA, MX тощо). Зазвичай його часто змінюють, щоб мінімізувати ризик, оскільки будь-яка компрометація цього ключа вплине на всі записи в зоні. KSK, з іншого боку, в основному використовується для підписання самого ключа зони (ZSK), а його хеш публікується як запис DS (підписувач делегування) у батьківській зоні.

Завдяки такому розподілу ролей зміна ZSK стала простішою: просто згенеруйте новий ZSK, підпишіть його за допомогою KSK, опублікуйте в записах DNSKEY зони та дозвольте резолверам оновити свою інформацію. Немає потреби торкатися батьківської зони, оскільки DS продовжує вказувати на той самий KSK, який залишається стабільним довше.

DNSSEC додає до протоколу DNS кілька типів специфічних записів, призначених для підтримки підпису та перевірки даних. Серед найважливіших – DNSKEY, RRSIG, DS, NSEC/NSEC3 та NSEC3PARAM . Усі вони дозволяють створювати логіку автентифікації, не змінюючи базову роботу запитів.

Запис DNSKEY зберігає відкритий ключ зони , необхідний для перевірки підписів. Запис RRSIG містить цифровий підпис, пов'язаний з певним набором записів («Набір ресурсних записів»). Запис DS – це хеш DNSKEY дочірньої зони, який публікується в батьківській зоні та служить ланкою в ланцюжку довіри.

Записи NSEC та NSEC3 використовуються для забезпечення автентифікованого заперечення існування , тобто для криптографічного підтвердження того, що доменне ім'я або запис не існує, запобігаючи атакам, які намагаються підсунути хибні відповіді, що вказують на те, що щось не існує, коли насправді воно існує (або навпаки).

Ланцюг довіри та перевірка відповіді DNSSEC

Так званий ланцюг довіри в DNSSEC будується шляхом зв'язування записів DNSKEY та DS від кореня до домену, який ми хочемо перевірити . Відправною точкою є відкритий ключ кореневої зони, який діє як орієнтир довіри та зазвичай налаштовується безпосередньо в рекурсивних резолверах.

Наприклад, якщо ви хочете перевірити домен, такий як mywebsite.es, логічний процес буде таким: резолвер довіряє відкритому ключу кореневого домену, який підписує ключ .es; зона .es публікує запис DS, що відповідає ключу KSK mywebsite.es; шляхом перевірки цього DS за допомогою ключа .es, резолвер довіряє DNSKEY mywebsite.es і звідти може перевірити RRSIG у всіх своїх записах.

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

Цей ієрархічний зв'язок також означає, що для справжньої ефективності DNSSEC недостатньо підписати лише вашу зону : батьківська зона (наприклад, .es) та коренева зона також повинні бути підписані, а їхні DNS-записи повинні бути правильно опубліковані. Наразі коренева зона DNS та практично всі загальні домени верхнього рівня (gTLD) і багато доменів верхнього рівня з кодом країни (ccTLD) вже підписані.

Коли рекурсивний сервер з увімкненою перевіркою DNSSEC виявляє, що підпис не збігається або що посилання відсутнє, відповідь, яку він повертає клієнту, зазвичай супроводжується кодом помилки RCODE SERVFAIL. Це може заплутати кінцевого користувача («вебсайт не працює»), але з точки зору безпеки це захисний захід від потенційно маніпульованих даних.

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

Атаки, що пом'якшуються за допомогою DNSSEC, та їх зв'язок з TLS/HTTPS

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

Крім того, DNSSEC знижує ризик отруєння кешу на рекурсивних серверах , запобігаючи прийняттю маніпульованих відповідей, які не проходять перевірку підпису. Це також ускладнює атаки типу «людина посередині» (MITM) на DNS-трафік, під час яких зловмисник змінює відповіді під час передачі: якщо відповідь не проходить перевірку, резолвер її відкидає.

Однак важливо розуміти, чого DNSSEC не робить. Ці розширення не призначені для шифрування вмісту запитів або відповідей . Весь DNS-трафік, навіть з DNSSEC, все одно передається у вигляді звичайного тексту, якщо ви не використовуєте інші додаткові технології (такі як DoT, DoH або рішення типу E-DNSSEC). DNSSEC зосереджується на забезпеченні автентичності отриманої вами інформації та її відсутності змін, а не на приховуванні того, що ви запитуєте.

Це чітко відрізняє його від таких протоколів, як TLS та HTTPS . У той час як HTTPS шифрує трафік між браузером і веб-сервером, щоб запобігти шпигунству або зміні зв'язку третіми сторонами, DNSSEC просто підписує дані DNS для виявлення спуфінгу. Сайт може мати HTTPS без DNSSEC або DNSSEC без HTTPS, але поєднання обох пропонує набагато комплексніший захист від спуфінгу та шпигунства.

Такі організації, як ICANN та IETF, роками сприяють широкому впровадженню DNSSEC реєстрами, реєстраторами, інтернет-провайдерами та мережевими операторами. Мета полягає в тому, щоб підписувалося все більше зон, а більше резолверів активно перевіряли їх, щоб пересічний користувач міг скористатися цими криптографічними гарантіями, не вживаючи жодних спеціальних дій.

DNSSEC у доменах .es та зобов'язання власників

У конкретному випадку Іспанії, підрозділ доменів ".es", яким керує Red.es, вже давно впроваджує додаткові технології та процедури для покращення якості та безпеки служби DNS з кодом країни .es. Серед цих заходів є впровадження протоколу безпеки DNSSEC відповідно до специфікацій IETF.

Домени .es відповідають за підписання зони верхнього рівня .ES та отримання авторизації від кореневого DNS-сервера, таким чином інтегруючись у глобальний ланцюг довіри. Це означає, що якщо ви володієте доменом .es, ви можете використовувати цю інфраструктуру для захисту власного домену за допомогою DNSSEC.

Як для власника домену, загальна процедура ввімкнення DNSSEC передбачає забезпечення публікації підписаної зони вашими авторитетними DNS-серверами. Зазвичай це передбачає створення відкритого ключа для вашої зони, підписання записів, публікацію DNS-ключа, а потім надсилання матеріалу ключа (або самого запису DS) до реєстру або вашому реєстратору, щоб вони могли створити відповідний запис DS у батьківській зоні.

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

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

DNSSEC у локальній мережі: перевірка на стороні користувача

З точки зору кінцевого користувача або компанії, яка стурбована безпекою своєї локальної мережі, ключове питання: що потрібно, щоб скористатися перевагами DNSSEC? Гарна новина полягає в тому, що вам не потрібно нічого налаштовувати на кожному комп’ютері окремо , якщо ваш рекурсивний DNS-сервер (той, який використовують ваші комп’ютери) перевіряє DNSSEC.

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

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

Щоб перевірити, чи захищено ваш домен DNSSEC, існує кілька онлайн-інструментів, таких як DNSSEC Analyzer та інші утиліти перевірки . Коли ви вводите свій домен, ви повинні побачити такі записи, як RRSIG (криптографічні підписи), DNSKEY (відкриті ключі) та DS (хеш DNSKEY у батьківській зоні). Якщо інструмент показує, що із записами немає цифрового підпису, ваш домен вважатиметься «непідписаним» або «незахищеним».

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

Обмеження DNSSEC: конфіденційність та інші аспекти

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

Він також не пропонує контролю доступу або спеціального захисту від атак типу «відмова в обслуговуванні» (DoS або DDoS) . Фактично, додаючи більше даних (підписів, ключів, додаткових записів), він збільшує розмір DNS-відповідей, що може бути використано в атаках посилення, якщо інфраструктура не налаштована та не захищена належним чином.

З іншого боку, DNSSEC вносить певну операційну складність: необхідно керувати парами ключів , ротувати ZSK та KSK, координувати публікацію DS у батьківській зоні та забезпечувати відсутність невідповідностей, які порушують ланцюжок довіри. Помилка в цих процедурах може призвести до того, що домен перестане правильно перевірятися, що призведе до очевидних перебоїв у роботі.

У самому процесі DNSSEC у повідомленнях є керуючі біти (такі як біт CD у запитах та біт AD у відповідях), які впливають на те, як виконується та повідомляється про перевірку. Зловмисник, який може маніпулювати цими бітами в небезпечному середовищі, може спробувати погіршити захист, що пропонується рекурсивним резольвером. Тому рекомендується, щоб зв'язок між резольверами та клієнтами, що використовують DNSSEC, відбувався через захищені канали.

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

E-DNSSEC: шлях до автентифікованого та зашифрованого DNS

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

Мета E-DNSSEC — поєднати властивості DNSSEC (автентичність та цілісність) з механізмами шифрування, які забезпечують конфіденційність запитів між клієнтом DNSSEC та сервером DNSSEC . Це підвищує загальну безпеку служби DNS, запобігаючи зовнішнім спостерігачам бачити, які доменні імена розпізнаються.

Концептуальний процес включатиме аналіз запиту на рекурсивному сервері, його шифрування перед надсиланням на авторитетний сервер, а потім розшифрування та обробку у звичайному режимі за допомогою DNSSEC . Відповідь, у свою чергу, може бути повернута підписаною та зашифрованою назад на рекурсивний сервер або клієнта, зберігаючи конфіденційність протягом усього процесу.

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

Сьогодні такі пропозиції, як E-DNSSEC, є частиною ширших зусиль щодо посилення конфіденційності DNS , поряд з такими технологіями, як DNS поверх TLS (DoT) та DNS поверх HTTPS (DoH). Основний напрямок зрозумілий: DNS майбутнього має бути одночасно автентичним та конфіденційним, і недостатньо просто швидко визначати імена; це також має бути зроблено безпечно.

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

Уся ця екосистема — від класичного DNS до DNSSEC та шифрованих рішень, таких як E-DNSSEC — демонструє, що безпека DNS — це не додаткова функція, а ключовий компонент архітектури Інтернету та будь-якої сучасної локальної мережі. Наявність резолверів, які перевіряють, підписаних зон, добре підтримуваних ланцюгів довіри та, в майбутньому, зашифрованих каналів для запитів, робить вирішальну різницю між відкритою мережею та інфраструктурою, підготовленою до поточних та майбутніх викликів.

Пов'язана стаття:

Як увімкнути DNS через HTTPS (DoH) у Windows 11 та покращити свою конфіденційність