Koniec problemu z łańcuchem CNAME: uproszczone zarządzanie z Route 53 Resolver DNS Firewall

1 maja 2024

Od dzisiaj możliwa jest konfiguracja DNS Firewall, aby automatycznie ufała wszystkim domenom w łańcuchu rozwiązań (takich jak CNAME lub DNAME).

Aktualizacja z 2 maja 2024: usunąłem odniesienie do aliasu Route53, który błędnie określany był jako łańcuch

Dlaczego warto używać DNS Firewall?

DNS Firewall zapewnia ochronę dla wychodzących żądań DNS z prywatnej sieci w chmurze (Amazon Virtual Private Cloud (Amazon VPC)). Żądania kierują się przez Amazon Route 53 Resolver dla rozwiązania nazwy domeny. Administratorzy firewalla mogą konfigurować reguły, aby filtrować i regulować wychodzący ruch DNS.

DNS Firewall pomaga w ochronie przeciwko wielu niebezpieczeństwom.

Wyobraźmy sobie, że złośliwemu aktorowi udało się zainstalować i uruchomić jakiś kod na instancjach Amazon Elastic Compute Cloud (Amazon EC2) lub kontenerach działających w jednej z Twoich prywatnych chmur wirtualnych (VPC). Złośliwy kod prawdopodobnie zainicjuje wychodzące połączenia sieciowe. Mógłby tak zrobić, aby połączyć się z serwerem komend i otrzymywać komendy do wykonania na Twoim urządzeniu. Mógłby także zainicjować połączenie do zewnętrznej usługi w skoordynowanym rozproszonym ataku odmowy usługi (DDoS) lub spróbować potajemnie wyciągnąć dane, które udało mu się zebrać w Twojej sieci.

Na szczęście Twoja sieć i grupy bezpieczeństwa są poprawnie skonfigurowane. Blokują cały wychodzący ruch, poza tym, który jest dobrze znany przez punkty końcowe API używane przez Twoją aplikację. Jak na razie wszystko idzie w porządku - złośliwy kod nie może wynieść informacji używając zwykłych połączeń TCP lub UDP.

A co z ruchem DNS? Złośliwy kod może wysyłać żądania DNS do autorytarnego serwera DNS, które kontrolują, żeby wysłać komendy kontroli lub zakodowane dane i może otrzymać w zamian dane. Zilustrowałem ten proces na poniższym schemacie.

DNS trafficAby zapobiec tym sytuacjom, możesz użyć DNS Firewall, aby monitorować i kontrolować domeny, o które mogą pytać Twoje aplikacje. Możesz odmówić dostępu do domen, o których wiesz, że są niebezpieczne i pozwolić innym żądaniom na przejście. Możesz też odmówić dostępu wszystkim domenom, poza tymi, którym w pełni ufasz.

Na czym polega wyzwanie z rejestrami CNAME i DNAME?

Wyobraź sobie, że skonfigurowałeś DNS Firewall, aby zezwolić jedynie na żądania DNS określonym, dobrze znanym domenom i zablokowałeś wszystkie inne. Aplikacja komunikuje się z alexa.amazon.com; co za tym idzie, stworzyłeś regułę pozwalającą ruchowi DNS na rozwiązanie hostname.

Jednakże, system DNS ma wiele typów rejestrów. Te, które nas interesują w tym artykule, to:

  • Rejestry A, które przyporządkowują nazwę DNS do adresu IP
  • Rejestry CNAME, które stanowią synonimy dla innych nazw DNS
  • Rejestry DNAME, które zapewniają przekierowanie z części drzewa nazewniczego DNS do innej części drzewa DNS

Po wysłaniu żądania alexa.amazon.com mogę zobaczyć, że w rzeczywistości jest to rejestr CNAME, który odwołuje się do pitangui.amazon.com - następnego rejestru CNAME, kierującego się do tp.5fd53c725-frontier.amazon.com, który z kolei jest CNAME dla d1wg1w6p5q8555.cloudfront.net. Jedynie ostatnia nazwa posiada rejestr A połączony z adresem IP 3.162.42.28. Adres IP zapewne będzie u Ciebie inny. Wskazuje na najbliższą lokalizację krawędzi Amazon CloudFront. Dla mnie jest to Paryż (CDG52).

Podobny mechanizm następuje przy rejestrach DNAME.

Podobny mechanizm następuje przy rejestrach DNAME.

