Sophos Firewall: sprzęt, wirtualny czy chmura?

Sophos Firewall może działać jako urządzenie XGS Appliance, urządzenie wirtualne, Software Appliance lub Cloud Deployment. Technicznie rzecz biorąc, wszędzie działa Sophos Firewall OS, ale model operacyjny nie jest taki sam. Decyzja dotyczy wydajności, wsparcia, projektu portu, HA, odzyskiwania, licencjonowania, monitorowania i tego, kto jest odpowiedzialny za którą platformę w przypadku zakłóceń.

W przypadku nowych projektów nie należy po prostu pytać, który wariant jest tańszy. Ważne jest, który wariant pasuje do lokalizacji, platformy wirtualizacji, architektury chmury i zespołu operacyjnego. Przewodnik doboru Sophos Firewall jest również ważny przy doborze wydajności.

Wybór platformy decyduje także o funkcjach zgodności: Tryb FIPS 140-3 jest dostępny na urządzeniach XGS Appliance, obsługiwanych platformach wirtualnych, AWS i Azure, ale nie na Software Appliances ani sprzęcie XG i SG.

Wybierz model operacyjny

Szybka decyzja

• Urządzenie XGS Appliance: Najczęściej odpowiednie, gdy witryna potrzebuje dedykowanej, wyraźnie obsługiwanej zapory ogniowej z portami fizycznymi.
• Urządzenie wirtualne: Nadaje się głównie, jeśli dostępna jest stabilna platforma wirtualizacji i można wirtualnie oddzielić strefy sieciowe.
• Software Appliance: Zwykle odpowiednie, jeśli Twój własny sprzęt ma być celowo obsługiwany i wspierany jako platforma firewall.
• Cloud Deployment: Najbardziej odpowiedni do ochrony obciążeń w AWS lub Azure lub do łączenia się z sieciami lokalnymi.

Najważniejsza zasada: zapora wirtualna lub chmurowa nie jest darmową przepustką za mniej planowania. CPU, pamięć RAM, pamięć masowa, przełączniki wirtualne, routing, HA, tworzenie kopii zapasowych i monitorowanie muszą być zaplanowane równie dokładnie, jak w przypadku sprzętu.

Kiedy zachować ostrożność

Decyzja nie powinna opierać się wyłącznie na tym, co jest technicznie możliwe. Niektóre środowiska wyglądają elastycznie na papierze, ale stwarzają niepotrzebne ryzyko w działaniu.

• Hypervisor jest już intensywnie wykorzystywany: IPS, TLS Inspection, VPN i rejestrowanie wymagają przewidywalnego CPU i rezerwy we/wy.
• WAN, LAN, DMZ i zarządzanie napotykają to samo fizyczne wąskie gardło: Logicznie czysta separacja jest mało pomocna, jeśli rzeczywista ścieżka danych jest przeciążona lub niepoprawnie podzielona na segmenty.
• Żaden zespół nie czuje się współodpowiedzialny za hypervisora ​​i zaporę ogniową: Incydenty pozostają pomiędzy zespołami zajmującymi się platformą, siecią i zaporą ogniową.
• HA zaplanowano jedynie jako pole wyboru: Bez testów hosta, pamięci masowej, sieci i przywracania wysoka dostępność nie zostanie udowodniona.
• Routing w chmurze nie jest w pełni udokumentowany: Zapora chroni tylko ruch, który jest przez nią faktycznie kierowany.
• Przywracanie nigdy nie było praktykowane: Kopia zapasowa jest niezawodna tylko wtedy, gdy przywracanie zostało realistycznie przetestowane lub przynajmniej odpowiednio zaplanowane. W takich przypadkach urządzenie XGS Appliance jest często nie tyle mniej nowoczesne, ile po prostu stanowi solidniejsze rozwiązanie operacyjne. Z drugiej strony zapora wirtualna lub chmurowa może być bardzo przydatna, jeśli platforma, projekt sieci, monitorowanie i obowiązki są jasno określone.

Porównaj platformy

XGS Appliance

Urządzenie XGS Appliance jest zwykle najbardziej przewidywalnym wariantem dla klasycznych lokalizacji. Sprzęt, porty, wsparcie, RMA, cykl życia i zapora systemowa tworzą skoordynowany system.

Zalety:

