Sophos Firewall: hardware, virtueel of cloud?

Sophos Firewall kan werken als XGS Appliance, virtueel apparaat, Software Appliance of Cloud Deployment. Technisch gezien draait overal Sophos Firewall OS, maar het besturingsmodel is niet hetzelfde. De beslissing heeft invloed op de prestaties, ondersteuning, poortontwerp, HA, herstel, licentieverlening, monitoring en de vraag wie verantwoordelijk is voor welk platform in geval van een verstoring.

Bij nieuwe projecten moet je niet alleen vragen welke variant goedkoper is. Waar het om gaat is welke variant past bij de locatie, het virtualisatieplatform, de cloudarchitectuur en het operations-team. De Sophos Firewall Maatvoeringsgids is ook belangrijk voor het bepalen van de prestatiegrootte.

De platformkeuze bepaalt ook de compliancefuncties: De FIPS 140-3-modus is beschikbaar op XGS Appliances, ondersteunde virtuele platformen, AWS en Azure, maar niet op Software Appliances of XG- en SG-hardware.

Kies het operationele model

Snelle beslissing

• XGS Appliance: Meestal geschikt wanneer een site een speciale, duidelijk ondersteunde firewall met fysieke poorten nodig heeft.
• Virtueel apparaat: Vooral geschikt als er een stabiel virtualisatieplatform beschikbaar is en netwerkzones virtueel netjes gescheiden kunnen worden.
• Software Appliance: Meestal geschikt als uw eigen hardware bewust als firewallplatform moet worden bediend en ondersteund.
• Cloud Deployment: Meest geschikt voor het beschermen van workloads in AWS of Azure of voor het verbinden met lokale netwerken.

De belangrijkste regel: een virtuele of cloudfirewall is geen vrijbrief voor minder planning. CPU, RAM, opslag, virtuele switches, routing, HA, back-up en monitoring moeten net zo zorgvuldig worden gepland als bij hardware.

Wanneer moet je voorzichtig zijn?

De beslissing moet niet alleen gebaseerd zijn op wat technisch mogelijk is. Sommige omgevingen zien er op papier flexibel uit, maar creëren tijdens de bedrijfsvoering onnodige risico’s.

• Hypervisor wordt al intensief gebruikt: IPS, TLS Inspection, VPN en logboekregistratie hebben voorspelbare CPU en I/O-reserve nodig.
• WAN, LAN, DMZ en het management lopen door hetzelfde fysieke knelpunt: Een logisch zuivere scheiding heeft weinig nut als het echte datapad overbelast of verkeerd gesegmenteerd is.
• Geen enkel team voelt zich gezamenlijk verantwoordelijk voor hypervisor en firewall: Incidenten blijven bestaan ​​tussen platform-, netwerk- en firewallteams.
• HA was alleen gepland als een selectievakje: Zonder host-, opslag-, netwerk- en hersteltests is hoge beschikbaarheid niet bewezen.
• Cloudrouting is niet volledig gedocumenteerd: De firewall beschermt alleen verkeer dat er daadwerkelijk doorheen wordt geleid.
• Herstellen is nooit toegepast: Een back-up is alleen betrouwbaar als een herstel realistisch is getest of op zijn minst goed is gepland. In dergelijke gevallen is een XGS Appliance vaak niet minder modern, maar gewoon de robuustere bedieningsbeslissing. Omgekeerd kan een virtuele of cloud-firewall zeer nuttig zijn als het platform, het netwerkontwerp, de monitoring en de verantwoordelijkheden duidelijk duidelijk zijn.

Vergelijk de platforms

XGS Appliance

Voor klassieke locaties is een XGS Appliance doorgaans de meest planbare variant. Hardware, poorten, ondersteuning, RMA, levenscyclus en firewall-besturingssysteem komen als een gecoördineerd systeem.

Voordelen:

