Skonfiguruj Sophos DNS Protection z Sophos Firewall

Sophos DNS Protection sprawdza zapytania DNS za pośrednictwem usługi chmurowej oraz zarządza politykami i raportami w Sophos Fusion (dawniej Sophos Central). Pozwala blokować złośliwe domeny, phishing, cele Command-and-Control i niepożądane kategorie, zanim klient nawiąże właściwe połączenie.

W przypadku Sophos Firewall najczytelniejsza konfiguracja standardowa wygląda zwykle tak: klienci używają firewalla jako resolvera DNS, firewall przekazuje publiczne zapytania do DNS Protection, a domeny wewnętrzne trafiają przez DNS Request Routes do wewnętrznych serwerów DNS.

DNS Protection nie zastępuje Web Protection, Threat Feeds ani NDR i Active Threat Response. Uzupełnia te mechanizmy na poziomie DNS.

Ten przewodnik celowo koncentruje się na Sophos Firewall: wartościach Fusion, przekazywaniu DNS, Request Routes, DHCP, NAT, odbiorze i wycofaniu. Przewodnik konfiguracji sieci opisuje architekturę niezależną od producenta i reguły dostępu, a przewodnik Locations — pełny cykl życia lokalizacji.

Decyzja i architektura docelowa

DNS jest usługą podstawową. Jeżeli resolver jest wolny, niestabilny lub zbyt restrykcyjny, użytkownicy szybko odbierają problem jako ogólną awarię sieci. DNS Protection należy więc stosować tylko wtedy, gdy korzyści z polityk Fusion, kategorii, logów lub ochrony klientów mobilnych uzasadniają dodatkową obsługę.

Według Avanet szybkie, nadmiarowe resolvery wraz z dobrze utrzymanymi Threat Feeds są bardziej pragmatycznym rozwiązaniem dla wielu klasycznych instalacji firewalla. DNS Protection sprawdza się szczególnie, gdy:

• zapytania DNS mają być widoczne w Sophos Fusion.
• lokalizacje wymagają różnych polityk DNS.
• kategorie mają być blokowane już podczas rozpoznawania nazw.
• klienci nie mogą używać dowolnych publicznych resolverów.
• zarządzane endpointy Windows mają być chronione także poza siecią firmową.

Najpierw wybierz wersję: od SFOS 23.0 używaj opisanej poniżej zintegrowanej ścieżki DoH z przypisaniem firewalla. Odniesienia do publicznego źródłowego IP, DDNS, dwóch statycznych forwarderów i przypisania Location opisują ścieżkę Traditional DNS na SFOS 22 i starszych, a nie wymagania nowej ścieżki firewalla. Endpoint Secure DNS pozostaje oddzielną ścieżką.

Ścieżka Traditional DNS na SFOS 22 i starszych wygląda następująco:

1. Sophos Fusion zna lokalizację jako Location.
2. Sophos Fusion udostępnia dwa adresy IP DNS Protection.
3. Sophos Firewall używa obu adresów jako DNS Forwarder.
4. DNS Request Routes wysyłają strefy wewnętrzne do wewnętrznych serwerów DNS.
5. DHCP przekazuje klientom firewall jako resolver.
6. Opcjonalna reguła NAT wymusza tę ścieżkę dla klasycznego ruchu DNS.
7. Sophos Fusion rejestruje i ocenia publiczne zapytania DNS.

Należy rozróżnić dwie metody:

• Traditional DNS over IPv4: dla firewalli, routerów i lokalnych resolverów. Sophos przypisuje zapytania do Location na podstawie publicznego źródłowego adresu IP lub FQDN DDNS.
• Secure DNS: DNS over HTTPS (DoH) dla zgodnych urządzeń. Sophos Endpoint może zarządzać tą ścieżką na obsługiwanych endpointach Windows; Windows i macOS można również skonfigurować ręcznie do Secure DNS.

Niestandardowa Location może obsługiwać obie metody. Dla przekazywania przez firewall trzeba włączyć Traditional DNS i podać publiczny adres IP lub FQDN.

Cztery ścieżki DNS to nie to samo

Podczas diagnostyki trzeba wiedzieć, gdzie przetwarzane jest zapytanie:

• Usługa DNS Protection: resolver w chmurze ocenia publiczne zapytania według Filtering Policy rozpoznanej Location. Raporty znajdują się w Sophos Fusion, a nie w Log Viewer firewalla.
• Firewall jako resolver: klient odpytuje adres interfejsu firewalla przez UDP lub TCP 53. Lokalna usługa DNS wybiera DNS Request Route albo forwardery z Network > DNS. W Administration > Device access usługa DNS musi być dozwolona dla strefy źródłowej. Reguła firewalla nie udostępnia tej usługi lokalnej.
• Tranzyt DNS: gdy klient odpytuje bezpośrednio publiczny resolver, firewall tylko przekazuje ruch. Obowiązuje reguła firewalla, ale nie DNS Request Routes. Log reguły potwierdza więc transport, a nie przetworzenie przez DNS Protection.
• Endpoint DNS Protection: Sophos Endpoint przechwytuje obsługiwane zapytania Windows i wysyła je przez HTTPS do Secure DNS Location. Reguła NAT dla portu 53 i Request Routes firewalla nie należą do tej ścieżki. Lokalnego DNS używają tylko wykluczone domeny lub opcjonalna ponowna próba NXDOMAIN.

