Poprawne używanie FQDN hosts i wildcard FQDNs w Sophos Firewall

Hosty FQDN są przydatne, gdy miejsca docelowego nie można wiarygodnie opisać za pomocą stałego adresu IP. Typowymi przykładami są usługi w chmurze, serwery aktualizacji, punkty końcowe uwierzytelniania lub usługi dostawców, których adresy IP mogą się zmieniać.

Host FQDN nie zastępuje zasad sieciowych, nie zapewnia pełnej kontroli adresów URL ani nie gwarantuje, że każda aplikacja będzie prawidłowo pasować. Ważnym pytaniem jest, w jaki sposób Sophos Firewall rozpoznaje nazwę lub, w przypadku symboli wieloznacznych, uczy się jej z ruchu DNS.

Kiedy hosty FQDN mają sens

Hosty FQDN spełniają reguły, w których techniczne miejsce docelowe jest lepiej opisane przez nazwę DNS niż przez indywidualne adresy IP. Jest to szczególnie przydatne w przypadku ruchu wychodzącego.

Przydatne przykłady:

Serwer wewnętrzny może łączyć się tylko z updates.vendor.example.
Aplikacja wymaga dostępu do kilku znanych nazw FQDN dostawców.
W regule zapory sieciowej, regule NAT, trasie SD-WAN lub konfiguracji VPN należy użyć określonego punktu końcowego chmury.
Przypadek rozwiązywania problemów musi wykazać, czy reguła pasuje do oczekiwanej nazwy lub nieoczekiwanego adresu IP.

Hosty FQDN są mniej odpowiednie w przypadku szerokiego dostępu do Internetu, takiego jak „wszystko w ramach jednej usługi SaaS”, gdy aplikacja korzysta z wielu domen, sieci CDN, interfejsów API, telemetrii i punktów końcowych logowania. W przypadku ruchu sieciowego lepszą warstwą kontrolną są często zasady sieciowe, grupy adresów URL, ochrona DNS, kontrola aplikacji lub inspekcja TLS.

Sophos Firewall może używać hostów FQDN nie tylko w regułach firewall, ale też w ustawieniach takich jak SD-WAN policy routes, VPN settings oraz techniczne obiekty hostów dla serwerów mail, proxy, DNS, authentication, remote access, web lub syslog. Mimo to przy każdym zastosowaniu trzeba sprawdzić, czy nazwa DNS jest naprawdę stabilniejsza niż obiekt IP albo dedykowana warstwa polityki.

W przypadku samej reguły zapory zacznij od zrozumienia i bezpiecznej konfiguracji reguł Sophos Firewall. Jeśli reguła nie pasuje, użyj reguła Sophos Firewall nie pasuje: sprawdzanie przyczyn.

Normalna nazwa hosta FQDN lub nazwa FQDN z symbolem wieloznacznym

Sophos Firewall inaczej obsługuje normalne hosty FQDN i wieloznaczne nazwy FQDN. To najważniejszy szczegół operacyjny.

Normalny host FQDN

W przypadku normalnego hosta FQDN, takiego jak updates.vendor.example, zapora rozpoznaje nazwę poprzez DNS. Zwrócone adresy IP są wykorzystywane dla obiektu. Jeśli rekord DNS ma czas TTL, zapora odświeża rozdzielczość po wygaśnięciu tego czasu TTL.

W SFOS 22 obowiązuje ważne ograniczenie IPv6: obiekty hosta FQDN nie rozpoznają adresów IPv6. Nie uniemożliwia to DNS Lookup ani zwykłym klientom otrzymywania odpowiedzi AAAA, ale sam obiekt nie utrzymuje tych celów IPv6. Obsługa IPv6 i ograniczenia w Sophos Firewall z SFOS 22 odróżnia to od pozostałych funkcji obsługiwanych i nieobsługiwanych.

Działa to dobrze, gdy:

nazwa FQDN wskazuje bezpośrednio na wymagane adresy IP,
aplikacja używa dokładnie tej nazwy,
odpowiedzi DNS nie przełączają się stale pomiędzy wieloma celami CDN,
test wykorzystuje tę samą rozdzielczość nazw, którą widzi zapora sieciowa.

FQDN z symbolami wieloznacznymi

