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 адреса на идентичен уебсайт, контролиран от него . Потребителят въвежда своите идентификационни данни, мислейки, че всичко е нормално, а киберпрестъпникът ги получава в обикновен текст, за да ги използва по-късно на реалния сайт.

Механизми като Transaction Signatures (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 (Delegation Signer) запис в родителската зона.

Благодарение на това разделение на ролите, промяната на 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, логичният процес би бил: резолверът се доверява на публичния ключ на root домейна, който подписва .es ключа; .es зоната публикува DS запис, съответстващ на KSK ключа mywebsite.es; чрез валидиране на този DS с .es ключа, резолверът се доверява на DNSKEY на mywebsite.es и оттам може да провери RRSIG-овете във всички свои записи.

Ако валиден подпис липсва във веригата или ако DS (Data Signature - подпис на данни) не е наличен там, където трябва да бъде, веригата на доверие е прекъсната. В този случай рекурсивният сървър, извършващ валидирането, не счита данните за безопасни и, в зависимост от конфигурацията си, или не отговаря със заявените записи, или маркира отговора като невалиден.

Тази йерархична връзка означава също, че за да бъде 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 от години; активирането му обикновено включва само няколко промени в конфигурационния им файл и добавяне на root trust anchor.

След като валидирането е активирано, когато един от компютрите ви в локалната мрежа отправи запитване към подписан домейн, рекурсивният резолвер проверява всички подписи и веригата на доверие, преди да върне отговора. Ако нещо не съвпада, той не връща никакви записи и потребителят вижда грешка, което ефективно му пречи да се свърже с потенциално измамен сайт.

За да проверите дали вашият домейн е защитен от 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 криптирано) . Идеята зад този подход е да се добави криптиране към 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 и да подобрите поверителността си