W zalecanym modelu klienci używają resolvera firewalla. Bezpośredni tranzyt do adresów DNS Protection nie jest równoważny, gdy strefy wewnętrzne wymagają Request Routes.

Przed rolloutem należy ustalić licencję, publiczne adresy wyjściowe, wewnętrzne strefy DNS, serwery DHCP oraz właścicieli polityk i wyjątków. Xstream Protection obejmuje samodzielny DNS Protection dla firewalla. Workspace Protection obejmuje DNS Protection dla endpointów; na urządzeniach musi być zainstalowany Sophos Endpoint. Obie licencje obejmują DoH.

Aby DNS Protection pojawił się jako produkt w Sophos Fusion, firewall z licencją Xstream musi być połączony z tym samym kontem Fusion. Licencję sprawdza się w Administration > Licensing na firewallu lub na stronie Firewall Licensing w Sophos Fusion. Sophos podaje trzy metody: rejestrację podczas instalacji, przejęcie numeru seryjnego w Firewall Licensing albo włączenie zarządzania przez Sophos Fusion w WebAdmin.

Decyzje licencyjne i uprawnienia Fusion należą do istniejących procesów licencjonowania Sophos Fusion oraz ról administracyjnych. Właściciel firewalla potrzebuje dostępu do DNS Protection i zatwierdzonych wartości tenantu, ale nie powinien rozszerzać ról w ramach tej zmiany.

Predefiniowana Location Default może być używana do Secure DNS i przypisywana do polityk, ale nie można jej edytować ani usunąć. Dozwolone jest maksymalnie 50 Locations i 100 publicznych wpisów IPv4/FQDN na Location. Locations należy więc tworzyć według lokalizacji i wyjścia internetowego, a nie dla każdego VLAN-u.

SFOS 23.0: konfiguracja i migracja DNS Protection przez DoH

Od SFOS 23.0 zintegrowany przełącznik DNS Protection korzysta z DNS over HTTPS (DoH). Filtering Policy przypisuje się do obiektu firewalla, a nie do poprzedniej Location IP/FQDN. Wymagane są Xstream Protection i rejestracja firewalla w Sophos Fusion; w HA muszą być zarejestrowane oba firewalle. Przed zmianą udokumentuj poprzednie ustawienia DNS, przypisanie polityki i wartości Location potrzebne do wycofania.

Przed migracją: Sprawdź, czy dotychczasowa Location obsługuje wyłącznie ścieżkę DNS tego firewalla, czy jest również używana przez inne resolvery lub Endpoint Secure DNS. Jeśli jest współdzielona, nie usuwaj Location z dotychczasowej Filtering Policy ani nie usuwaj samej Location. Opisane poniżej zastąpienie wykonaj dopiero po osobnym wyjaśnieniu i zachowaniu przypisania polityki dla pozostałych korzystających z niej resolverów i urządzeń; do tego czasu wstrzymaj migrację.

Włączenie ochrony i przypisanie polityki

1. Na firewallu włącz DNS Protection w Network > DNS.
2. Świadomie zdecyduj o użyciu Fall back to DNS server: gdy opcja jest aktywna, trzeba skonfigurować serwer DNS w DNS server settings. Bez tej opcji nie można tam konfigurować serwerów DNS przy włączonym DNS Protection. Zewnętrzny resolver awaryjny zwiększa dostępność, ale może ominąć filtrowanie i rejestrowanie DNS Protection, gdy usługa jest nieosiągalna. Udokumentuj decyzję i resolver zastępczy; DoH do dowolnego dostawcy nie oznacza automatycznie DNS Protection.
3. W Sophos Fusion otwórz My Products > DNS Protection > Policies > Filtering policies. Dla nowej konfiguracji wybierz Add policy, zaznacz firewall w Locations and firewalls > Available i przenieś go do Assigned to this policy. Type musi wskazywać Firewall; nazwa zawiera etykietę firewalla i numer seryjny. Ustaw wymagane filtry w Settings i zapisz politykę.

Zastąpienie istniejącego przypisania Traditional DNS

Po aktualizacji i włączeniu DNS Protection otwórz istniejącą Filtering Policy. W Locations and firewalls przenieś Location utworzoną dla tego firewalla z Assigned to this policy do Available. Następnie przenieś firewall z Available do Assigned to this policy i wybierz Save. Starą Location można usunąć dopiero po zapisaniu. Avanet zaleca zachowanie jej do pomyślnego odbioru pilotażu; nie usuwaj jej, jeśli inne resolvery lub urządzenia nadal jej potrzebują. Ta migracja nie dotyczy resolverów innych producentów ani Endpoint Secure DNS.