W przypadku wieloznacznej nazwy FQDN, takiej jak *.example.com, zapora nie rozpoznaje po prostu „wszystkich możliwych subdomen”. DNS nie zapewnia pełnej listy wszystkich subdomen.

Zamiast tego zapora uczy się pasujących adresów IP z odpowiedzi DNS. W tym celu musi widzieć pasujące odpowiedzi; w przypadku tranzytowego ruchu DNS dodatkowo musi być włączone learn-subdomains. Sam widoczny ruch DNS nie gwarantuje jeszcze skutecznego uczenia się. Udokumentowane ścieżki uczenia się to:

Sophos Firewall jest serwerem DNS dla klientów.
Lub ruch DNS przechodzi przez zaporę sieciową i jest wykrywany przez DPI.
Według Sophos, ta wiedza dotyczy ruchu UDP DNS na porcie 53 do zewnętrznych serwerów DNS.

Jeśli klienci korzystają z protokołu DNS-over-HTTPS, DNS-over-TLS, innej ścieżki DNS lub lokalnego modułu rozpoznawania nazw, zapora może nie widzieć odpowiednich odpowiedzi DNS. Wieloznaczna nazwa FQDN może wówczas pozostać pusta lub niekompletna, nawet jeśli domena działa w przeglądarce.

Utwórz hosta FQDN

Ścieżka menu to:

Hosts and services > FQDN host > Add

Dla czystego obiektu liczy się tylko kilka pól:

Name: opisowy i stabilny technicznie, np. fqdn_vendor_updates lub wfqdn_example_subdomains .
FQDN: pełna kwalifikowana nazwa domenowa, na przykład updates.vendor.example lub *.example.com .
FQDN host group: opcjonalnie wybrać istniejącą grupę albo utworzyć nową. Host FQDN może należeć do kilku FQDN host groups.
Pisownia: pisz nazwy FQDN małymi literami. Sophos twierdzi, że wielkie litery w hostach FQDN nie są obsługiwane.

Po wprowadzeniu pól obiekt zapisuje się przyciskiem Save.

Po zapisaniu nie należy od razu umieszczać obiektu na ślepo w regułach produkcji. Najpierw wykonaj krótki test: czy zapora rozpoznaje nazwę, czy przeglądarka dzienników wyświetla później oczekiwany docelowy adres IP i czy ten adres IP jest zgodny z odpowiedzią DNS klienta?

Grupowanie wielu hostów FQDN

FQDN host group łączy kilka istniejących hostów FQDN w jeden obiekt wielokrotnego użytku. Grupy można wybierać między innymi w regułach zapory i SD-WAN policy routes.

Przejdź do Hosts and services > FQDN host group > Add. W polu Name wpisz unikatową nazwę, wybierz wymagane hosty i kliknij Save. W przypadku aplikacji z oddzielnymi punktami końcowymi grupa grp_vendor_service może na przykład zawierać login.vendor.example, api.vendor.example i updates.vendor.example. Host może należeć do więcej niż jednej grupy. Dodawaj tylko niezbędne nazwy, ponieważ każdy dodatkowy host rozszerza wszystkie reguły korzystające z grupy.

Listy FQDN host i FQDN host group można przeszukiwać według dowolnego wyświetlanego atrybutu. Przed zmianą lub usunięciem obiektu sprawdź osobno, które reguły zapory, SD-WAN policy routes lub inne konfiguracje go używają. Zmiana grupy współdzielonej wpływa na wszystkie te zastosowania.

Użyj w regułach zapory sieciowej

W większości projektów host FQDN należy do reguł ruchu wychodzącego w ramach Destination networks . Reguła opisuje następnie, które źródła wewnętrzne mogą łączyć się z którym dynamicznym miejscem docelowym.

Typowy przepływ:

Utwórz obiekt FQDN w Hosts and services > FQDN host .
Otwórz lub utwórz pasującą regułę w Rules and policies > Firewall rules .
Zdefiniuj wąsko Source zones i Source networks and devices.
Wybierz Destination zones celowo, zwykle WAN.
Wybierz obiekt FQDN w Destination networks .
Zezwól tylko na wymagane porty w Services, na przykład HTTPS.
Włącz rejestrowanie.
Uruchom prawdziwy test i sprawdź Rule ID, docelowy adres IP, NAT Rule ID i usługę w Log Viewer.

