Wdrożenie i routing Sophos Firewall w Azure

Sophos Firewall można wdrożyć z Azure Marketplace jako jedną appliance albo przez template Load Balancer z dwiema firewallami. Sophos nazywa drugi projekt active-active, ale nie jest to natywny klaster HA SFOS. Konfiguracja, sesje i status nie synchronizują się jak między dwiema appliance HA.

⚠️ Routing Azure jest częścią konfiguracji firewalla. Prawidłowa reguła SFOS nie wystarcza bez User Defined Route, Network Security Group albo drogi powrotnej przez Load Balancer. Każde udostępnienie wymaga walidacji całej drogi w obie strony.

Wybór modelu i licencji

Koszty infrastruktury Azure i oprogramowania Sophos są oddzielne. PAYG rozlicza się godzinowo bez minimalnego zobowiązania w opisanym modelu i obejmuje Xstream; nie można dodawać pojedynczych subskrypcji ani Enhanced Plus Support. Sprawdzić kraj rozliczeń na liście krajów przekazów Microsoft oraz rzeczywistą ofertę; jeśli PAYG jest niedostępne, wybrać BYOL. BYOL od autoryzowanego resellera umożliwia pakiety, osobne subskrypcje (Network Protection, Web Protection, Zero-Day Protection) i wsparcie włącznie z Enhanced Plus Support. Opisane okresy to rok, dwa lub trzy lata: potwierdzić ofertę i uprawnienia bez obietnic ceny lub wsparcia. Zatrzymanie oprogramowania nie usuwa płatnych zasobów Azure.

Sophos podaje jako minimum Standard_F2s_v2, dwa vCPU, 4 GB RAM i co najmniej dwie karty NIC. Faktyczny rozmiar należy dobrać także do przepustowości, włączonych funkcji ochrony i limitów Azure. Publiczny IP używa Standard SKU ze statycznym przypisaniem. Basic SKU jest wycofana i nie należy do nowych wdrożeń.

Wdrożenie standalone z Marketplace

Utworzenie i zabezpieczenie appliance

1. Wybrać Sophos Firewall w Azure Marketplace oraz BYOL lub PAYG.
2. Określić Subscription, Resource Group, region, nazwę VM, silne początkowe hasło admin, rozmiar VM i Storage Account. VNet, subnety i sieci zdalne nie mogą się nakładać.
3. Przypisać PortA do LAN, a PortB do WAN. NSG początkowo otworzyć tylko dla wymaganych źródeł administracyjnych.
4. Zakończyć wdrożenie i otworzyć WebAdmin pod https://<dns-name>:4444.
5. W kontrolowany sposób ukończyć kreator, rejestrację, licencjonowanie i aktualizację firmware.
6. Ustawić prywatny adres NIC LAN jako Static. Dodać do każdej subnet workload UDR 0.0.0.0/0, Virtual appliance, z tym IP LAN jako Next Hop.
7. Przetestować IP Forwarding, NSG, reguły SFOS i drogę powrotną ze zdefiniowanego klienta.

Domyślna UDR kieruje ruch internetowy powiązanej podsieci workloadów przez firewall. Bardziej szczegółowe trasy Azure nadal mają pierwszeństwo. Połączenie route-based z Azure VPN Gateway korzysta dodatkowo z interfejsu XFRM oraz tras statycznych, SD-WAN lub BGP.

Przygotowanie planu adresacji

Dla nowego wdrożenia najpierw utworzyć publiczny adres IP w Public IP addresses > Create z IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static i Routing preference: Microsoft network. Ustawić unikalny DNS name label i wybrać Domain name label scope: None. Sophos wskazuje dla tej procedury również DDoS protection > Protection type: Network. Opcja wymaga odpowiedniego planu Azure DDoS i może generować dodatkowe koszty, dlatego przed utworzeniem adresu należy uzgodnić plan z administratorem Azure. Następnie wybrać adres w Public IP name. Availability zone: 1 to wybór w udokumentowanym przykładzie. Osobno obowiązuje ograniczenie do jednej strefy dostępności; nie dowodzi to wyłącznego wsparcia strefy 1 ani nie potwierdza innych stref lub projektów wielostrefowych. Dawna opcja dynamiczna Basic nie nadaje się już do nowych wdrożeń po jej wycofaniu przez Azure.