• speciale firewallhardware,
• vaste havenapparatuur en uitbreidingsmogelijkheden,
• duidelijke toewijzing van WAN, LAN, DMZ, HA koppeling en beheer,
• eenvoudig hardwareondersteunings- en vervangingsproces,
• geen afhankelijkheid van hypervisorbronnen,
• Zeer geschikt voor filialen, hoofdkantoren en edge firewalls. Het grootste voordeel ligt in de werking: als er een probleem is, hoef je niet eerst duidelijk te maken of de hypervisor, vSwitch, opslag, cloudrouting of firewall zelf de oorzaak is. Voor veel MKB-locaties is dit belangrijker dan maximale flexibiliteit.

Virtueel apparaat

Een virtuele Sophos Firewall is zinvol als er al een schoon virtualisatieplatform bestaat en de firewall moet worden geïntegreerd in een datacenter, een multi-tenantomgeving of een intern segmentatieontwerp.

Relevante virtuele platforms zijn onder meer VMware, Microsoft Hyper-V, KVM, Nutanix Prism en Citrix Hypervisor. Controleer vóór de implementatie de concrete platformversie aan de hand van de actuele compatibiliteitsinformatie van Sophos. Sophos noemt minimaal één vCPU, 4 GB RAM, twee vNICs, een primaire schijf van 32 GB en een rapportschijf van 80 GB. Dit zijn installatievereisten, geen sizingadvies voor productie-inspectieverkeer.

Controleer meer dan alleen de productfamilie. Voor Nutanix vereist Sophos bijvoorbeeld AOS 6.5.x of een latere LTS-versie, de meegeleverde AHV-versie, een compatibele versie van Prism Central en een AHV-cluster dat bij Prism Central is geregistreerd. KVM vereist een x86-host met een recente Linux-kernel en ingeschakelde Intel VT- of AMD-V-ondersteuning. Als u vCPU en RAM voor een hogere belasting vergroot, plan dan ook een grotere rapportschijf voor het extra logvolume.

Belangrijke operationele vragen:

• Zijn de CPU-bronnen gegarandeerd of zijn ze zwaar overtekend?
• Zijn RAM en opslag voldoende gedimensioneerd?
• Zijn virtuele NIC’s en poortgroepen duidelijk gescheiden?
• Zijn er speciale netwerkpaden voor WAN, LAN, DMZ, HA en beheer?
• Is promiscue modus, VLAN trunking of SR-IOV vereist?
• Is er een schoon back-up- en herstelconcept?
• Is het duidelijk wie samen de problemen met de hypervisor, storage en firewall oplost?

Een virtuele firewall kan heel goed werken. Het wordt echter al snel problematisch als het op een overbelaste host draait of als WAN, LAN en het beheer er alleen logisch schoon uitzien, maar fysiek door dezelfde knelpunten lopen.

⚠️ Hypervisorsnapshots of backups van de virtualisatieleverancier zijn geen ondersteunde vervanging voor de geïntegreerde Sophos-backup. Sla voor een ondersteunde restore de configuratie op via Backup & Firmware > Backup & Restore. Platformbackups mogen aanvullend bestaan, maar mogen niet het enige herstelpad zijn.

Software Appliance

Een Software Appliance wordt op eigen x86-64-hardware geïnstalleerd. Dit kan zinvol zijn voor labs, speciale omgevingen of zeer gerichte ontwerpen. In productie moet dit model bewust worden gekozen, omdat hardware, drivers, reserveonderdelen, monitoring en support grotendeels onder de verantwoordelijkheid van de beheerder vallen.

De installatie formatteert en partitioneert de schijf opnieuw en verwijdert daarbij het bestaande besturingssysteem en alle bestanden. Voor een SFOS 22 Software Appliance vereist Sophos Legacy BIOS, minimaal 4 GB RAM, twee netwerkinterfaces en minimaal 32 GB opslag; 64 GB wordt aanbevolen. Als niet aan de minimumvereisten wordt voldaan, kan de firewall in fail-safe mode gaan.

Als een appliance al in de Failsafe-modus start, moet vóór resourcewijzigingen de door SFOS vastgestelde oorzaak worden bewaard met het runbook Sophos Firewall in de Failsafe-modus controleren.

