Automatycznie blokuj podejrzaną aktywność DNS za pomocą Amazon GuardDuty i Route 53 Resolver DNS Firewall

W poniższym artykule twórcy pokażą, jak korzystać z zapory DNS Amazon Route 53 Resolver, aby automatycznie odpowiadać na podejrzane zapytania DNS wykryte przez Amazon GuardDuty w środowisku Amazon Web Services (AWS).

Filar bezpieczeństwa AWS Well-Architected Framework obejmuje reagowanie na incydenty, stwierdzając, że Twoja organizacja powinna wdrożyć mechanizmy, aby automatycznie reagować i łagodzić potencjalny wpływ problemów z bezpieczeństwem. Automatyzacja reakcji na incydenty pomaga skalować możliwości, szybko zmniejszać zakres zagrożonych zasobów i ograniczać powtarzalną pracę zespołów ds. bezpieczeństwa.

Przypadki użycia zapory DNS Route 53 Resolver

Route 53 Resolver DNS Firewall to zarządzana zapora, której można używać do blokowania zapytań DNS dotyczących znanych złośliwych domen i zezwalania na zapytania dotyczące zaufanych domen. Zapewnia bardziej szczegółową kontrolę nad zachowaniem zapytań DNS zasobów w Twoich środowiskach VPC.

Pora omówić dwa przypadki użycia zapory DNS Route 53 Resolver:

• Korzystanie z list dozwolonych – jeśli masz bardziej rygorystyczne wymagania dotyczące zabezpieczeń sieci i chcesz odrzucać wszystkie wychodzące zapytania DNS dla domen, które nie pasują do tych na listach zatwierdzonych domen (znanych jako listy dozwolone lub białe listy), możesz utworzyć takie reguły. Nazywa się to podejściem „walled garden” do bezpieczeństwa DNS. Te listy dozwolone obejmują tylko domeny, dla których zasoby w ramach wirtualnej chmury prywatnej Amazon (Amazon VPC) mogą wykonywać zapytania DNS za pośrednictwem DNS dostarczanego przez Amazon. Pomaga to zapewnić blokowanie zapytań DNS zawierających domeny, którym Twoja organizacja nie ufa.
• Korzystanie z list odrzuconych – jeśli Twoja organizacja woli domyślnie zezwalać na wszystkie wychodzące wyszukiwania DNS na Twoich kontach i wymaga tylko możliwości blokowania zapytań DNS dotyczących znanych złośliwych domen, możesz użyć Zapory DNS do tworzenia list odmów, które obejmują wszystkie złośliwe domeny nazwy znane Twojej organizacji. Zapora DNS udostępnia również reguły zarządzane AWS, dając możliwość konfigurowania ochrony przed znanymi zagrożeniami DNS, takimi jak boty typu Command and Control (C&C). Możesz także dodawać listy blokowania z zewnętrznych źródeł analizy zagrożeń typu open source.

Poniżej kilka ważnych punktów dotyczących korzystania z list dozwolonych i odrzuconych:

1. Szersze użycie list dozwolonych skuteczniej blokuje większą liczbę złośliwych zapytań DNS niż krótka lista odmów. Na przykład, jeśli Twoje zadania wymagają dostępu tylko do domen .com, zezwolenie tylko na .com zablokuje wiele złośliwych domen, które mogą być specyficzne dla niektórych krajów. Zobacz listę domen najwyższego poziomu z kodem kraju (ccTLD).
2. Jeśli korzystasz z list dozwolonych, upewnij się, że nadążasz za domenami, z którymi Twoje aplikacje muszą się komunikować. Podobnie, jeśli używasz list odrzuconych, musisz być na bieżąco z aktualizacjami list.
3. Listy dozwolone i listy odrzucone nie są modelami wzajemnie się wykluczającymi i mogą być używane razem. Załóżmy na przykład, że masz listę dozwolonych, która zezwala tylko na domeny .com (z zamiarem domyślnego zablokowania kilku ccTLD). Możesz również użyć wbudowanej listy odmów zarządzanych reguł AWS, aby zablokować znane złośliwe domeny .com w celu uzyskania dodatkowej warstwy bezpieczeństwa.