Weryfikacja pilotażu i wycofanie

Klienci nadal używają firewalla jako resolvera. Kolejne kroki dotyczące DNS Request Routes, DHCP i opcjonalnego przekierowania NAT portu 53 mają zastosowanie także tutaj; nie wykonuj dodatkowo starych kroków Location i statycznych forwarderów. W Network > DNS > Test name resolution wpisz publiczną nazwę w Hostname or IP address i wybierz Test connection. Sprawdź serwer, użyty protokół, wynik i czas odpowiedzi. Z klienta pilotażowego sprawdź też nazwy wewnętrzne, wyszukiwanie wsteczne i nieszkodliwą domenę celowo blokowaną przez politykę. Sprawdź przypisanie firewalla w Fusion i raporty DNS Protection; samo prawidłowe rozpoznanie nazwy nie dowodzi skuteczności Filtering Policy. Nie rozszerzaj wdrożenia przed pomyślnym zakończeniem pilotażu. Ten przewodnik nie był testowany w laboratorium na firewallu SFOS 23.

Aby wycofać zmianę, najpierw ponownie przypisz zachowaną Location Traditional DNS do poprzedniej polityki, usuń przypisanie firewalla i wybierz Save. Następnie wyłącz DNS Protection na firewallu i przywróć udokumentowaną poprzednią konfigurację DNS w DNS server settings. Są to pola SFOS 23, a nie nazwy pól SFOS 22 pokazane poniżej. Zachowaj Request Routes i niezmienione wartości DNS klientów, a potem ponownie sprawdź rozpoznawanie nazw publicznych i wewnętrznych oraz filtrowanie. Jeśli Location została już usunięta, odtwórz ją z udokumentowanych wartości przed tym wycofaniem.

XML API: udokumentowane zmiany, ale bez bezpiecznej receptury do skopiowania

Dokumentacja XML API SFOS 23 dla DNS List dodaje DNSProtection z Enabled i Fallback, DNSProtocol, DNSOverHTTPS z DNSServer1 do DNSServer3 oraz URL, IPv4Address i IPv6Address, a także FallbackToUnencryptedDns i DNSSecProtection. Komentarze w przykładzie uzależniają ustawienia IPv4/IPv6 od UnencryptedDNS, a blok DoH od DNSOverHTTPS; dla DoH wymagany jest DNSServer1, a dla każdego serwera wskazano adres IPv4 albo IPv6. Te warunki zapisane w komentarzach dokumentacji nie stanowią w pełni wyjaśnionej ani przetestowanej tutaj receptury API.

Dwie sprzeczności pozostają nierozstrzygnięte: SFOS 22 nazywa selektor DNSQueryConfiguration i podaje wartości tekstowe. Tabela SFOS 23 podaje natomiast DNS Query Configuration oraz 0, 1, 2, 3, bez pokazania w przykładzie tagu XML ani przyporządkowania tych wartości. Komentarz do DNSProtocol jednocześnie określa pole jako wymagane i podaje UnencryptedDNS jako wartość przy jego pominięciu. Nie można z tego wywnioskować ani tagu ze spacjami, ani numerycznego przyporządkowania, bezpiecznego pominięcia, automatycznej zgodności czy bezpiecznej wartości domyślnej.

Aktualna bezpieczna ścieżka: wyraźnie nie udostępniamy tutaj niejednoznacznej receptury dotyczącej selektora lub pominięcia pola. W SFOS 23 należy używać opisanej wyżej ścieżki WebAdmin w Network > DNS, świadomie zdecydować o protokole i fallbacku oraz w pilotażu sprawdzić zapisane ustawienia, faktycznie używany protokół, przypisanie polityki do firewalla, rozwiązywanie nazw wewnętrznych i skuteczność filtrowania. Jeśli konieczna jest automatyzacja, należy ją wstrzymać do czasu wyjaśnienia tych pól przez producenta dla konkretnej wersji; działający UI nie potwierdza schematu XML ani REST.

DNSProtection/Fallback i DNSOverHTTPS/FallbackToUnencryptedDns to odrębne ustawienia: pierwsze dotyczy zastępczego rozwiązywania nazw przy nieosiągalnej usłudze DNS Protection, drugie — przejścia z DoH na nieszyfrowany DNS. Utrata ochrony lub widoczności oraz utrata szyfrowania transportu to różne ryzyka. Nie należy ich utożsamiać ani przyjmować niepotwierdzonych domyślnych wartości Boolean; obie decyzje trzeba jawnie zweryfikować. DoH do dowolnego dostawcy nie oznacza Sophos DNS Protection, a DNSSecProtection nie jest ani DoH, ani przypisaniem Filtering Policy. Z tych niejasności nie tworzymy wykonywalnego XML globalnej konfiguracji DNS.