Controleer:

• Is de hardware geschikt voor continu gebruik?
• Zijn netwerkkaarten, opslag en BIOS/UEFI-configuratie geschikt?
• Is er vervangende hardware?
• Is het installatie- en herstelproces gedocumenteerd?
• Wie is verantwoordelijk voor hardwarefouten?

Voor standaardlocaties is een XGS Appliance vaak eenvoudiger. Voor bijzondere technische gevallen kan een Software Appliance toch geschikt zijn als het operations team het platform goed beheerst.

Cloud Deployment

Cloudimplementaties zijn met name handig wanneer workloads in AWS of Azure moeten worden beschermd of wanneer cloudnetwerken zijn verbonden met lokale locaties. In de cloud zijn andere vragen belangrijk dan op de traditionele locatie.

Plannen:

• VPC/VNet-ontwerp,
• routeringstabellen,
• Beschikbaarheidszones,
• Elastische IP’s of openbare IP’s,
• Site-naar-site VPN of SD-WAN,
• Logging en centrale evaluatie,
• Cloudkosten voor bijvoorbeeld opslag, verkeer en HA-ontwerp,
• Operationele verantwoordelijkheid tussen cloudteam en firewallteam.

Een cloudfirewall is geen vervanging voor een schoon cloudnetwerkontwerp. Alleen de paden die daadwerkelijk door de firewall worden geleid, worden beveiligd. De implementatie- en routeringskeuzes worden uitgelegd in de handleidingen voor Sophos Firewall op AWS en Sophos Firewall op Azure.

Een virtuele of software-appliance installeren

Download de image rechtstreeks van de Sophos-pagina Firewall Installers. Kies onder Virtual Installers het bijbehorende OVF-pakket voor Citrix of VMware, het VHD-pakket voor Hyper-V of het QCOW2-pakket voor KVM, Proxmox of Nutanix. Gebruik voor eigen hardware in plaats daarvan de ISO onder Software Installers.

Controleer vóór de import of de hierboven gekoppelde downloadpagina via HTTPS is geladen, het pakket niet van een mirror van derden komt en het archief volledig en zonder fouten is uitgepakt. Houd bij een OVF-pakket het manifest, de OVF en beide VMDK-bestanden bij elkaar. Stop als de import een afwijking in het manifest of de checksum meldt en download het pakket opnieuw rechtstreeks van Sophos. Voor een interne bestandsoverdracht kunt u ook direct na het downloaden een SHA-256-waarde vastleggen en deze op het doelsysteem opnieuw vergelijken. Hiermee worden overdrachtsfouten gedetecteerd, maar dit vervangt geen handtekening van de leverancier.

Vóór de import gelden de minima van 1 vCPU, 4 GB RAM, twee vNIC’s, een primaire schijf van 32 GB en een rapportschijf van 80 GB. Te weinig resources activeert fail-safe mode. Hypervisorsnapshots en leveranciersback-ups zijn geen ondersteunde firewallback-ups; gebruik de SFOS-back-upfunctie.

Controleer vóór de eerste start PortA en PortB tegen management-, LAN- en WAN-netwerken. Een omgekeerde koppeling kan WebAdmin direct aan internet blootstellen. Voer de eerste toegang uit vanuit een geïsoleerd beheernetwerk op https://172.16.16.16:4444, bijvoorbeeld met 172.16.16.2/24 op de client. Wijzig het standaardwachtwoord niet vooraf in de CLI, omdat de setup-assistent daarna niet start. Controleer na de wizard licentie, beide schijven, interfaces, reporting, back-up en een negatieve toegangstest vanuit een niet-toegestaan netwerk.

De installatie valideren en veilig terugdraaien

Installeer niet meteen opnieuw als https://172.16.16.16:4444 niet bereikbaar is. Controleer eerst of de beheerclient rechtstreeks in het netwerk van PortA zit, of de bijbehorende vNIC verbonden is en of de poortgroep of bridge daadwerkelijk aan het geïsoleerde beheernetwerk is gekoppeld. Controleer daarna via de VM-console of de firewall volledig is gestart en sluit een adresconflict met 172.16.16.16 uit. PortA mag tijdens deze test niet per ongeluk met het openbare WAN verbonden zijn.