Host FQDN sam w sobie nie zapewnia bezpieczeństwa reguły. Jeśli Źródło to Any , Usługa to Any, a Miejsce docelowe to szeroki obiekt wieloznaczny, wynik może szybko stać się bardzo otwarty. Lepsza jest mała reguła z jasnym źródłem, przejrzystą usługą, aktywnym logowaniem i udokumentowanym celem.

Przypadek specjalny: wstępnie skonfigurowane grupy dla reguł Web Proxy

Wstępnie skonfigurowane grupy SafeSearch enforcement, YouTube restrictions enforcement i Google app enforcement służą wyłącznie do reguł wymuszających SafeSearch, ograniczenia YouTube lub logowanie do Google Workspace przez Web Proxy. Nie zastępują własnej listy ogólnych miejsc docelowych SaaS.

Przed włączeniem takiej reguły upewnij się, że urządzenia w grupie pilotażowej ufają urzędowi certyfikacji (CA), skonfiguruj odpowiednie wyjątki od deszyfrowania oraz przygotuj konkretne testy akceptacyjne HTTP i HTTPS. Procedurę opisuje artykuł stopniowe wdrażanie TLS Inspection na Sophos Firewall.

W dedykowanej regule zapory ustaw Action na Allow, a Destination zones na WAN. W sekcji Destination networks wybierz wymagane wstępnie skonfigurowane grupy, a w Services usługi HTTP i HTTPS. Włącz także Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine i Decrypt HTTPS during web proxy filtering. Umieść regułę nad regułami, które przetwarzają ten sam ruch za pomocą silnika DPI.

Po teście sprawdź w Log Viewer i przeglądarce, czy tylko zamierzona grupa pilotażowa korzysta z tej reguły i czy wymagane ograniczenie działa. Aby wycofać zmianę, wyłącz nową regułę proxy i potwierdź, że ruch jest ponownie przetwarzany przez znajdującą się niżej regułę DPI. Usuń regułę proxy dopiero po potwierdzeniu tego stanu.

Ograniczenia i pułapki

Wiele problemów z nazwami FQDN nie wynika z listy reguł, ale z zachowania DNS klientów lub aplikacji.

Zapora widzi różne odpowiedzi DNS

Jeśli klient i zapora korzystają z różnych programów rozpoznawania nazw DNS, mogą otrzymać różne adresy IP dla tej samej nazwy. Jest to normalne w przypadku sieci CDN. Reguła może następnie dopasować jeden adres IP, podczas gdy klient korzysta z innego.

Podczas rozwiązywania problemów porównaj:

Który adres IP zwraca nslookup lub dig na kliencie?
Który docelowy adres IP pojawia się w przeglądarce dziennika?
Z jakich serwerów DNS korzysta klient i zapora sieciowa?
Czy DNS używa portu 53, DNS-over-HTTPS czy DNS-over-TLS?

Wieloznaczna nazwa FQDN niczego się nie uczy

Wieloznaczna nazwa FQDN działa tylko wtedy, gdy zapora widzi pasujące odpowiedzi DNS. Jeśli klient korzysta z DoH w przeglądarce lub ścieżki DNS, która nie przechodzi przez zaporę, zapora nie może nauczyć się subdomen. W przypadku ruchu DNS, który jedynie przechodzi przez zaporę, należy dodatkowo sprawdzić, czy włączone jest learn-subdomains. Jest to kolejny warunek konieczny, a nie gwarancja powodzenia.

W takich przypadkach przeniesienie reguły zapory nie jest rozwiązaniem. Zamiast tego zdecyduj się na projekt DNS: użyj zapory sieciowej jako usługi przesyłania dalej DNS, kieruj ruch DNS przez zaporę w kontrolowany sposób lub użyj innej warstwy kontroli dla ruchu sieciowego.

Nazwa FQDN jest zbyt szeroka

Symbol wieloznaczny, taki jak *.example.com, może zawierać znacznie więcej niż zamierzono. Nowoczesne usługi SaaS wykorzystują domeny logowania, domeny API, media CDN, telemetrię, usługi wsparcia i strony trzecie. Czasami pojedynczy obiekt wieloznaczny jest zbyt szorstki.

Jeśli dostęp z założenia musi być szeroki, polityka internetowa, grupa adresów URL lub Kontrola aplikacji są często łatwiejsze do zrozumienia i przeglądu niż bardzo duża reguła zapory FQDN.