Omówienie rozwiązania

Odnieś się się do dokumentacji zapory DNS, aby zapoznać się z jej konstrukcjami i zrozumieć, jak działa. Przykład automatyzacji, który w tym artykule przedstawiają autorzy, koncentruje się na dostarczaniu blokad lub alertów dla zapytań DNS z podejrzanymi nazwami domen. Rozważ na przykład scenariusz, w którym wystąpienie Amazon Elastic Compute Cloud (Amazon EC2) wysyła zapytanie o nazwę domeny skojarzoną ze znanym serwerem dowodzenia i kontroli. Jak pokazano na rysunku 1, gdy GuardDuty wykryje komunikację ze złośliwą domeną, inicjuje serię kroków. Najpierw AWS Step Functions aranżuje odpowiedź naprawczą za pomocą zdefiniowanego przepływu pracy, następnie zapora DNS dodaje podejrzaną domenę do listy odmów lub listy alertów, a na końcu GuardDuty powiadamia operatorów zabezpieczeń o próbie komunikacji.

Rysunek 1: Przegląd rozwiązań wysokiego poziomu

W tym rozwiązaniu wykrycie zagrożeń przez GuardDuty uruchamia automatyczną procedurę naprawczą udokumentowaną w tym artykule. GuardDuty informuje Cię o stanie Twojego środowiska AWS, generując wyniki dotyczące bezpieczeństwa. Każdy wynik GuardDuty ma przypisany poziom ważności i wartość, które odzwierciedlają potencjalne ryzyko, jakie wynik może mieć dla Twojej sieci, zgodnie z ustaleniami naszych inżynierów ds. bezpieczeństwa. Wartość istotności może mieścić się w dowolnym miejscu w zakresie od 0,1 do 8,9, przy czym wyższe wartości wskazują na większe zagrożenie bezpieczeństwa. Aby pomóc w ustaleniu odpowiedzi na potencjalny problem z zabezpieczeniami, który jest wyróżniony przez wynik, GuardDuty dzieli ten zakres na poziomy ważności Wysoki, Średni i Niski. Twórcy zauważyli, że wiele ustaleń GuardDuty opartych na DNS należy do kategorii o wysokim poziomie ważności i wiele razy te ustalenia silnie wskazują na potencjalny kompromis (na przykład aktywność przed ransomware).

W tym artykule autorzy skupiają się w szczególności na następujących rodzajach ustaleń GuardDuty:

• Backdoor:EC2/C&CActivity.B!DNS;
• Impact:EC2/MaliciousDomainRequest.Reputation;
• Trojan:EC2/DNSDataExfiltration.

Zaporę DNS skonfigurowano tak, aby blokowała tylko zdarzenia o wysokim poziomie ważności, wysyłając tylko te domeny na listę odrzuconych. Zapora DNS wysyła pozostałe domeny do listy alertów.

To rozwiązanie wykorzystuje Step Functions i AWS Lambda, dzięki czemu kroki odpowiedzi na incydenty są uruchamiane we właściwej kolejności. Step Functions udostępnia również logikę ponawiania prób i obsługi błędów. Funkcje lambda współdziałają z usługami sieciowymi w celu blokowania ruchu oraz z bazami danych do przechowywania danych o zablokowanych listach domen i AWS Security Hub wyszukującym nazwy zasobów Amazon (ARN).

Jak to działa?

Rysunek nr 2 przedstawia szczegółowo zautomatyzowany proces naprawy.

Rysunek 2: Szczegółowy schemat przepływu pracy

Rozwiązanie realizowane jest w następujący sposób:

1. GuardDuty wykrywa próby komunikacji zawierające podejrzaną domenę. GuardDuty generuje wynik w formacie JSON, który zawiera szczegóły, takie jak identyfikator instancji EC2 (jeśli dotyczy), informacje o koncie, typ wyszukiwania, domena i inne szczegóły. Poniżej znajduje się przykładowy wynik (niektóre pola zostały usunięte dla zwięzłości).

{
  "schemaVersion": "2.0",
  "accountId": "123456789012",
  "id": " 1234567890abcdef0",
  "type": "Backdoor:EC2/C&CActivity.B!DNS",
  "service": {
    "serviceName": "guardduty",
    "action": {
      "actionType": "DNS_REQUEST",
     "dnsRequestAction": {
"domain": "guarddutyc2activityb.com",
"protocol": "UDP",
"blocked": false
      }
    }
  }
}

2. Centrum bezpieczeństwa przyjmuje wyniki wygenerowane przez GuardDuty i konsoliduje je z wynikami z innych usług bezpieczeństwa AWS. Security Hub publikuje również zawartość odkrycia do domyślnej magistrali w Amazon EventBridge. Poniżej znajduje się fragment przykładowego zdarzenia opublikowanego w EventBridge.

{ 
  "id": "12345abc-ca56-771b-cd1b-710550598e37", 
  "detail-type": "Security Hub Findings - Imported", 
  "source": "aws.securityhub", 
  "account": "123456789012", 
  "time": "2021-01-05T01:20:33Z", 
  "region": "us-east-1", 
  "detail": { 
    "findings": [ 
        { "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/guardduty", 
        "Types": ["Software and Configuration Checks/Backdoor:EC2.C&CActivity.B!DNS"], 
        "LastObservedAt": "2021-01-05T01:15:01.549Z", 
        "ProductFields": 
            {"aws/guardduty/service/action/dnsRequestAction/blocked": "false",
            "aws/guardduty/service/action/dnsRequestAction/domain": "guarddutyc2activityb.com"} 
            }
            ]}}

3. EventBridge posiada regułę z wzorcem zdarzenia, który pasuje do zdarzeń GuardDuty, zawierających złośliwą nazwę domeny. Gdy zdarzenie pasujące do wzorca jest publikowane na domyślnej magistrali, EventBridge kieruje to zdarzenie do wyznaczonego celu, w tym przypadku maszyny stanów Step Functions. Poniżej znajduje się fragment kodu AWS CloudFormation, który definiuje regułę EventBridge.

# EventBridge Event Rule - For Security Hub event published to EventBridge:
  SecurityHubtoFirewallStateMachineEvent:
    Type: "AWS::Events::Rule"
    Properties:
      Description: "Security Hub - GuardDuty findings with DNS Domain"
      EventPattern:
        source:
        - aws.securityhub
        detail:
          findings:
            ProductFields:
              aws/guardduty/service/action/dnsRequestAction/blocked:
                - "exists": true
      State: "ENABLED"
      Targets:
        -
          Arn: !GetAtt SecurityHubtoDnsFirewallStateMachine.Arn
          RoleArn: !GetAtt SecurityHubtoFirewallStateMachineEventRole.Arn
          Id: "GuardDutyEvent-StepFunctions-Trigger"

4. Automat stanu funkcji Step Functions pozyskuje szczegóły odnalezienia centrum zabezpieczeń opublikowanego w EventBridge i organizuje odpowiedź na naprawę za pomocą zdefiniowanego przepływu pracy. Rysunek nr 3 przedstawia przepływ pracy automatu stanów.

Rysunek 3: Przepływ pracy automatu stanów AWS Step Functions

5. Pierwsze dwa kroki w maszynie stanów, getDomainFromDynamo i isDomainInDynamo, wywołują funkcję Lambda. CheckDomainInDynamoLambdaFunction, która sprawdza, czy oflagowana domena znajduje się już w tabeli Amazon DynamoDB. Jeśli domena już istnieje w DynamoDB, przepływ pracy nadal sprawdza, czy domena znajduje się również na liście domen i odpowiednio ją dodaje. Jeśli domeny nie ma w DynamoDB, przepływ pracy traktuje ją jako nowy dodatek i dodaje domenę do obu list domen, a także do tabeli DynamoDB.

