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 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.

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 Central, 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 Central.
• 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ą.

Zalecana ścieżka przez firewall wygląda następująco:

1. Sophos Central zna lokalizację jako Location.
2. Sophos Central 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 Central 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.

Przed rolloutem należy ustalić licencję, publiczne adresy wyjściowe, wewnętrzne strefy DNS, serwery DHCP oraz osoby odpowiedzialne za polityki i wyjątki. Xstream Protection obejmuje samodzielny DNS Protection. Endpoint DNS Protection wymaga Workspace Protection oraz odpowiedniej licencji Sophos Endpoint.

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.

Konfiguracja DNS Protection

1. Utworzenie Location w Sophos Central

My Products > DNS Protection > Locations

1. Wybierz Add i wpisz jednoznaczną nazwę lokalizacji.
2. Włącz Traditional DNS over IPv4.
3. Podaj publiczny adres WAN lub stabilny FQDN DDNS.
4. Przy Multi-WAN uwzględnij wszystkie faktycznie używane adresy wyjściowe.
5. Zapisz Location.

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 dostępne są dwa adresy IP DNS Protection. Zawsze kopiuj je z własnego tenantu Central i używaj 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.

3. Konfiguracja firewalla jako DNS Forwarder

Network > DNS

1. Wybierz Static DNS.
2. Wprowadź dwa adresy Central 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. Zapisz konfigurację.

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.

4. Przekazywanie domen wewnętrznych

Network > DNS
DNS request route section > 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

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. Edytuj serwer DHCP odpowiedniej sieci.
2. Przekazuj wewnętrzny adres interfejsu firewalla jako serwer DNS.
3. Odnów dzierżawę na kliencie testowym.
4. 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

Opcjonalna reguła DNAT może przekierować klasyczny ruch DNS klientów wewnętrznych do firewalla:

• 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
• Inbound interfaces: tylko interfejsy odpowiadające źródłom wewnętrznym, nigdy WAN
• Position: wysoko, przed bardziej ogólnymi regułami NAT

Wyjątki dla wewnętrznych serwerów DNS i urządzeń specjalnych muszą być udokumentowane. 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, sieć gościnną i logi. 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.

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.

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 Central, 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.

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

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 testy:

• 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.
• logi pojawiają się w Sophos Central po oczekiwanym opóźnieniu raportowania.
• 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

Location nie pojawia się w Sophos Central

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.

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 względem czasu rzeczywistego. Dopiero potem sprawdź DHCP, DNS klienta, DNS firewalla, przekierowanie NAT, alternatywne resolvery, profile VPN i przypisanie Location.

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.

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.

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 organizacja nie chce stale obsługiwać tych elementów, często lepsze są niezawodne resolvery i ukierunkowane mechanizmy ochrony. DNS Protection ma sens tam, gdzie polityki, raportowanie i ochrona endpointów są rzeczywiście używane i monitorowane.