Wiele domen wskazuje na ten sam adres IP

Sophos wyraźnie dokumentuje, że hosty FQDN nie obsługują wielu domen rozwiązywanych na ten sam adres IP. Obiekt FQDN działa na podstawie rozwiązanych adresów IP i nie może rozróżniać takich domen w warstwie IP. Dlatego nie należy oczekiwać, że zapewni niezawodne rozdzielenie tych domen.

W przypadku decyzji internetowych opartych na domenie warstwa internetowa jest zatem bardziej odpowiednia niż reguła zapory sieciowej oparta wyłącznie na protokole IP z obiektem FQDN.

Rozwiązywanie problemów

Jeśli reguła FQDN nie zachowuje się zgodnie z oczekiwaniami, najpierw sprawdź rzeczywiste połączenie. Nazwa w przedmiocie nie jest decydująca; adres IP używany w momencie testu to.

Reguła nie pasuje

Sprawdzać:

Czy Strefa Źródła pasuje?
Czy źródłowy adres IP lub sieć źródłowa są zgodne?
Czy usługa jest zgodna, na przykład TCP 443 zamiast tylko HTTP?
Czy przeglądarka logów pokazuje inny identyfikator reguły?
Czy przeglądarka logów pokazuje docelowy adres IP, który nie jest zgodny z bieżącą odpowiedzią DNS?
Czy nad regułą FQDN jest aktywna bardziej ogólna reguła?

Jeśli przeglądarka dzienników pokazuje inną regułę, kolejność reguł ma większe znaczenie niż obiekt FQDN. Jeśli Log Viewer nic nie pokazuje, brak ruchu docierającego do zapory lub nieaktywne rejestrowanie są możliwymi przyczynami, ale nie jedynymi. Należy również sprawdzić wybrany moduł oraz filtry czasu, pól i wyszukiwania. Sesje reguł zapory są rejestrowane dopiero przy zamknięciu połączenia po otrzymaniu zdarzenia Destroy; jeśli połączenie zostanie zamknięte bez tego zdarzenia, może brakować wpisu sesji w dzienniku. Dlatego należy również uwzględnić możliwość, że połączenie jest nadal otwarte. Za pomocą ukierunkowanego Packet Capture należy sprawdzić, czy pakiety testowe docierają do zapory; sam pusty Log Viewer nie dowodzi, że tak nie jest.

Nazwa FQDN z symbolami wieloznacznymi pozostaje pusta

Sprawdzać:

Czy klient używa zapory sieciowej jako serwera DNS?
Czy DNS jest widoczny przez zaporę sieciową?
Czy klient korzysta z DoH czy DoT?
Czy używany jest UDP 53?
Czy dla tranzytowego ruchu DNS włączone jest learn-subdomains? Same widoczne odpowiedzi DNS nie gwarantują jeszcze wyuczonego powiązania.
Czy istnieje trasa żądania DNS lub wewnętrzny moduł rozpoznawania nazw ukrywający odpowiedź, zanim zapora ją dostrzeże?

Jeśli DNS jest celowo kierowany wewnętrznie, konfiguracja DNS request routes w Sophos Firewall pomaga w projektowaniu DNS.

DNS zmieniony, reguła reaguje później

Obiekty FQDN współpracują z odpowiedziami DNS i pamięciami podręcznymi. Jeśli zmieni się miejsce docelowe dostawcy, może wystąpić opóźnienie, zanim zapora użyje nowego stanu. W przypadku normalnych hostów FQDN decydujące znaczenie ma TTL rekordu DNS.

W Device Console Sophos udostępnia systemową rodzinę poleceń set fqdn-host; nie zmienia ona tylko jednego wybranego obiektu hosta. cache-ttl domyślnie używa dns-reply-ttl albo może przyjąć wartość od 60 do 86400 sekund. idle-timeout usuwa nieużywane powiązania po 60–86400 sekundach; wartość domyślna wynosi 3600 sekund. eviction określa, czy i po jakim czasie mają być usuwane wyuczone adresy IP subdomen wildcard; zakres interwału wynosi od 60 do 86400 sekund. learn-subdomains włącza lub wyłącza poznawanie tych adresów z ruchu tranzytowego, który przechodzi przez zaporę, ale nie pochodzi z niej ani nie jest do niej kierowany. Po zmianie cache-ttl nowa wartość dotyczy tylko później rozwiązanych wpisów; wpisy już zapisane w pamięci podręcznej zachowują poprzednią wartość do wygaśnięcia.