6. Kolejne trzy kroki w maszynie stanów – getDomainFromDomainList, isDomainInDomainList i addDomainToDnsFirewallDomainList – wywołują drugą funkcję Lambda, która sprawdza i aktualizuje listy domen zapory DNS o nazwę domeny. Rysunek nr 4 przedstawia przykład reguł zapory DNS i powiązanej listy domen.

Rysunek 4: Przykładowe reguły w grupie reguł Zapory DNS

Rysunek nr 5 przedstawia listę domen.

Rysunek 5: Lista domen.

Następny krok w maszynie stanów, updateDynamoDB, wywołuje trzecią funkcję Lambda, która aktualizuje tabelę DynamoDB o domenę, która została właśnie dodana do listy domen. Rysunek nr 6 przedstawia przykładowy wpis domeny, który jest przechowywany w tabeli DynamoDB.

Rysunek 6: Wpis tabeli DynamoDB

7. Krok NotificationSuccess automatu stanu używa tematu Amazon Simple Notification Service (Amazon SNS), aby wysłać wiadomość, że nastąpiło automatyczne blokowanie lub alert.

8. Jeśli wystąpiła awaria w którymkolwiek z poprzednich kroków, automat stanu uruchamia krok notifyFailure. Automat stanowy publikuje komunikat w temacie SNS, że automatyczny przepływ pracy korygowania nie został ukończony i może być wymagana ręczna interwencja.

Wdrażanie rozwiązania i testy.

Aby skonfigurować to rozwiązanie, wykonaj następujące czynności:

1. Zweryfikuj wymagania wstępne na swoim koncie AWS.
2. Wdróż szablon CloudFormation.
3. Utwórz testowe zdarzenie Centrum bezpieczeństwa.
4. Potwierdź wpis na liście domen grupy reguł zapory DNS.
5. Potwierdź powiadomienie SNS.
6. Zastosuj grupę reguł do VPC za pomocą zapory DNS.

Krok 1: Zweryfikuj wymagania wstępne na swoim koncie AWS

Przykładowe rozwiązanie, które autorzy udostępniają w artykule, wymaga aktywacji zarówno GuardDuty, jak i Security Hub na swoim koncie AWS. Jeśli któraś z tych usług nie jest aktywowana na Twoim koncie, dowiedz się więcej z:

• GuardDuty;
• Security Hub.

Krok 2: Wdróż szablon CloudFormation

W kolejnym kroku upewnij się, że wdrażasz szablon na koncie AWS i regionie AWS, w którym chcesz monitorować wyniki GuardDuty i blokować podejrzaną aktywność DNS. W zależności od architektury rozwiązanie można wdrożyć jednorazowo centralnie na koncie zabezpieczeń lub wielokrotnie wdrażać je na wielu kontach.

Aby wdrożyć szablon:

1. Wybierz przycisk Uruchom stos, aby uruchomić stos CloudFormation na swoim koncie:

Uwaga: stos zostanie uruchomiony w regionie Płn. Wirginii (USA-wschód-1). Ukończenie stosu CloudFormation zajmuje około 15 minut. Aby wdrożyć to rozwiązanie w innych regionach AWS, pobierz szablon CloudFormation rozwiązania i wdróż go w wybranym regionie. Zapora sieciowa nie jest obecnie dostępna we wszystkich regionach. Aby uzyskać więcej informacji o tym, gdzie jest dostępny, zobacz listę punktów końcowych usługi.

2. W konsoli AWS CloudFormation wybierz formularz Wybierz Szablon, a następnie kliknij Dalej.

3. Na stronie Określ szczegóły podaj następujące parametry wejściowe. Możesz zmodyfikować wartości domyślne, aby dostosować rozwiązanie do swojego środowiska.