XML API: SFOS 22 — DNS List; SFOS 23 — DNS List.

Konfiguracja DNS Protection

Traditional DNS na SFOS 22 i starszych: kroki 1–3 opisują poprzednią ścieżkę IP/FQDN. Kroki 4–6 pozostają istotne również dla zintegrowanej ścieżki SFOS 23.

1. Utworzenie Location w Sophos Fusion

My Products > DNS Protection > Locations

1. Wybierz Add i wpisz unikatową nazwę w Name; w Description najlepiej podać wyjście internetowe i właściciela.
2. W Connection method włącz Traditional DNS over IPv4.
3. W IPv4 addresses or FQDNs wpisz publiczny adres WAN lub stabilny FQDN DDNS. Każdą wartość potwierdź Enter lub Tab.
4. Przy Multi-WAN uwzględnij wszystkie używane adresy wyjściowe. Adresy wykryte automatycznie nie aktualizują się same po późniejszej zmianie.
5. Wybierz Save.

Prywatne adresy IP są niedozwolone. Sophos musi rozpoznać publiczny źródłowy adres IP, przez który zapytanie dociera do usługi. Dla adresów dynamicznych Sophos regularnie sprawdza nazwę DDNS, ale po zmianie może wystąpić krótka przerwa. W Cloudflare rekord DDNS musi mieć ustawienie DNS only i nie może przechodzić przez proxy.

Przy CGNAT lub współdzielonym adresie operatora adres zostaje przypisany do konta klienta, które zarejestruje go jako pierwsze. FQDN nie rozwiązuje problemu, jeśli wskazuje ten sam współdzielony adres IP; potrzebny jest unikatowy publiczny adres IP.

2. Pobranie adresów IP DNS Protection

My Products > DNS Protection > Installers

W sekcji Installers, obok IP addresses, dostępne są dwa adresy IP DNS Protection. Użyj Copy, aby skopiować obie wartości z własnego tenantu Fusion, a następnie użyj ich jako DNS 1 i DNS 2. Zewnętrzny resolver jako dodatkowy fallback może ominąć ochronę i rejestrowanie.

Adresy IP są dostępne również przy aktywnym Secure DNS. Dla ścieżki firewalla kluczowe jest, aby w Location skonfigurować także Traditional DNS z publicznym adresem wyjściowym.

Na tej samej stronie przycisk Copy obok URL pozwala skopiować adres testowy. Jeśli po otwarciu go w przeglądarce pojawi się komunikat powitalny DNS Protection, ścieżka resolvera jest skonfigurowana prawidłowo. W późniejszej diagnostyce szczególnie przydatny jest adres https://dns.access.sophos.com: jeśli tylko ta nazwa nie jest rozpoznawana lub przeglądarka zamiast komunikatu powitalnego wyświetla błąd, wskazuje to na wyciek DNS albo przekierowanie przez operatora.

3. Konfiguracja firewalla jako DNS Forwarder

Network > DNS

1. Wybierz Static DNS.
2. Wprowadź dwa adresy Fusion w DNS 1 i DNS 2.
3. Pozostaw DNS 3 puste, o ile nie istnieje świadomie udokumentowany wyjątek.
4. Dla IPv6 również wybierz Static DNS i nie wpisuj serwerów DNS IPv6.
5. Włącz Choose IPv4 DNS server over IPv6.
6. Wybierz Apply.

Usługa działa przez IPv4, ale rozpoznaje również rekordy AAAA, a więc cele IPv6. Przy SD-WAN, failover lub Policy Routing rzeczywista ścieżka wyjściowa musi odpowiadać publicznemu adresowi zapisanemu w Location.

Od SFOS 21.5 DNS Protection status widget w Control center pokazuje stan połączenia. Do prowadzonej konfiguracji i diagnostyki dostępny jest także Sophos Assistant. Widget jest szybkim wskaźnikiem operacyjnym; przy odbiorze całej ścieżki bardziej miarodajne są prawidłowe otwarcie adresu testowego i raporty DNS Protection. Jak weryfikować strony pomocy i odróżniać prezentacje objaśniające od procedur, w których faktycznie wprowadza się konfigurację, pokazuje artykuł Bezpieczne korzystanie z Sophos Assistant.

4. Przekazywanie domen wewnętrznych

Network > DNS
DNS request route > Add

DNS Protection nie rozpoznaje stref wewnętrznych. Dlatego dla Active Directory, aplikacji wewnętrznych i wyszukiwania wstecznego potrzebne są DNS Request Routes.

Przykład:

• Host/domain name: firma.local lub corp.example.com
• Target servers: wewnętrzne kontrolery domeny lub serwery DNS, w wymaganej kolejności; jedna trasa obsługuje maksymalnie osiem adresów IP

