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

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

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

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

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

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

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

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

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

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

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

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

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

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

Існують такі механізми, як TSIG (Підписи транзакцій)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, іноді достатньо лише встановити прапорець у панелі керування. Однак, залежно від провайдера та рівня обслуговування, ця функціональність може мати невелику річну вартість.

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

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

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

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

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

Щоб перевірити, чи захищений ваш домен DNSSEC, існує кілька онлайн-інструментів, таких як Аналізатор DNSSEC та інші утиліти перевіркиКоли ви вводите свій домен, ви повинні побачити такі записи, як 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)Ідея цього підходу полягає в додаванні шифрування до запитів 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 та покращити свою конфіденційність