• AdminEmail – adres e-mail, na który będą wysyłane powiadomienia. Musi to być prawidłowy adres e-mail. Nie ma wartości domyślnej.
• DnsFireWallAlertDomainListName – nazwa listy domen zapory DNS zawierającej domeny, które będą tylko ostrzegane, a nie blokowane. Wartość domyślna to DemoAlertDomainListAutoUpdated.
• DnsFireWallBlockDomainListName – nazwa listy domen zapory DNS zawierającej domeny, które będą blokowane. Wartość domyślna to DemoBlockedDomainListAutoUpdated.
• DnsFirewallBlockAction – możesz wybrać NODATA lub NXDOMAIN. NODATA oznacza, że nie ma dostępnej odpowiedzi, jeśli zapytanie DNS z VPC pasuje do domeny na liście zablokowanych domen. NXDOMAIN oznacza, że odpowiedzią jest komunikat o błędzie, który wskazuje, że domena nie istnieje. Wartość domyślna to NODATA.

Rysunek nr 7 przedstawia przykład wartości wprowadzonych na ekranie Parametry.

Rysunek 7: Przykładowe parametry stosu CloudFormation.

4. Po wprowadzeniu wartości dla wszystkich parametrów wejściowych wybierz Dalej.

5. Na stronie Opcje zachowaj wartości domyślne, a następnie wybierz Dalej.

6. Na stronie Recenzja, w sekcji Możliwości zaznacz pole wyboru obok Potwierdzam, że AWS CloudFormation może tworzyć zasoby IAM. Następnie wybierz Utwórz. Rysunek nr 8 pokazuje, jak wygląda monit o potwierdzenie możliwości CloudFormation.

Rysunek 8: AWS CloudFormation capabilities acknowledgement.

Podczas tworzenia stosu sprawdź skrzynkę odbiorczą e-mail odpowiadającą wartości podanej dla parametru AdminEmail address. Poszukaj wiadomości e-mail o temacie „Powiadomienie AWS – Potwierdzenie subskrypcji”. Wybierz link, aby potwierdzić subskrypcję tematu SNS.

Po zmianie pola Status stosu CloudFormation na CREATE_COMPLETE, jak pokazano na rysunku nr 9, rozwiązanie jest zaimplementowane i jest gotowe do testowania.

Rysunek 9: CloudFormation stack completed deployment.

Krok 3: Utwórz testowe zdarzenie Centrum Bezpieczeństwa

Po zakończeniu wdrażania stosu CloudFormation można przetestować funkcjonalność, tworząc zdarzenie testowe w tym samym formacie, który zostałby opublikowany przez Centrum zabezpieczeń.

Aby utworzyć testowe uruchomienie rozwiązania:

1. W AWS Management Console wybierz Usługi, wybierz CloudFormation, a następnie dla Stosu wybierz nazwę stosu podaną w Kroku 2: Wdróż szablon CloudFormation.

2. Na karcie Zasoby dla stosu poszukaj wpisu SecurityHubDnsFirewallStateMachine. Powinien wyglądać tak, jak pokazano na rysunku nr 10.

Rysunek 10: Zasoby stosu CloudFormation

3. Wybierz link. Zostaniesz przekierowany do konsoli Step Functions z już otwartą maszyną stanów. Wybierz Rozpocznij wykonanie.

Rysunek 11: Maszyna stanu AWS Step Functions

4. ułatwić testowanie, autorzy udostępnili plik zdarzeń testowych. Na stronie Rozpocznij wykonywanie w sekcji Dane wejściowe wklej próbkę wyszukiwania C&CActivity.B!DNS, jak pokazano na rysunku nr 12.

Rysunek 12: Przykładowe wejście do wykonania automatu stanów Step Functions.

5. Zanotuj nazwę domeny guarddutyc2activityb.com dla zdalnego hosta zidentyfikowanego w wyniku GuardDuty w zdarzeniu testowym w wierszu 57 próbki. Rozwiązanie powinno blokować lub ostrzegać ruch z tej nazwy domeny w następujących krokach.