Przykład do adaptacji używa VNet 10.20.0.0/16, LAN 10.20.10.0/24 na PortA, WAN 10.20.20.0/24 na PortB i statycznego IP LAN 10.20.10.4. Te wartości RFC 1918 należy zastąpić wolnymi zakresami bez nakładania się z peeringiem, VPN i sieciami on-premises.

Utworzenie UDR LAN z dokładnymi polami Azure

Sophos wymaga zatrzymania VM przed ustawieniem statycznego IP LAN: Virtual machines > > Stop, następnie NIC LAN, Settings > IP configurations > ipconfig, Allocation: Static; zachować bieżący adres LAN albo wpisać zarezerwowany adres i zapisać zmianę. Ponownie uruchomić VM, a następnie utworzyć tabelę w Route tables > Create w tej samej Resource Group i regionie. W Subnets > Associate powiązać każdą podsieć klientów lub workloadów, której ruch ma przechodzić przez appliance. Jeśli klienci znajdują się bezpośrednio w podsieci LAN PortA, powiązać właśnie tę podsieć LAN, jak w podstawowym przykładzie Sophos. Nie powiązywać podsieci WAN firewalla. W Routes > Add ustawić Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance i Next hop address: 10.20.10.4. Sprawdzić Enable IP forwarding na obu NIC. Propagate gateway routes: Yes pozostawić tylko zgodnie z projektem VPN/ExpressRoute. Na końcu utworzyć ograniczoną, logowaną regułę LAN-WAN w Rules and policies > Firewall rules.

Obsługa active-active z Load Balancer

Template Sophos tworzy dwie firewalle oraz zewnętrzny i wewnętrzny Standard Load Balancer z HA Ports. Wymaga VNet /16 oraz subnetów LAN i WAN /24; przed użyciem innych rozmiarów Sophos wymaga konsultacji z przedstawicielem.

Health probes docierają do WebAdmin na 4444 i proxy na 3128. Probe wewnętrzne zależą również od specjalnych tras do adresu platformowego 168.63.129.16, które Automation Runbook wstrzykuje do tabeli routingu kernela. Trasy te nie przetrwają firmware upgrade; dostarczony runbook należy potem uruchomić ponownie i sprawdzić.

Podczas wdrożenia Trusted network musi początkowo mieć wartość *, ponieważ Azure Automation Runbook łączy się z publicznych IP Azure. Po sukcesie natychmiast ograniczyć NSG do udokumentowanych CIDR admina. Pierwsza firewall używa WebAdmin 4444 i SSH 2222, druga 4445 i 2223. Obie appliance rejestruje się osobno i utrzymuje identyczne reguły firewall, NAT i routing.

Konfiguracja probe i egress

Na obu firewallach skonfigurować gateway w Routing > Gateways i trasy probe w Routing > SD-WAN routes; trasa zewnętrzna musi być wyżej niż wewnętrzna. UDR workload 0.0.0.0/0 używa Next hop type: Virtual appliance oraz frontend IP wewnętrznego Load Balancer. W appliance probe TCP 4444 i 3128 są widoczne ze źródłem 168.63.129.16. Po zmianie portów probe wewnętrzna i zewnętrzna muszą pozostać różne. W NSG zezwolić na ścieżkę probe przez Source Service Tag AzureLoadBalancer; listenery SFOS i specjalne trasy Sophos również muszą być zgodne. Ani Service Tag, ani adres platformowy nie są ogólnie zaufanym źródłem internetowym. Oba backendy sprawdzić w Load balancer > Monitoring > Insights lub Health Probe Status; zdrowa probe nie potwierdza aplikacji ani drogi powrotnej.

