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.

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. Działa to niezawodnie, gdy zapora sieciowa widzi ruch DNS:

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łne imię i nazwisko, 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?

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.

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 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 zwraca uwagę, że hosty FQDN nie są przeznaczone do czystego rozróżniania wielu domen, gdy są one rozpoznawane na ten sam adres IP. W warstwie IP zapora nie zawsze może wiedzieć, z której domeny korzysta później aplikacja.

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 przeglądarka logów nic nie pokazuje, ruch nie dociera do zapory sieciowej lub rejestrowanie nie jest aktywne.

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

Sophos oferuje opcje CLI dla hostów FQDN, takie jak cache-ttl, idle-timeout, eviction i learn-subdomains. cache-ttl może używać TTL z odpowiedzi DNS albo wartości od 60 do 86400 sekund. idle-timeout domyślnie usuwa nieużywane powiązania po 3600 sekundach. eviction określa, kiedy usuwane są adresy IP nauczone z wildcard subdomains. Po zmianie cache-ttl nowa wartość dotyczy tylko nowych rozwiązań nazw; wpisy już znajdujące się w cache zachowują wcześniejszą wartość do czasu wygaśnięcia.

Tych wartości nie należy zmieniać jako pierwszej reakcji. Najpierw trzeba sprawdzić, czy projekt DNS, ścieżka resolvera i baza reguł są poprawne. Tuning należy do 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.

Sophos podaje limit do 16 000 hostów FQDN, ale nie jest to zaproszenie 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.