6. Wybierz Rozpocznij wykonywanie, aby rozpocząć przetwarzanie zdarzenia testowego.

7. Można teraz śledzić przetwarzanie przez automat stanów zdarzenia testowego. Przetwarzanie powinno zakończyć się w ciągu kilku sekund. Możesz wybrać różne kroki w wizualnym inspektorze wykresów, aby wyświetlić dane wejściowe i wyjściowe. Rysunek nr 13 przedstawia dane wejściowe kroku addDomainToDnsFirewallDomainList, który uruchamia funkcję Lambda, która współdziała z zaporą DNS.

Rysunek 13: Funkcje kroku stan szczegółów kroku maszyny.

Krok 4: Potwierdź wpis w grupie reguł Zapory DNS

Teraz, gdy automat stanowy przetworzył zdarzenie testowe, możesz sprawdzić, czy grupa reguł zapory DNS zablokuje ruch do nazwy domeny zidentyfikowanej w wyniku GuardDuty.

Aby zweryfikować wpisy w grupie reguł Zapory DNS:

1. W konsoli zarządzania AWS wybierz Usługi, a następnie wybierz VPC. W sekcji Zapora DNS na lewym pasku nawigacyjnym wybierz Grupy reguł Zapory DNS.

2. Wybierz grupę reguł demoDnsFirewallRuleGroup utworzoną przez rozwiązanie, a zobaczysz reguły pokazane na rysunku nr 14.

Rysunek 14: Wybierz regułę zapory DNS.

3. Wybierz listę domen skojarzoną z regułą BLOKUJ. Upewnij się, że zostały utworzone reguły blokujące ruch ze źródła i do domeny określonej w zdarzeniu testowym. Lista domen powinna wyglądać podobnie do pokazanej na rysunku nr 15.

Rysunek 15: Sprawdź, czy domena została dodana do listy zablokowanych domen.

Krok 5: Potwierdź powiadomienia SNS

W tym kroku zobaczysz powiadomienie SNS, które zostało wysłane na skonfigurowany adres e-mail.

Aby potwierdzić powiadomienie SNS:

• Przejrzyj skrzynkę odbiorczą e-mail pod kątem wartości podanej dla parametru AdminEmail i poszukaj wiadomości z tematem „Wiadomość powiadomienia AWS”. Treść wiadomości od SNS powinna być podobna do poniższej.

{"Blocked":"true","Input":{"ResponseMetadata":{"RequestId":"HOLOAAENUS3MN9B0DS6CO8BF4BVV4KQNSO5AEMVJF66Q9ASUAAJG","HTTPStatusCode":200,"HTTPHeaders":{"server":"Server","date":"Wed, 17 Nov 2021 08:20:38 GMT","content-type":"application/x-amz-json-1.0","content-length":"2","connection":"keep-alive","x-amzn-requestid":"HOLOAAENUS3MN9B0DS6CO8BF4BVV4KQNSO5AEMVJF66Q9ASUAAJG","x-amz-crc32":"2745614147"},"RetryAttempts":0}}}

Krok 6. Zastosuj grupę reguł do VPC za pomocą zapory DNS

W ramach wdrożenia szablonu CloudFormation utworzono dla Ciebie dwie testowe sieci VPC, aby zademonstrować, że możesz przypisać pojedynczą grupę reguł zapory DNS do wielu sieci VPC. Możesz też powiązać tę grupę reguł z istniejącym środowiskiem VPC, które Cię interesuje. Aby dowiedzieć się, jak wykonać to zadanie, zobacz „Managing associations between your VPC and Route 53 Resolver DNS Firewall rule group”. W celu zapewnienia widoczności zapytań DNS i celów debugowania szablon tworzy grupy dzienników, które gromadzą dzienniki zapytań usługi DNS Resolver.