Nie zmieniaj tych wartości jako pierwszego działania. Najpierw sprawdź projekt DNS, ścieżkę resolvera i bazę reguł. Przed zmianą zapisz wszystkie bieżące wartości, zmieniaj tylko jeden parametr naraz i testuj jego działanie na nowo rozwiązanych wpisach. Aby wycofać zmianę, przywróć zapisaną wartość początkową; dla domyślnego TTL jest to dns-reply-ttl. Tuning powinien być częścią udokumentowanej procedury operacyjnej lub wsparcia.

Zalecenie operacyjne

Hostami FQDN można zarządzać, jeśli traktuje się je jako zależności techniczne, a nie spontaniczne wyjątki.

Dobra praktyka:

Udokumentuj jasny cel każdego obiektu FQDN.
Używaj oszczędnie symboli wieloznacznych.
Łącz obiekty FQDN z wąskimi definicjami źródeł i usług.
Włącz rejestrowanie nowych lub krytycznych reguł.
Testuj zmiany za pomocą przeglądarki dzienników i wyszukiwania DNS.
Nie ukrywaj szerokiego dostępu do sieci w dużej regule FQDN.
W przypadku usług SaaS lub chmurowych regularnie sprawdzaj, czy dostawca wymaga dodatkowych domen.

Dokumentacja CLI podaje limit do 16 000 hostów FQDN. Jednak dla SFOS 22 Sophos dokumentuje wspólny limit 16 000 hostów obejmujący wszystkie typy hostów; nie należy z tego wnioskować o dodatkowej, niezależnej pojemności dla FQDN ani o wolnej rezerwie. Ten limit nie jest zaproszeniem do niekontrolowanego wzrostu. Wiele starych wyjątków FQDN utrudnia przeglądy, troubleshooting i utrzymanie reguł. Lepsza jest mniejsza, udokumentowana lista obiektów z właścicielem, celem i datą przeglądu.

Jeśli obiekt został utworzony tylko dlatego, że „aplikacja w innym przypadku nie działa”, przejrzyj go później. Te awaryjne obiekty często stają się trwałymi wyjątkami, które są trudne do wyjaśnienia.

Często zadawane pytania

Jaka jest różnica między hostem FQDN a hostem IP?

Host IP opisuje stały adres lub sieć. Host FQDN opisuje nazwę DNS, której bieżących adresów IP może używać zapora. Pomaga to w przypadku dynamicznych miejsc docelowych, ale zależy od rozdzielczości DNS i zachowania pamięci podręcznej.

Czy `*.example.com` automatycznie działa dla wszystkich subdomen?

Nie jako pełna lista domen. Zapora sieciowa musi widzieć pasujące odpowiedzi DNS i uczyć się z nich adresów IP. Jeśli DNS nie jest widoczny przez zaporę, nazwa FQDN z symbolem wieloznacznym może pozostać niekompletna.

Dlaczego moja reguła FQDN nie jest zgodna?

Zwykle kontekst reguły, kolejność lub faktycznie używany docelowy adres IP nie są zgodne. W przeglądarce dziennika sprawdź, który identyfikator reguły, docelowy adres IP, port docelowy i identyfikator reguły NAT pojawiają się podczas prawdziwego testu.

Czy hosty FQDN działają w trybie DNS-over-HTTPS lub DNS-over-TLS?

Nazwy FQDN z symbolami wieloznacznymi są problematyczne, gdy klienci korzystają z DoH lub DoT, a zapora nie widzi odpowiedzi DNS. Zapora sieciowa nie może wówczas niezawodnie nauczyć się wymaganych subdomen.

Czy do filtrowania sieci należy używać hostów FQDN?

Tylko wybiórczo. Do prawdziwej kontroli sieci zwykle bardziej odpowiednie są zasady sieciowe, grupy adresów URL, ochrona DNS, kontrola aplikacji lub inspekcja TLS. Hosty FQDN są przydatne w przypadku technicznych miejsc docelowych w regułach sieciowych, ale nie stanowią pełnych zasad dotyczących adresów URL.