• dedykowany sprzęt firewall,
• stałe wyposażenie portów i możliwości rozbudowy,
• jasne przypisanie łącza i zarządzania WAN, LAN, DMZ, HA,
• łatwy proces wsparcia i wymiany sprzętu,
• brak zależności od zasobów hypervisora,
• Dobrze nadaje się do oddziałów, centrali i zapór brzegowych. Największą zaletą jest działanie: jeśli wystąpi problem, nie musisz najpierw wyjaśniać, czy przyczyną jest hypervisor, vSwitch, pamięć masowa, routing w chmurze czy sama zapora sieciowa. Dla wielu lokalizacji MŚP jest to ważniejsze niż maksymalna elastyczność.

Urządzenie wirtualne

Wirtualny Sophos Firewall ma sens, jeśli istnieje już czysta platforma wirtualizacji, a zapora sieciowa ma zostać zintegrowana z centrum danych, środowiskiem wielodostępnym lub projektem wewnętrznej segmentacji.

Obsługiwane platformy wirtualne obejmują VMware, Microsoft Hyper-V, KVM, Nutanix Prism i Citrix Hypervisor. Przed wdrożeniem należy sprawdzić konkretną wersję platformy w aktualnych informacjach zgodności Sophos. Sophos podaje minimum: jeden vCPU, 4 GB RAM, dwie vNIC, dysk podstawowy 32 GB i dysk raportów 80 GB. Są to minima instalacyjne, a nie zalecenie sizingu dla ruchu inspekcyjnego w produkcji.

Weryfikacja nie może kończyć się na rodzinie produktów. Na przykład dla Nutanix Sophos wymaga AOS 6.5.x lub nowszego wydania LTS, dołączonej wersji AHV, zgodnej wersji Prism Central oraz klastra AHV zarejestrowanego w Prism Central. KVM wymaga hosta x86 z aktualnym jądrem Linux i włączoną obsługą Intel VT lub AMD-V. Jeśli zwiększa się liczbę vCPU i RAM z powodu większego obciążenia, należy również zaplanować większy dysk raportów dla dodatkowych logów.

Ważne pytania operacyjne:

• Czy zasoby CPU są gwarantowane, czy też znacznie przekroczone?
• Czy pamięć RAM i pamięć masowa są wystarczająco duże?
• Czy wirtualne karty sieciowe i grupy portów są wyraźnie oddzielone?
• Czy istnieją dedykowane ścieżki sieciowe dla WAN, LAN, DMZ, HA i zarządzania?
• Czy wymagany jest tryb promiscuous, trunking VLAN lub SR-IOV?
• Czy istnieje koncepcja czystego tworzenia kopii zapasowych i przywracania?
• Czy jest jasne, kto wspólnie rozwiązuje problemy z hypervisorem, pamięcią masową i zaporą sieciową?

Wirtualna zapora sieciowa może działać bardzo dobrze. Jednak sytuacja szybko staje się problematyczna, gdy działa na przeciążonym hoście lub gdy WAN, LAN i zarządzanie wyglądają tylko na logicznie czyste, ale fizycznie przechodzą przez te same wąskie gardła.

⚠️ Snapshoty hypervisora ani backupy dostawcy platformy wirtualizacyjnej nie są wspieranym zamiennikiem zintegrowanego backupu Sophos. Aby uzyskać wspierany restore, konfigurację należy zapisać w Backup & Firmware > Backup & Restore. Backupy platformy mogą istnieć dodatkowo, ale nie mogą być jedyną ścieżką recovery.

Software Appliance

Software Appliance instaluje się na dedykowanym sprzęcie x86-64. Może to być przydatne w laboratoriach, środowiskach specjalnych lub bardzo ukierunkowanych projektach. W produkcji ten model trzeba wybrać świadomie, ponieważ sprzęt, sterowniki, części zamienne, monitoring i wsparcie są w dużej mierze odpowiedzialnością operatora.

Instalacja formatuje i ponownie partycjonuje dysk, usuwając istniejący system operacyjny oraz wszystkie pliki. Dla Software Appliance z SFOS 22 Sophos wymaga Legacy BIOS, co najmniej 4 GB RAM, dwóch interfejsów sieciowych i co najmniej 32 GB przestrzeni; zalecane jest 64 GB. Jeśli wymagania minimalne nie są spełnione, firewall może przejść w tryb fail-safe.

Jeśli appliance uruchamia się już w trybie Failsafe, przed zmianą zasobów należy zapisać przyczynę wykrytą przez SFOS za pomocą runbooka Diagnostyka Sophos Firewall w trybie Failsafe.

Sprawdź:

• Czy sprzęt nadaje się do pracy ciągłej?
• Czy karty sieciowe, pamięć masowa i konfiguracja BIOS/UEFI są odpowiednie?
• Czy istnieje sprzęt zastępczy?
• Czy proces instalacji i odzyskiwania jest udokumentowany?
• Kto jest odpowiedzialny za błędy sprzętowe?

W przypadku standardowych lokalizacji często łatwiej jest zastosować urządzenie XGS Appliance. W specjalnych przypadkach technicznych Software Appliance może być nadal odpowiedni, jeśli zespół operacyjny dobrze zna platformę.

Cloud Deployment

Wdrożenia w chmurze są szczególnie przydatne, gdy obciążenia w AWS lub Azure wymagają ochrony lub gdy sieci w chmurze są połączone z lokalizacjami lokalnymi. W chmurze ważne są inne pytania niż w tradycyjnej lokalizacji.

Zaplanuj:

• Projektowanie VPC/VNet,
• tablice routingu,
• Strefy Dostępności,
• Elastyczne adresy IP lub publiczne adresy IP,
• Site-to-Site VPN lub SD-WAN,
• Rejestrowanie i centralna ocena,
• Koszty chmury, np. przechowywanie, ruch i projekt HA,
• Odpowiedzialność operacyjna pomiędzy zespołem zajmującym się chmurą a zespołem zapory ogniowej.

Zapora sieciowa w chmurze nie zastępuje czystego projektu sieci w chmurze. Chronione są tylko ścieżki faktycznie trasowane przez zaporę. Decyzje dotyczące wdrożenia i routingu opisują instrukcje Sophos Firewall w AWS oraz Sophos Firewall w Azure.

Instalacja appliance wirtualnego lub programowego

Obraz należy pobrać bezpośrednio ze strony Sophos Firewall Installers. W sekcji Virtual Installers należy wybrać odpowiedni pakiet OVF dla Citrix lub VMware, pakiet VHD dla Hyper-V albo pakiet QCOW2 dla KVM, Proxmox lub Nutanix. Dla własnego sprzętu należy zamiast tego użyć obrazu ISO z sekcji Software Installers.

Przed importem trzeba sprawdzić, czy podlinkowana wyżej strona pobierania została otwarta przez HTTPS, czy pakiet nie pochodzi z zewnętrznego serwera lustrzanego i czy archiwum rozpakowało się w całości bez błędów. W przypadku pakietu OVF manifest, plik OVF i oba pliki VMDK muszą pozostać razem. Jeśli import zgłosi niezgodność manifestu lub sumy kontrolnej, należy przerwać instalację i ponownie pobrać pakiet bezpośrednio od Sophos. Przy wewnętrznym przesyłaniu pliku można też zapisać wartość SHA-256 bezpośrednio po pobraniu i porównać ją ponownie w systemie docelowym. Pozwala to wykryć błędy transmisji, ale nie zastępuje podpisu producenta.

Przed importem obowiązują minima: 1 vCPU, 4 GB RAM, dwie vNIC, dysk podstawowy 32 GB i dysk raportów 80 GB. Niedostateczne zasoby uruchamiają tryb fail-safe. Snapshoty i kopie hipernadzorcy nie są obsługiwanymi backupami firewalla; należy używać funkcji backupu SFOS.

Przed pierwszym uruchomieniem sprawdzić PortA i PortB względem sieci zarządzania, LAN i WAN. Odwrócone przypisanie może wystawić WebAdmin bezpośrednio do Internetu. Pierwszy dostęp wykonać z izolowanej sieci administracyjnej pod https://172.16.16.16:4444, na przykład z 172.16.16.2/24 na kliencie. Nie zmieniać wcześniej domyślnego hasła w CLI, bo asystent konfiguracji nie uruchomi się. Po wizardzie sprawdzić licencję, oba dyski, interfejsy, raportowanie, backup i negatywny test dostępu z niedozwolonej sieci.

Weryfikacja instalacji i bezpieczne wycofanie

Jeśli https://172.16.16.16:4444 jest niedostępny, nie należy od razu ponownie instalować systemu. Najpierw trzeba sprawdzić, czy klient administracyjny znajduje się bezpośrednio w sieci PortA, czy odpowiednia vNIC jest podłączona oraz czy jej grupa portów lub bridge rzeczywiście prowadzi do izolowanej sieci administracyjnej. Następnie za pomocą konsoli VM należy potwierdzić, że firewall uruchomił się w pełni, i wykluczyć konflikt adresów z 172.16.16.16. Podczas tego testu PortA nie może być przypadkowo połączony z publiczną siecią WAN.