corp.example.com jest domeną dokumentacyjną i trzeba ją zastąpić rzeczywiście wewnętrzną strefą autorytatywną. Nie kieruj całej example.com, jeśli wewnętrzna jest tylko jedna podstrefa. Jeśli wyszukiwanie w pamięci podręcznej pasującej trasy się nie powiedzie, firewall nie odpytuje dodatkowo publicznych forwarderów ani serwerów głównych. Kolejność i dostępność Target Servers są więc elementem odporności.

Pełna procedura znajduje się w artykule Konfiguracja DNS Request Routes na Sophos Firewall. Publicznie zarejestrowane domeny wewnętrzne należy również dopuścić na liście domen, jeżeli blokuje je kategoria taka jak Parked Domains.

5. Kierowanie klientów do firewalla przez DHCP

Network > DHCP

1. W Server edytuj odpowiedni serwer DHCP i zanotuj adres wybranego Interface.
2. W DNS server wyłącz Use device’s DNS settings.
3. Ustaw wewnętrzny adres interfejsu DHCP firewalla jako Primary DNS.
4. Zapisz, odnów dzierżawę klienta testowego i sprawdź faktycznie używany resolver.

Sophos pokazuje jako przykład adres firewalla jako Primary DNS oraz adres DNS Protection jako Secondary DNS. Klienci nie zawsze traktują jednak drugi wpis wyłącznie jako serwer awaryjny. Bezpośrednie zapytania do DNS Protection omijają DNS Request Routes firewalla. W sieciach z Active Directory lub strefami wewnętrznymi nadmiarowość należy więc rozwiązać w ścieżce resolvera, a nie przez dowolny drugi DNS klienta.

6. Zapobieganie bezpośredniemu omijaniu DNS

Najpierw w Administration > Device access sprawdź, czy DNS jest włączony dla każdej strefy źródłowej. Następnie opcjonalna reguła DNAT może przekierować klasyczny ruch DNS do firewalla:

Rules and policies > NAT rules > IPv4 > Add NAT rule > New NAT rule

• Rule name: na przykład redirect-client-dns-to-firewall
• Rule position: Top
• Original source: odpowiednie sieci wewnętrzne
• Original destination: wychodząca grupa hostów lub Internet IPv4
• Original service: DNS
• Translated destination: wewnętrzny adres IP firewalla
• Translated source / Translated service: Original
• Inbound interfaces: tylko interfejsy odpowiadające źródłom wewnętrznym, nigdy WAN

Internet IPv4 ma szeroki zakres i nadaje się tylko wtedy, gdy przekierowane mają być wszystkie klasyczne zewnętrzne cele DNS. Maksymalnie zawęź sieci źródłowe i Inbound Interfaces. Wewnętrzne serwery DNS i urządzenia specjalne wymagają udokumentowanych wyjątków umieszczonych przed tą regułą. Reguła obejmuje tylko DNS na UDP/TCP 53. DoH i DoT wymagają osobnych kontroli w przeglądarce, MDM, endpoincie lub Web Policy. Przed aktywacją przetestuj wewnętrzne rozpoznawanie nazw, VPN i sieć gościnną. Mechanizm reguł opisano dokładniej w Zrozumienie NAT na Sophos Firewall.

Polityki, endpointy i strony blokowania

Filtering Policy i listy domen

Filtering Policy przypisuje się do jednej lub kilku Locations w DNS Protection > Policies > Filtering policies. Dla Location może być aktywna tylko jedna Filtering Policy. Oprócz kategorii można definiować listy domen i opcje takie jak Safe Search.

W przypadku ścieżki Traditional DNS ten artykuł sprawdza przypisanie do właściwej Location; w przypadku zintegrowanej ścieżki SFOS 23 — przypisanie obiektu Firewall do oczekiwanej Filtering Policy. Przypisanie Location i zrzut ekranu w tej sekcji przedstawiają dotychczasową ścieżkę. Tworzenie, wyjątki, Safe Search, pilotaż i wycofanie zmian polityki opisuje Konfiguracja Filtering Policies Sophos DNS Protection.

Listy domen powinny mieć cel, Owner i datę przeglądu. Allow list zastępuje zwykłe decyzje kategorii, ale nie klasyfikację SophosLabs jako Threat lub Security Risk. Dozwolona domena może nadal być blokowana, jeśli jej cel CNAME należy do zablokowanej kategorii.

W przypadku kategorii szczególnie ważne są następujące decyzje:

• Infrastructure: zwykle zezwalaj na Content delivery, CRL i OCSP, ponieważ mogą od nich zależeć aktualizacje i weryfikacja certyfikatów.
• Threats and liabilities: zazwyczaj blokuj kategorie takie jak Phishing, Malware, Newly Registered Websites lub Anonymizers i rozwiązuj False Positives w sposób ukierunkowany.
• Data loss: oceniaj pamięć chmurową i pocztę WWW zgodnie z wymaganiami DLP i compliance.
• Uncategorized: nie blokuj bezwarunkowo; nowe legalne lub wewnętrzne usługi mogą czasowo nie mieć kategorii.
• Produktywność, Social Media i przepustowość: podejmuj decyzję według sieci i potrzeb firmy, nie jako ogólną regułę bezpieczeństwa.

