DNSSEC и DNS сигурност във вашата локална мрежа

Информатек Дигитал » Ресурси » DNSSEC и DNS сигурност във вашата локална мрежа

Интернет е изграден върху няколко ключови компонента, които почти никога не виждаме, но които са там всеки път, когато отворим браузъра си. Един от най-важните е системата от имена на домейни и когато говорим за DNSSEC и сигурност в локална мрежаВ действителност говорим за осигуряване на тази основа, за да се предотвратят измамни пренасочвания, имперсонации и други доста сериозни атаки.

Преди приоритетът беше просто да се гарантира, че всичко работи; днес знаем, че това не е достатъчно. DNS беше създаден през 80-те години на миналия век, без да се вземат предвид масивните кибератаки, но сега се нуждаем от него, за да прави повече от просто разрешаване на имена, проверете автентичността и целостта на всеки отговорЕто къде се намесва DNSSEC, а напоследък и предложения като E-DNSSEC, които също се стремят да добавят поверителност, нещо ключово, ако сте загрижени за сигурността на вашата локална или корпоративна мрежа.

Какво е DNS и защо е толкова важен за сигурността?

DNS системата (Domain Name System) е телефонният указател в интернет: той превежда лесни за запомняне имена (като www.example.es) в числови IP адреси, които оборудването разпознава (например 192.168.2.15 или IPv6 адрес). Без този механизъм ще трябва да запомняме числа вместо имена, което е напълно непрактично.

Тази инфраструктура е организирана като разпределена база данни във формата на дърво, с коренна зона най-отгоре, следвана от домейни от най-високо ниво (TLD като .es, .com, .org) и, отдолу, домейни и поддомейни. Всяка част от тази база данни се нарича „зона„и се хоства на един или повече авторитетни сървъри за имена, които публикуват „официалната“ информация за всеки домейн.“

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

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

За да проверите дали вашият домейн е защитен от DNSSEC, има няколко онлайн инструмента, като например DNSSEC анализатор и други помощни програми за валидиранеКогато въведете домейна си, би трябвало да видите записи като RRSIG (криптографски подписи), DNSKEY (публични ключове) и DS (хеш на DNSKEY в родителската зона). Ако инструментът покаже, че няма цифров подпис, свързан със записите, вашият домейн ще се счита за „неподписан“ или „несигурен“.

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

Ограничения на DNSSEC: поверителност и други аспекти

Въпреки всичките си предимства, DNSSEC не е магическо решение за всички проблеми със сигурността на DNS. Ключов аспект е, че Не осигурява поверителност на консултациитеDNS пакетите, дори с DNSSEC, все още пътуват като обикновен текст, така че всеки, който има достъп до трафика (например в несигурна обществена WiFi мрежа) можете да видите кои домейни се запитват.

Той също така не предлага контрол на достъпа или специфична защита срещу атаки тип „отказ от услуга“ (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 и да подобрите поверителността си