Jeśli po konfiguracji brakuje raportów lub appliance uruchamia się w trybie fail-safe, należy porównać przypisanie, magistralę i minimalny rozmiar dysku auxiliary/report, a także CPU, RAM i obie vNIC, z wymaganiami Sophos dla danej platformy. Przed zmianą zasobów należy zapisać wykrytą przyczynę za pomocą runbooka trybu fail-safe.

Dopóki firewall nie routuje ruchu produkcyjnego, wycofanie jest proste: należy wyłączyć VM, cofnąć trasy testowe lub tymczasowy default gateway i nadal używać istniejącego firewalla bez zmian. Po uruchomieniu produkcyjnym odzyskiwanie musi opierać się na aktualnym backupie SFOS i udokumentowanym odtworzeniu VM, a nie na snapshotcie hypervisora.

Instalacja na własnym sprzęcie

Software Appliance całkowicie zastępuje istniejący system operacyjny. Wymaga x86-64, Legacy BIOS, co najmniej 4 GB RAM, dwóch NIC i HDD lub SSD 32 GB; zalecane jest 64 GB. Pamięć USB musi mieć co najmniej 1 GB. Windows lub macOS służy tylko do zapisania ISO. Serwer startuje potem z USB i po potwierdzeniu jest całkowicie formatowany i partycjonowany. Najpierw trzeba zabezpieczyć dane oraz sprawdzić tryb startu, wykrywanie NIC i niezależną drogę recovery.

Zaplanuj eksploatację i odzyskiwanie

Wydajność i rozmiar

Jeśli chodzi o sprzęt, wydajność zależy od wybranego modelu. W przypadku wdrożeń wirtualnych, oprogramowania i chmur wydajność jest w większym stopniu zależna od platformy.

Szczególnie istotne:

• wykonanie CPU i rezerwacja CPU,
• RAM,
• opóźnienie przechowywania,
• wirtualne karty sieciowe,
• ścieżka sieciowa hypervisora lub chmury,
• liczba sesji,
• TLS Inspection,
• IPS,
• przepustowość VPN,
• Rejestrowanie i raportowanie.

Dlatego wartości zawarte w arkuszach danych należy zawsze czytać w kontekście. Przepustowość zapory sieciowej bez inspekcji zabezpieczeń nie jest taka sama jak w przypadku modułu Ochrona przed zagrożeniami, TLS Inspection lub IPsec VPN przy rzeczywistym obciążeniu. Wyjaśniono różnice Sophos Firewall Poprawnie zinterpretuj dane dotyczące wydajności.

HA i odzyskiwanie

Wysoka dostępność różni się znacznie w zależności od platformy. Jeśli chodzi o sprzęt, HA jest zwykle łatwiejszy do zrozumienia: dwa urządzenia, łącze HA, zdefiniowane interfejsy, przejrzyste urządzenie zastępcze. W przypadku wdrożeń wirtualnych i chmurowych pojawiają się dodatkowe pytania:

• Czy węzły HA działają na różnych hostach?
• Czy pamięć masowa, sieć i hypervisor są naprawdę zbędne?
• Czy wirtualne adresy MAC i reguły vSwitch są kompatybilne?
• Czy są jakieś zależności od routingu w chmurze lub równoważenia obciążenia?
• Czy kopie zapasowe i przywracanie działają na nowej instancji?
• Czy przetestowano awarię hosta lub strefy dostępności?

Podstawy wariantów HA można znaleźć w Konfigurowanie wysokiej dostępności Sophos Firewall (HA). Aby odzyskać, wymagana jest lektura Sophos Firewall Utwórz lub przywróć kopię zapasową.

Licencjonowanie i wsparcie

Licencje trzeba sprawdzić wcześnie, ponieważ firewalle sprzętowe, wirtualne i programowe są traktowane odmiennie. Od marca 2025 r. licencje wirtualne, programowe i cloud BYOL są ograniczone liczbą rdzeni CPU; wcześniejszy limit RAM już nie obowiązuje. Nie oznacza to, że dowolna ilość RAM kompensuje zły sizing CPU, storage lub NIC. Numer seryjny, licencja na rdzenie, wsparcie i subskrypcja nadal muszą odpowiadać instancji.