Po pomyślnym przetestowaniu danej próbki emulującej C&CActivity.B!DNS możesz powtórzyć kroki od 3 do 6 dla próbki odnajdującej MaliciousDomainRequest.Reputation i próbki odnajdującej DNSDataExfiltration.

Te próbki są dostarczane dla Twojej wygody, a działanie blokujące zobaczysz w ciągu kilku minut. Alternatywnie możesz użyć innych sposobów testowania, co może zająć około godziny na wykonanie działania blokującego. Aby zainicjować aktywność DNS C&C, możesz wysłać żądanie DNS ze swojej instancji (używając dig dla Linuxa lub nslookup dla Windows) przeciwko domenie testowej guarddutyc2activityb.com. Alternatywnie możesz skorzystać z GuardDuty Tester, który generuje nieautoryzowane zdarzenia DNS C&C i eksfiltracji DNS.

Aby pójść o krok dalej w tym rozwiązaniu, możesz zaimplementować automatyczne przedawnianie domen, które są dodawane do listy domen. Jednym ze sposobów, aby to zrobić, jest użycie funkcji „Czas życia” w DynamoDB i regularne uzupełnianie listy domen z DynamoDB. Zaletą tego jest to, że jeśli złośliwy charakter domeny na liście domen zmieni się z biegiem czasu, lista będzie aktualizowana w tym czasie i podczas procesu ponownego zapełniania.

Kwestie do rozważenia:

Należy pamiętać o kilku kwestiach dotyczących Zapory DNS:

• Zapora DNS i zapora sieciowa AWS współpracują ze sobą w celu poprawy możliwości filtrowania domen w ruchu HTTP(S). Lista domen skonfigurowana w Zaporze sieciowej powinna odzwierciedlać listę domen skonfigurowaną w Zaporze DNS.
• Filtry zapory DNS oparte na nazwie domeny. Nie tłumaczy tej nazwy domeny na adres IP, który ma zostać zablokowany.
• Najlepszą praktyką jest blokowanie ruchu wychodzącego do portu 53 za pomocą list kontroli dostępu do sieci (sieci ACL) lub zapory sieciowej, aby GuardDuty mógł monitorować zapytania DNS.
• Zapora DNS filtruje zapytania DNS do Amazon Route 53 Resolver (znanego również jako AmazonProvidedDNS lub VPC .2 Resolver) w VPC. Dlatego w przypadku ruchu opuszczającego VPC zaleca się użycie zapory DNS wraz z zaporą sieciową, której można użyć do zabezpieczenia ruchu, który nie jest kierowany do rozwiązania Amazon Route 53 Resolver. Zapora sieciowa może również blokować nazwy domen istniejące w ruchu sieciowym opuszczającym Amazon VPC, takie jak nagłówki HTTP HOST, pola TLS Server Name Indication (SNI) itd.
• Zaporę sieciową można użyć do blokowania zewnętrznych zaszyfrowanych usług DNS, aby nie można było ich używać do obchodzenia zasad zapory DNS.

Wnioski

Za pomocą tego artykułu dowiedziałeś się, jak automatycznie blokować złośliwe domeny za pomocą zapory Route 53 Resolver DNS Firewall i GuardDuty. Możesz użyć tego przykładowego rozwiązania, aby automatycznie blokować komunikację z podejrzanymi hostami wykrytymi przez GuardDuty i możesz zastosować te blokady we wszystkich skonfigurowanych zaporach zapory DNS na swoim koncie.

Cały kod tego rozwiązania jest dostępny w serwisie GitHub. Twórcy zachęcają do zabawy z kodem, mając nadzieję, że pomoże Ci to dowiedzieć się więcej o automatycznym naprawianiu bezpieczeństwa. Możesz dostosować kod, aby lepiej pasował do Twojego unikalnego środowiska lub rozszerzyć kod o dodatkowe kroki.

Jeśli masz pytania na temat korzystania z tego rozwiązania, rozpocznij wątek na Route 53 Resolver forum lub GuardDuty forums lub skontaktuj się ze wsparciem AWS.

źródło: AWS