Als na de setup rapporten ontbreken of de appliance in fail-safe mode start, vergelijkt u de toewijzing, bus en minimale grootte van de auxiliary-/rapportschijf plus CPU, RAM en beide vNIC’s met de platformspecifieke vereisten van Sophos. Leg de gedetecteerde oorzaak vast met het fail-safe-runbook voordat u resources wijzigt.

Zolang de firewall geen productieverkeer routeert, is terugdraaien eenvoudig: schakel de VM uit, draai testroutes of de tijdelijke standaardgateway terug en blijf de bestaande firewall ongewijzigd gebruiken. Na de ingebruikname moet herstel gebaseerd zijn op een actuele SFOS-back-up en een gedocumenteerde herbouw van de VM, niet op een hypervisorsnapshot.

Installeren op eigen hardware

De software-appliance vervangt het bestaande besturingssysteem volledig. Vereist zijn x86-64, Legacy BIOS, minstens 4 GB RAM, twee NIC’s en een HDD of SSD van 32 GB; 64 GB wordt aanbevolen. De USB-stick heeft minstens 1 GB nodig. Windows of macOS wordt alleen gebruikt om de ISO te schrijven. Daarna start de doelserver vanaf USB en wordt deze na bevestiging volledig geformatteerd en opnieuw gepartitioneerd. Stel eerst data, bootmodus, NIC-detectie en een onafhankelijk herstelpad veilig.

Beheer en herstel plannen

Prestaties en afmetingen

Als het om hardware gaat, zijn de prestaties afhankelijk van het model dat u kiest. Voor virtuele, software- en cloudimplementaties zijn de prestaties meer platformafhankelijk.

Bijzonder relevant:

• CPU-prestaties en CPU-reservering,
• RAM-geheugen,
• opslaglatentie,
• virtuele NIC’s,
• hypervisor- of cloudnetwerkpad,
• aantal sessies,
• TLS Inspection,
• IPS,
• VPN-doorvoer,
• Loggen en rapporteren.

Gegevensbladwaarden moeten daarom altijd in hun context worden gelezen. Firewall-doorvoer zonder beveiligingsinspectie is niet hetzelfde als Threat Protection, TLS Inspection of IPsec VPN onder echte belasting. De verschillen uitgelegd Sophos Firewall Prestatiegegevens correct interpreteren.

HA en herstel

Hoge beschikbaarheid verschilt aanzienlijk, afhankelijk van het platform. Als het om hardware gaat, is HA meestal gemakkelijker te begrijpen: twee apparaten, HA-link, gedefinieerde interfaces, duidelijk vervangend apparaat. Er rijzen aanvullende vragen voor virtuele en cloud-implementaties:

• Werken HA-nodes op verschillende hosts?
• Zijn opslag, netwerk en hypervisor echt redundant?
• Zijn virtuele MAC-adressen en vSwitch-regels compatibel?
• Zijn er afhankelijkheden van cloudrouting of load-balancing?
• Werken back-ups en herstelbewerkingen op een nieuw exemplaar?
• Is het falen van een host of een beschikbaarheidszone getest?

De basisprincipes van HA-varianten kunt u vinden in Sophos Firewall hoge beschikbaarheid instellen (HA). Voor herstel is Sophos Firewall Back-up maken of terugzetten vereist.

Licenties en ondersteuning

Licenties moeten vroeg worden gecontroleerd, omdat hardware-, virtuele en softwarefirewalls verschillend worden behandeld. Sinds maart 2025 worden virtuele, software- en cloud-BYOL-licenties beperkt door CPU-cores; de vroegere RAM-licentielimiet is vervallen. Dit betekent niet dat onbeperkt RAM een slechte sizing van CPU, storage of NICs compenseert. Serienummer, core-licentie, support en abonnement moeten nog steeds bij de instance passen.