Endpoint DNS Protection

Endpoint DNS Protection Policy jest przeznaczona dla zarządzanych endpointów Windows, które mają być chronione także poza siecią firmy. Sophos Endpoint przechwytuje zapytania DNS i wysyła je przez HTTPS do Secure-DNS-Location. Powiązana Filtering Policy określa właściwe filtrowanie.

Przewodnik Endpoint DNS Protection obejmuje konfigurację, wewnętrzne Domain Exclusions i przypisanie. NAT, Request Routes i DHCP firewalla nie zastępują tej ścieżki endpointu.

Polityka nie obsługuje obecnie Windows Server ani macOS. Dla macOS istnieje osobna ścieżka ręcznego profilu Secure DNS; Linux, urządzenia mobilne i specjalne również wymagają własnego rozwiązania sieciowego, VPN lub MDM. Przed rolloutem sprawdź aktualne wymagania pakietu Endpoint w Sophos Fusion, ponieważ mogą szybko się zmieniać.

Strefy wewnętrzne są jawnie utrzymywane jako Domain Exclusions w Endpoint Policy. Jest to bardziej niezawodne niż ponowienie po NXDOMAIN i zapobiega zbędnym zapytaniom zewnętrznym. DNS Protection Root Certificate może być automatycznie dystrybuowany na obsługiwane endpointy.

Root Certificate i strona blokowania

W przypadku stron blokowania HTTPS klienci muszą ufać certyfikatowi DNS Protection Root Certificate. Nie jest to ten sam certyfikat co urząd CA firewalla dla TLS Inspection; jego dystrybucję opisano w artykule Dystrybucja certyfikatu CA Sophos Firewall dla TLS Inspection.

Informacje o sprawdzaniu, wdrażaniu, rotacji i usuwaniu zawiera artykuł Wdrażanie certyfikatu głównego Sophos DNS Protection.

Certyfikat i test konfiguracji znajdują się w DNS Protection > Installers. Ponadto dostępna musi być domena blockpage.dnsprotection.sophos.com.

W Web Proxy Mode funkcja Pharming Protection może zakłócać stronę blokowania. Zanim globalnie wyłączysz ochronę, zezwól na domenę strony za pomocą konkretnej reguły firewalla HTTP/HTTPS bez Web Filter i ustaw Do not decrypt w regule TLS.

Pilotaż, rollout i odbiór

Przypisanie Location i pola Location w raportach w poniższej liście dotyczą Traditional DNS lub danych endpointów. Dla zintegrowanej ścieżki SFOS 23 używaj zamiast nich przypisania firewalla i opisanych wyżej kontroli pilotażu SFOS 23; nie zakładaj na tej podstawie, że nazwy pól raportów lub Live Discover pozostały bez zmian.

Najpierw aktywuj DNS Protection w małej sieci pilotażowej. Udokumentuj strefy wewnętrzne, wyszukiwania wsteczne i usługi krytyczne, skonfiguruj DNS Request Routes i przygotuj jasny rollback do poprzednich resolverów. Sieci serwerów wymagają osobnego okna testowego, ponieważ licencjonowanie, aktualizacje, CRL/OCSP, backup lub komunikacja klastra mogą zależeć od DNS.

Przed szerokim rolloutem muszą przejść następujące kontrole. Polecenia klienta nie były tu wykonywane w środowisku SFOS 22; są to polecenia diagnostyczne tylko do odczytu. Dowodem działania produktu są test konfiguracji i raporty Fusion:

• publiczna domena jest rozpoznawana przez przewidziany resolver.
• wewnętrzna domena AD i wyszukiwanie wsteczne działają przez DNS Request Routes.
• test konfiguracji w Installers pokazuje oczekiwane potwierdzenie.
• nieszkodliwa domena celowo zablokowana polityką testową jest blokowana i przypisana do właściwej Location.
• w DNS Protection > Logs & Reports raport DNS usage by source pokazuje Location po oczekiwanym opóźnieniu, a dla danych endpoint również użytkownika i urządzenie.
• sieć gościnna używa planowanej ścieżki DNS, ale nie wewnętrznych serwerów DNS.
• klient VPN otrzymuje właściwe resolvery i sufiksy DNS.
• Browser DoH, Private Relay ani lokalne profile nie omijają niespodziewanie kontroli.
• rollback do poprzedniego resolvera został przetestowany lub jasno udokumentowany.

Polecenia testowe dla klientów

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux z systemd-resolved i zainstalowanym dig:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Zastąp <firewall-ip> adresem wewnętrznego interfejsu Sophos Firewall. Jeżeli jawne zapytanie do firewalla działa, a zwykłe nie, przyczyna zwykle leży w DHCP, VPN, Browser DoH lub lokalnej konfiguracji DNS. Polecenia pokazują resolver klienta i jego odpowiedź, ale same nie dowodzą, którego upstream używa firewall.