Kontrole wdrożenia szablonu

Otworzyć zasób wdrożeniowy active-active, sprawdzić i zapisać rewizję, następnie Deploy to Azure. Przed Next > Create sprawdzić:

• Subscription, Resource group, Region, Location i dostępność Automation accounts w subskrypcji/regionie.
• Sprawdzony Base URL, VM name, bezpiecznie przechowywane Admin password, Image SKU (BYOL/PAYG-new), VM size z co najmniej dwoma NIC.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24), wolne Loadbalancer Int IP w LAN.
• Nowe/istniejące, grupy i nazwy Public IP, Storage, Network security group, Availability set, Automation account; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Zweryfikować istniejące zasoby i unikalną etykietę DNS.
• Zachować pierwotne reguły NSG i zatwierdzony czas Trusted network: *. Ograniczyć administrację również po błędzie automatyzacji; bez zatwierdzonego wyjątku czasowego zatrzymać wdrożenie z nieograniczonym publicznym zarządzaniem.

Następnie zapisać faktyczne NIC/podsieci, gateway, frontend LB, probes i mapowania portów administracji; nie kopiować przykładu standalone.

Gateway i trasy probes na obu appliance

Utworzyć i zapisać w Routing > Gateways > Add:

Zachowany przykład używa 10.54.11.1/10.54.22.1 i WAN dla obu gateway, lecz następnie wiąże trasy wewnętrzną/zewnętrzną z #PortA/#PortB. To nietypowe mapowanie jest specyficzne dla wdrożenia. Sprawdzić NIC, interfejsy SFOS i osiągalność podsieci; przy sprzeczności zatrzymać się i wyjaśnić z właścicielem, bez kopiowania IP lub wymyślania uniwersalnego mapowania.

W Routing > SD-WAN routes > Add najpierw wewnętrzna, potem zewnętrzna, obie Top:

Porównać obiekty i definicję usługi z faktycznym ruchem: HTTP nie oznacza zmiany probes TCP 4444/3128 na 80. Nie uogólniać niepodanej usługi wewnętrznej do szerokiej trasy; źródło/cel pozostają ograniczone. Zapisać, utrzymać zewnętrzną nad wewnętrzną i powtórzyć sprawdzone mapowanie na appliance 2. Sprawdzić Load balancers > Monitoring > Metrics > Health probe status, agregację Avg, filtr Backend IP address, dla obu backend/LB, a następnie rzeczywisty egress i powrót.

Odzyskiwanie wstrzykniętych tras po firmware

Zaplanować serwis: opisany runbook restartuje VM i może przerwać sesje. Wyeksportować backup SFOS, zachować runbook/NSG i sprawdzić drugi backend przed pracą na jednej VM. Przy awarii obu zaplanować przerwę, nie obiecywać recovery bez przestoju.

1. Network security groups > [NSG firewall] > Inbound security rules > allow_ssh: ustalić dostęp runnera do faktycznego mapowania SSH. Źródło używa Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, ryzykownego wyjątku czasowego, nie stałej rekomendacji. Preferować sprawdzoną węższą ścieżkę; inaczej wymagać jawnej zgody, krótkiego terminu i wyłącznie potrzebnego mapowania SSH. Nie zgadywać CIDR Azure ani otwierać innych portów.
2. Grupa zasobów > Automation account > Runbooks > [wdrożony runbook] > Edit > Edit in portal. Zachowana rewizja mówi o komentowaniu wierszy 20–24: zidentyfikować zamierzony blok w faktycznym skrypcie i zachować oryginał; nie przenosić numerów między rewizjami. Przy niejasnym celu zatrzymać się. Save > Publish, sprawdzić diff, Start.
3. Wprowadzić wartości tej VM:

4. Sprawdzić wyjście, błędy i status job. Completed oznacza tylko koniec zadania: czekać na restart/dostęp, sprawdzić trasę 168.63.129.16, obie probes oraz aplikację/egress. Dopiero potem odzyskiwać VM 2 z jej własnymi parametrami.
5. Natychmiast odtworzyć zapisane ograniczenia NSG, również po błędzie, i sprawdzić efektywny dostęp. Zachować działający backend i błędy, odtworzyć skrypt po błędnej edycji i eskalować przed powtórką lub pracą na drugim. Completed nie dowodzi 100 % zdrowia ani internetu. Instrukcja dokumentacyjna, bez wykonanych testów cloud/appliance/rollback.

DNAT i droga powrotna

Zewnętrzny Load Balancer wybiera firewall. HA Ports przenoszą przepływy NVA między protokołami i portami, ale nie zastępują publikacji właściwej dla usługi. Dla publikowanej usługi TCP utworzyć na zewnętrznym Load Balancer odpowiednią health probe oraz powiązaną z nią regułę Load Balancing. Następnie reguła NAT SFOS tłumaczy ruch do serwera. W Rules and policies > NAT rules ustawienie Translated source (SNAT): MASQ powoduje odpowiedź serwera do IP LAN tej samej firewall. Bez MASQ powrót może przejść przez drugą firewall i zerwać sesję.

Bezpośrednie publikowanie RDP nie jest zalecane. Preferowane są VPN lub ZTNA. Jeśli publikacja jest konieczna, ograniczyć źródło, usługę i cel w Azure i SFOS, włączyć logging i IPS oraz wykonać test negatywny.

Walidacja, diagnostyka i wycofanie

Testy odbiorcze

1. W Effective routes testowej VM sprawdzić, czy 0.0.0.0/0 wskazuje IP LAN SFOS, a dla active-active IP wewnętrznego Load Balancer.
2. Przetestować DNS, HTTPS i aplikację, a w Log viewer > Firewall potwierdzić Rule ID, źródło i cel. Dla publikacji wykonać test pozytywny z dozwolonej sieci źródłowej i test negatywny z niedozwolonej. Osobno sprawdzić cel DNAT oraz drogę powrotną serwera.
3. Dla active-active sprawdzić Health Probe Status i Backend Pool. Tylko w oknie serwisowym usunąć jeden firewall, przetestować nowe połączenia przez drugi i przywrócić zdrowy backend przed drugim testem. Istniejące sesje nie są synchronizowane i mogą zostać przerwane.

Typowe błędy

Przy braku egress sprawdzić kolejno Effective Routes, powiązanie subnet workload, statyczny IP LAN, IP forwarding, NSG i Rule ID SFOS. Dla unhealthy probe sprawdzić protokół/port TCP, listener, NSG i trasy SD-WAN do 168.63.129.16. Po firmware upgrade wstrzyknięte trasy nie są trwałe: ponownie uruchomić runbook Sophos dla obu VM, sprawdzić probe i od razu przywrócić CIDR admina w NSG SSH. Przy niestabilnym DNAT porównać reguły obu appliance, MASQ, Backend Pool i trasę powrotną serwera.

Przed wycofaniem egress zapisać wcześniej zatwierdzony Next Hop. Ponownie przypisać poprzednią Route Table albo odizolować subnet workload na czas zmiany. Samo odłączenie nowej tabeli może aktywować trasę systemową Azure 0.0.0.0/0 -> Internet i ominąć firewall; wolno to zrobić tylko po jawnym sprawdzeniu i zaakceptowaniu tej ścieżki. UDR i reguły tymczasowe usunąć dopiero po walidacji przywróconej drogi powrotnej. Dla DNAT najpierw wyłączyć regułę zewnętrznego Load Balancer. Snapshoty Azure nie zastępują eksportowanego backupu SFOS. Osobno udokumentować kopię zapasową, odbudowę, przypisanie licencji, osobę odpowiedzialną i alarm kosztowy.

Dalej użyć wewnętrznego runbooka Azure VPN Gateway lub konfiguracji Entra Domain Services w runbooku AD.