Sophos Firewall - Basislicentie is geschikt voor de basislicenties. De wijziging in virtuele en softwarelicenties, waarbij RAM niet langer de focus is van de licentielimiet, wordt vermeld in de blogpost Sophos Firewall VM & SW - Alleen CPU telt - Geen RAM-limiet meer.

Wat is belangrijk tijdens de bediening:

• Licentie- en ondersteuningsstatus documenteren.
• Registreer het serienummer en de registratiestatus netjes.
• Controleer de HA-licentie voordat u gaat bouwen.
• Controleer of de firmware en ondersteuning in aanmerking komen voordat u upgrades uitvoert.
• Ken het RMA- of herstelproces voor het gekozen platform. Vóór grote upgrades moet Controleer Sophos Firewall vóór SFOS 22 Upgrade ook worden gebruikt omdat platformondersteuning, opslagruimte, back-up, HA en oude VPN-configuraties upgraderelevant kunnen zijn.

Voor active-passive HA op virtuele of software-appliances heeft alleen de Primary alle vereiste licenties nodig, inclusief de Base Firewall License. Bij active-active heeft elke node een eigen Base Firewall License en dezelfde aanvullende beveiligingslicenties nodig; de vervaldatums mogen verschillen. Dit moet vóór de bouw van het cluster worden opgelost, niet tijdens de analyse van de eerste failover.

Beslissingsmatrix

• Klassieke locatie met WAN, LAN en DMZ: Meestal hardware. Alleen virtueel met een goede virtualisatiestrategie.
• Datacenter met bestaand hypervisorteam: Hardware is mogelijk, virtueel is vaak zinvol.
• Cloudworkloads in AWS of Azure: Meer virtueel of cloud, geen klassieke hardware.
• Gemakkelijke ondersteuning en RMA belangrijk: Meer hardware. Bij virtueel of cloud hangt veel af van het platformteam.
• Veel fysieke poorten vereist: Meer hardware. Alleen virtueel met een strak NIC- en vSwitch-ontwerp.
• Dynamische schaling en Infrastructure as Code: Meer virtueel of in de cloud.
• Klein IT-team zonder gespecialiseerde hypervisorkennis: Meestal hardware; Plan virtuele firewalls zorgvuldig.
• Tenant- of segmentatieontwerp in het datacenter: Hardware is mogelijk, virtueel is vaak zinvol.

Veelvoorkomende fouten

• Voer een virtuele firewall uit op een overboekte host.
• Scheid WAN, LAN en beheer op de hypervisor niet.
• Selecteer hardware alleen op basis van prijs in plaats van grootte.
• Een cloudfirewall implementeren, maar niet volledig nadenken over routeringstabellen.
• Plan HA, maar test geen host-, opslag- of cloudfouten.
• Maak een back-up, maar oefen nooit met herstellen.
• Controleer de licentie- en ondersteuningsstatus alleen tijdens een firmware-upgrade.
• Activeer beveiligingsfuncties zoals TLS Inspection of IPS later, zonder prestatiereserve.
• Breng het platformteam, netwerkteam en firewallmanagers alleen bij elkaar bij een verstoring.

Controlelijst

• Locatie duidelijk gedefinieerd: locatie, datacenter of cloud.
• Verkeer, bandbreedte en beveiligingsfuncties vastgelegd voor dimensionering.
• Hardware-, virtuele, software- of cloudvarianten bewust gekozen.
• Verantwoordelijkheid voor firewall, hypervisor, cloud en netwerk gedocumenteerd.
• HA en herstelontwerp gecontroleerd.
• Back-up- en herstelproces getest of gepland.
• Licentie, ondersteuning en registratie verduidelijkt.
• Monitoring voor firewall en onderliggend platform beschikbaar.
• Upgrademogelijkheden en platformondersteuning gecontroleerd.
• Persoon verantwoordelijk voor platform, netwerk, firewall, back-up en herstel genoemd.

Veelgestelde vragen