Sophos Firewall - Licencja podstawowa jest odpowiednia dla podstaw licencji podstawowej. Zmiany dotyczące licencji wirtualnych i oprogramowania, w przypadku których pamięć RAM nie jest już przedmiotem limitu licencji, są wymienione w poście na blogu Sophos Firewall VM & SW – Liczy się tylko CPU – Koniec z limitem pamięci RAM.

Co jest ważne w działaniu:

• Dokumentuj status licencji i wsparcia.
• Czysto zapisz numer seryjny i status rejestracji.
• Przed rozpoczęciem budowy sprawdź licencję HA.
• Przed aktualizacją sprawdź dostępność oprogramowania sprzętowego i wsparcia.
• Zapoznaj się z procedurą RMA lub procesem odzyskiwania dla wybranej platformy. Przed większymi aktualizacjami należy również użyć Sprawdź Sophos Firewall przed aktualizacją SFOS 22, ponieważ obsługa platformy, przestrzeń dyskowa, kopie zapasowe, HA i stare konfiguracje VPN mogą być istotne w przypadku aktualizacji.

W active-passive HA na appliance wirtualnych lub programowych tylko node Primary potrzebuje wszystkich wymaganych licencji, w tym Base Firewall License. W active-active każdy node potrzebuje własnej Base Firewall License oraz takich samych dodatkowych licencji ochronnych; daty ich wygaśnięcia mogą się różnić. Należy to rozstrzygnąć przed budową klastra, a nie podczas analizy pierwszego failoveru.

Macierz decyzyjna

• Klasyczna lokalizacja z WAN, LAN i DMZ: Głównie sprzęt. Wirtualny tylko z dobrą strategią wirtualizacji.
• Centrum danych z istniejącym zespołem hypervisorów: Sprzęt jest możliwy, wirtualnie często ma sens.
• Obciążenia w chmurze w AWS lub Azure: Bardziej wirtualny lub chmurowy, a nie klasyczny sprzęt.
• Łatwe wsparcie i ważne RMA: Więcej sprzętu. W przypadku rozwiązań wirtualnych lub chmurowych wiele zależy od zespołu obsługującego platformę.
• Wymaganych wiele portów fizycznych: Więcej sprzętu. Tylko wirtualne z czystą kartą sieciową i projektem vSwitch.
• Skalowanie dynamiczne i Infrastructure as Code: Bardziej wirtualne lub w chmurze.
• Mały zespół IT bez specjalistycznej wiedzy na temat hypervisora: Głównie sprzęt; Starannie planuj wirtualne zapory sieciowe.
• Projekt najemcy lub segmentacji w centrum danych: Sprzęt jest możliwy, wirtualnie często ma sens.

Typowe błędy

• Uruchom wirtualną zaporę ogniową na przepełnionym hoście.
• Nie oddzielaj WAN, LAN i zarządzania na hypervisorze.
• Wybierz sprzęt wyłącznie na podstawie ceny, a nie rozmiaru.
• Wdrażanie zapory sieciowej w chmurze, ale nie do końca przemyślenie tabel routingu.
• Zaplanuj HA, ale nie testuj awarii hosta, pamięci masowej ani chmury.
• Utwórz kopię zapasową, ale nigdy nie ćwicz przywracania.
• Sprawdź status licencji i wsparcia tylko podczas aktualizacji oprogramowania sprzętowego.
• Aktywuj później funkcje bezpieczeństwa, takie jak TLS Inspection lub IPS, bez rezerwy wydajności.
• Łącz zespół platformy, zespół sieciowy i menedżerów zapór firewall tylko w przypadku zakłóceń.

Lista kontrolna

• Jasno określona lokalizacja: lokalizacja, centrum danych lub chmura.
• Funkcje ruchu, przepustowości i bezpieczeństwa rejestrowane w celu zmiany rozmiaru.
• Celowo wybrane warianty sprzętu, wirtualnego, oprogramowania lub chmury.
• Udokumentowana odpowiedzialność za firewall, hypervisor, chmurę i sieć.
• Sprawdzono HA i projekt odzyskiwania.
• Przetestowano lub zaplanowano proces tworzenia kopii zapasowych i przywracania.
• Wyjaśniono licencję, wsparcie i rejestrację.
• Dostępne monitorowanie zapory ogniowej i platformy bazowej.
• Sprawdzono możliwość aktualizacji i obsługę platformy.
• Wyznaczona osoba odpowiedzialna za platformę, sieć, zaporę ogniową, tworzenie kopii zapasowych i przywracanie.

Często zadawane pytania