Sprawdzenie strefy wewnętrznej:

dig @<firewall-ip> interner-host.corp.example.com

Zapytanie musi dotrzeć do wewnętrznego serwera DNS przez odpowiednią DNS Request Route.

Troubleshooting

Kontrole Location, źródłowego IP i upstream UDP/TCP 53 w tej sekcji dotyczą Traditional DNS. Dla zintegrowanej ścieżki SFOS 23 sprawdź najpierw DNS Protection, przypisanie firewalla do polityki i użyty protokół przez Test name resolution. Stosuj opisane wyżej kontrole pilotażu SFOS 23; nie dodawaj starych forwarderów IPv4.

Location nie pojawia się w Sophos Fusion

Sprawdź publiczny adres WAN, FQDN DDNS i rzeczywiste wyjście Multi-WAN. Nieskonfigurowany źródłowy adres IP może zostać odrzucony przez usługę DNS Protection. Przy adresach dynamicznych sprawdź, czy FQDN wskazuje z zewnątrz aktualny adres IP; rekordy Cloudflare muszą mieć ustawienie DNS only.

W My Environment > Alerts pojawiają się nieprawidłowe FQDN i konflikty IP. Przy CGNAT lub współdzielonych wyjściach proxy/VPN pierwszeństwo ma Location zarejestrowana jako pierwsza. Inny FQDN wskazujący ten sam adres IP nie zmienia przypisania.

Brak ruchu DNS mimo prawidłowej Location

Ten objaw obejmuje również komunikaty No queries received from locations w dashboardzie oraz DNS Protection: Connectivity Error w Control center. Najpierw otwórz https://dns.access.sophos.com. Jeśli komunikat powitalny się nie pojawi, przetestuj przez UDP i TCP 53 oba adresy tenantu widoczne w Installers oraz sprawdź rzeczywiste wyjście WAN.

Jeśli zapytania trafiają do innego celu lub odpowiada inny resolver, router albo operator może przekierowywać DNS. Test Standard lub Extended w https://www.dnsleaktest.com/ pomaga to zawęzić: przy DNS Protection wartości w kolumnie Hostname zawierają wzorzec gw-<Nummer><Region>.dnsprotection.sophos.com, a jako ISP widnieje Amazon lub odpowiadająca mu nazwa. Jeśli test pokazuje wyłącznie inne resolvery, poproś operatora o sprawdzenie przekierowania DNS. Jeśli pojawiają się zarówno resolvery Sophos, jak i zewnętrzne, sprawdź ustawienia DNS firewalla, wewnętrznego serwera DNS i klientów oraz równoległe resolvery IPv6. https://ipleak.net/ może posłużyć jako kontrola porównawcza.

Pozostaw na firewallu tylko dwa adresy tenantu jako forwardery, sprawdź routing, NAT i Packet Capture oraz wyjaśnij przekierowanie z operatorem. Trzeci publiczny resolver byłby jedynie niechronionym obejściem.

Niektórzy klienci używają innego resolvera

Sprawdź łącznie DHCPv4, DHCPv6, Router Advertisements, profil VPN i statyczne wartości klientów. Dodatkowy serwer DNS IPv6 może kierować zapytania poza DNS Protection. DNS Protection działa przez IPv4, ale rozpoznaje rekordy AAAA, więc cele IPv6 nie wymagają osobnego resolvera IPv6.

Nazwy wewnętrzne przestały działać

Sprawdź DNS Request Routes, wewnętrzne serwery DNS, strefy odwrotne, domeny wyszukiwania i sufiksy klientów. Upewnij się też, że klient używa firewalla lub przewidzianego wewnętrznego resolvera, a nie bezpośrednio adresu IP DNS Protection.

Domena wewnętrzna lub legalna jest blokowana

Sprawdź kategoryzację, listę domen i cel CNAME. Wąski wyjątek jest lepszy niż otwarcie całej kategorii. Klasyfikacji SophosLabs Threat i Security Risk nie można zastąpić za pomocą Allow domain list.

Logi pozostają puste

Dashboard i raporty są opóźnione o około 15-25 minut. Zmieniona nazwa Location lub polityki może pojawić się dopiero po 30 minutach do czterech godzin. Dopiero potem sprawdź DHCP, DNS klienta, DNS firewalla, przekierowanie NAT, alternatywne resolvery, profile VPN i przypisanie Location.

W DNS Protection > Logs & Reports zacznij od DNS usage by source i filtruj według Location, Domain, Status lub Source IP. Dla DNS przekazywanego bezpośrednio reguła z Log firewall traffic może wykazać przejście UDP/TCP 53 przez firewall. Dla resolvera firewalla rozstrzygające jest Administration > Device access; reguła firewalla nie dowodzi zezwolenia ani odmowy dla tej lokalnej usługi.