Aby pozwolić na pełne rozwiązanie takiego łańcucha CNAME, mógłbyś mieć ochotę na konfigurację reguły DNS Firewall, aby pozwolić na wszystkie nazwy pod amazon.com (*.amazon.com), ale doprowadziłoby to do zaprzestania działania ostatniego CNAME idącego do cloudfront.net.

Łańcuch DNS CNAME jest kontrolowany przez usługę, z którą łączy się Twoja aplikacja. Łańcuch mógłby się zmienić w każdym momencie, zmuszając Cię do manualnego zarządzania listą reguł i autoryzowanych domen w regułach DNS Firewall.

Wprowadzenie autoryzacji łańcucha przekierowującego DNS Firewall

Na podstawie tego wyjaśnienia jesteś teraz w stanie zrozumieć nową możliwość, którą wypuściliśmy dzisiaj. Dodaliśmy parametr do UpdateFirewallRule API (dostępne także na AWS Command Line Interface (AWS CLI) i AWS Management Console), aby skonfigurować DNS Firewall, żeby śledził i automatycznie ufał wszystkim domenom w łańcuchu CNAME lub DNAME.

Ten parametr pozwala administratorom firewallowym na dawanie pozwoleń jedynie dla domen w żądaniach Twoich aplikacji. Firewall automatycznie zaufa wszystkim pośrednim domenom w łańcuchu, dopóki nie osiągnie rejestru A z adresem IP.

Zobaczmy to w akcji

Zaczynam z już skonfigurowanym DNS Firewall przez listę domen, grupę reguł i regułę, które POZWALAJĄ na żądania dla domeny alexa.amazon.com. Grupa reguł jest przyłączona do VPC, gdzie mam odpaloną instancję EC2.

Kiedy łączę się z tą instancją i wysyłam żądanie DNS, aby rozwiązać alexa.amazon.com, zwraca jedynie pierwszą nazwę w łańcuchu domen (pitangui.amazon.com) i się zatrzymuje. Jest to spodziewane, ponieważ pitangui.amazon.com nie uzyskało autoryzacji.

Wprowadzenie autoryzacji łańcucha przekierowującego DNS Firewall

Aby to rozwiązać, aktualizuję regułę firewall, aby zaufała całemu łańcuchowi przekierowującemu. Używam AWS CLI do wezwania update-firewall-rule API z nowym parametrem firewall-domain-redirection-action ustawionym na TRUST_REDIRECTION_DOMAIN.

Aby to rozwiązać, aktualizuję regułę firewall, aby zaufała całemu łańcuchowi przekierowującemu. Używam AWS CLI do wezwania update-firewall-rule API z nowym parametrem firewall-domain-redirection-action ustawionym na TRUST_REDIRECTION_DOMAIN.

Poniższy schemat ilustruje konfigurację na tym etapie.

DNS Firewall

Wracając do instancji EC2, próbuję jeszcze raz żądania DNS. Tym razem działa. Rozwiązuje cały łańcuch przekierowujący aż do adresu IP.

Wracając do instancji EC2, próbuję jeszcze raz żądania DNS. Tym razem działa. Rozwiązuje cały łańcuch przekierowujący aż do adresu IP.

Dzięki zaufanemu przekierowaniu łańcucha, administratorzy sieciowi mogą teraz w łatwy sposób zaimplementować strategię blokowania wszystkich domen i autoryzacji jedynie tych zaufanych w DNS Firewall bez potrzeby martwienia się o łańcuchy CNAME lub DNAME.

Ta możliwość jest dostępna bez żadnych dodatkowych kosztów we wszystkich regionach AWS. Spróbuj już dziś!

źródło: AWS

 

Case Studies
Referencje

Firma Hostersi pozwoliła nam osadzić ogólne zagadnienia programu Well Architected Framework w kontekście naszej firmy. Oszczędziło nam to wiele czasu i pozwoliło znaleźć lepiej dopasowane rozwiązania do specyfiki naszego biznesu. WAF był świetnym katalizatorem do wprowadzenie szeregu zmian w obszarze niezawodności, szybkości i bezpieczeństwa edrone. 

Piotr Stachowicz
CTO
W skrócie o nas
Specjalizujemy się w dostarczaniu rozwiązań IT w obszarach projektowania infrastruktury serwerowej, wdrażania chmury obliczeniowej, opieki administracyjnej i bezpieczeństwa danych.