Operatory filtrów, limity eksportu, opóźnienia i Live Discover opisuje Analiza raportów DNS Protection i Live Discover. W diagnostyce firewalla najpierw potwierdź ścieżkę resolvera, a dopiero potem uruchamiaj bardziej szczegółowe zapytania raportowe.

Przy EDR, XDR lub MDR narzędzie Threat Analysis Center > Live Discover może dodatkowo analizować dane DNS Protection, takie jak Domain, Policy Action, Location i Source IP. Pola użytkownika i urządzenia są dostępne dla danych endpointów w raportach standardowych, a nie w udokumentowanym schemacie DNS firewalla w Live Discover.

Strona blokowania nie jest wyświetlana

Sprawdź DNS Protection Root Certificate, ścieżkę DNS i dostępność blockpage.dnsprotection.sophos.com. W Web Proxy Mode sprawdź również Pharming Protection, regułę HTTP/HTTPS i wyjątek TLS Do not decrypt. VPN, Browser DoH i Apple Private Relay mogą także ominąć DNS Protection podczas testu.

Dla wąskiego wyjątku firewalla utwórz obiekt FQDN dla blockpage.dnsprotection.sophos.com. Reguła Allow zezwala na HTTP/HTTPS z odpowiednich stref i sieci wewnętrznych do strefy WAN, z tym obiektem jako celem i bez Web Filter. Odpowiadająca reguła TLS używa tych samych kryteriów z Do not decrypt. Nie wyłączaj globalnie Pharming Protection ani TLS Inspection.

DoH lub Private DNS omija kontrolę

Przekierowanie NAT portu 53 nie obejmuje DoH ani DoT. Polityki przeglądarki, systemu operacyjnego i MDM muszą kontrolować takie resolvery. Secure DNS w DNS Protection używa DoH; osobny tryb DNS Protection przez DoT nie jest udokumentowany.

Na urządzeniach Apple również iCloud Private Relay może omijać przewidzianą ścieżkę DNS. Jeśli na przykład iPhone’y nie mają dostępu do Internetu, ale inne urządzenia w tej samej lokalizacji działają, najpierw wyłącz Limit IP Address Tracking dla sprawdzanej ścieżki i ponów test. Zmianę obejmującą całą organizację wprowadzaj dopiero po tym ograniczonym teście i uzgodnieniu wymagań dotyczących prywatności.

Klienci VPN zachowują się inaczej niż klienci LAN

Sprawdź przypisane serwery DNS, sufiksy DNS, Split DNS, Full lub Split Tunnel i lokalne resolvery. DNS Protection może działać w biurze, a mimo to być omijany przy dostępie zdalnym. Podstawowy wybór VPN opisuje artykuł Sophos Connect czy SSL VPN: które rozwiązanie dostępu zdalnego wybrać?.

Eksploatacja

DNS Protection nie jest jednorazową wymianą serwera DNS. Regularnie sprawdzaj:

• Locations, publiczne adresy wyjściowe i rozpoznawanie DDNS.
• ustawienia DHCP i wewnętrzne DNS Request Routes.
• polityki, listy domen, Owner i daty przeglądu.
• najczęściej blokowane domeny i udokumentowane False Positives.
• nowe lokalizacje, sieci gościnne, ścieżki VPN i platformy endpointów.
• dystrybucję certyfikatu i dostępność domeny strony blokowania.
• raporty po zmianach i zdefiniowaną ścieżkę rollbacku.

Jeśli nie chcesz stale obsługiwać tych elementów, solidne resolvery i ukierunkowane mechanizmy ochrony są często lepszym wyborem. DNS Protection ma sens tam, gdzie polityki, raportowanie i ochrona Endpoint są rzeczywiście używane i monitorowane.

Bezpieczne wycofanie

Poniższe wycofanie konfiguracji lokalizacji dotyczy poprzedniej ścieżki Traditional DNS. Dla migracji SFOS 23 stosuj opisane wyżej wycofanie z przypisaniem polityki i przełącznikiem DNS Protection.

Dla ścieżki lokalizacji najpierw wyłącz przekierowanie DNS, aby podczas wycofania nie wymuszać firewalla na klientach. Następnie przywróć poprzednie resolvery w Network > DHCP, odnow dzierżawę klienta testowego i sprawdź nazwy publiczne oraz wewnętrzne. Dopiero potem przywróć poprzedni tryb lub serwery w Network > DNS. Początkowo pozostaw Request Routes; nie przeszkadzają w wycofaniu i ułatwiają kontrolowany powrót. Usuń Location z Fusion dopiero wtedy, gdy nie ma już przypisanych potrzebnych sieci ani polityk.

Endpoint DNS Protection wycofaj osobno: w DNS Protection > Policies > Endpoint policies usuń przypisanie albo wyłącz Use Sophos DNS Protection, a następnie sprawdź na urządzeniu pilotażowym, czy znów używa resolverów systemowych lub aplikacyjnych. Root Certificate można później usunąć tym samym zarządzanym kanałem, którym go wdrożono.