Sophos Firewall Services veilig opnieuw starten

Een herstart van afzonderlijke Sophos Firewall Services kan helpen wanneer een module niet meer correct reageert, een log geen nieuwe entries meer toont of Sophos Support om een gerichte herstart vraagt. Het is echter geen vervanging voor nette troubleshooting. Een verkeerde service-herstart kan VPN-tunnels, routing, WebAdmin, DNS, DHCP, reporting of andere functies kort onderbreken.

Dit artikel legt uit hoe men services via WebAdmin of Advanced Shell opnieuw start, vooraf de passende logs controleert en daarna nagaat of de service weer netjes draait. Wanneer eerst onduidelijk is welke technische service bij welke module hoort, helpt het overzicht Sophos Firewall Troubleshooting: Services en logs. Voor basisveiligheid op de CLI, debug en tcpdump past daarnaast Sophos Firewall CLI Troubleshooting: belangrijke commando’s.

⚠️ Belangrijk: Service-herstarts moeten in productieve omgevingen gepland worden uitgevoerd. Vooraf moet duidelijk zijn welke service betrokken is, welke gebruikers of tunnels kunnen worden onderbroken en of er alternatieve toegang tot de firewall beschikbaar is.

Wanneer een service-herstart zinvol is

Een gerichte service-herstart is zinvol wanneer een concrete module betrokken is en de rest van de firewall in principe stabiel draait.

Typische voorbeelden:

• WebAdmin laadt niet meer, maar routing en firewallregels werken verder.
• Een VPN-service hangt, terwijl andere firewallfuncties onopvallend zijn.
• Een log toont actuele fouten voor een bepaalde service.
• Sophos Support noemt een concrete service die opnieuw gestart moet worden.
• Een service werd na een configuratiewijziging niet netjes actief.

Niet zinvol is het blind herstarten van meerdere services alleen omdat een probleem nog onduidelijk is. Dan moet men eerst logs, systeembelasting, opslagruimte, HA-toestand, routing en betrokken modules controleren.

Wanneer men services niet opnieuw moet starten

Een service-herstart is verleidelijk omdat hij snel effect heeft. In sommige situaties verslechtert hij echter de analyse of veroorzaakt hij extra onderbrekingen.

• Oorzaak is nog volledig onduidelijk: De herstart verandert de toestand en kan belangrijke sporen in logs of statusuitvoer verbergen.
• Meerdere centrale services vallen tegelijk uit: Dan is vaak niet een afzonderlijke service het probleem, maar systeembelasting, opslagruimte, database, HA of platformtoestand.
• Firewall is alleen nog via precies deze service bereikbaar: Een herstart kan de laatste remote toegang laten wegvallen.
• Productieve VPN-, routing- of DHCP-services zijn betrokken: Bestaande gebruikers, locaties of leases kunnen kort worden onderbroken.
• Debug loopt al en de fout is reproduceerbaar: Eerst relevante logs veiligstellen, daarna opnieuw starten.
• De service werd al meerdere keren opnieuw gestart: Dan is oorzaakanalyse nodig in plaats van herhaling.

Wanneer een herstart toch nodig is, moet vooraf minstens het actuele tijdstip, betrokken gebruikers of locaties, servicenaam, logbestand en verwachte impact worden genoteerd.

Voor de herstart controleren

Voor een service-herstart moet men kort documenteren wat betrokken is. Dat bespaart tijd wanneer de fout terugkomt of een supportcase nodig wordt.

Praktische voorcontrole:

1. Betrokken module afbakenen, bijvoorbeeld WebAdmin, IPsec, DNS, DHCP, IPS of WAF.
2. Controleren of de firewall als geheel stabiel is of meerdere services uitvallen.
3. Controleren of er op dat moment admins, VPN-gebruikers of kritieke locaties verbonden zijn.
4. Bij HA-clusters controleren op welke node wordt gewerkt en welke node actief is.
5. Passend logbestand openen en de laatste meldingen veiligstellen.
6. Opslagruimte controleren wanneer debug, grote logs of PCAP-bestanden betrokken zijn.
7. Indien nodig logs voor de herstart exporteren.
8. Afbreekcriterium vastleggen: wanneer wordt de herstart gestopt, verschoven of geëscaleerd?

Voor HA-omgevingen is daarnaast Sophos Firewall HA Cluster Varianten begrijpen relevant. Wanneer logs voor een externe analyse nodig zijn, past Sophos Firewall logs voor support en analyse veiligstellen.

Eerst bewijs veiligstellen wanneer de fout terugkomt

Een service-herstart kan een symptoom tijdelijk oplossen, maar tegelijk de toestand veranderen die voor de oorzaakanalyse belangrijk zou zijn. Wanneer een probleem herhaaldelijk optreedt, moet men daarom voor de volgende herstart eerst een klein bewijsvenster veiligstellen.

Zinvolle minimale gegevens:

• exact tijdstip met tijdzone
• betrokken service en betrokken functie
• laatste relevante meldingen uit het passende logbestand
• statusuitvoer van de service voor de herstart
• systeembelasting, opslagruimte of rapport-/database-aanwijzingen wanneer de GUI traag is
• betrokken gebruikers, tunnels, interfaces, regels of locaties
• laatste configuratiewijziging, firmwarewijziging, hotfix of HA-gebeurtenis

Dat is vooral belangrijk wanneer dezelfde service meerdere keren opnieuw werd gestart. Dan is de herstart alleen nog een directe maatregel. De eigenlijke taak is de vraag waarom de service herhaaldelijk hangt, crasht, blokkeert of geen nieuwe logs meer schrijft.

Herstart in supportcase documenteren

Wanneer een service-herstart deel is van een supportcase, onderhoudsvenster of terugkerend probleem, moet men de actie kort documenteren. Dat hoeft geen lang rapport te zijn. Belangrijk is dat later duidelijk blijft welke service wanneer, waarom en met welk resultaat opnieuw gestart werd.

Praktische notitiesjabloon:

Date/time and time zone:
Firewall / HA node:
Service:
Command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Deze notitie is vooral nuttig wanneer een fout na enkele uren of dagen terugkomt. Dan ziet men meteen of steeds dezelfde service betrokken is, of de herstart alleen kortstondig helpt of dat een dieper probleem zoals opslagruimte, databasetoestand, HA-gedrag of een productfout waarschijnlijker wordt.

Services via WebAdmin opnieuw starten

Sommige services kunnen direct via WebAdmin opnieuw worden gestart. Dat is de eenvoudigste route wanneer de GUI nog bereikbaar is en de gewenste service daar zichtbaar is.

Het officiële menupad is System services > Services. Daar kan men services starten, stoppen en opnieuw starten. Als een service niet geconfigureerd is, is de knop onder Manage grijs.

WebAdmin biedt vooral duidelijk afgebakende services, bijvoorbeeld Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot en Packet capture and Live connections. Voor de klik moet duidelijk zijn of de service direct in het datapad ligt, of actieve gebruikers geraakt worden en hoe men het resultaat daarna controleert.

Twee details zijn operationeel belangrijk: Anti-spam kan alleen worden gestart wanneer er een inbound of outbound spam policy bestaat. Als men Packet capture and Live connections stopt, worden niet alleen lopende captures beëindigd, maar worden live connections ook niet meer weergegeven.

Voor een eerste inschatting is daarnaast Control Center > System nuttig. De services-status toont daar of alle services normaal draaien of dat er een warning of alert is. Een klik op het pictogram toont de betrokken services. Dit vervangt geen functietest, maar helpt om een probleem met één service te onderscheiden van een bredere systeemtoestand.

Voor diepere troubleshooting, loganalyse of services zonder GUI-actie heeft men de Advanced Shell nodig.

Wanneer alleen de WebAdmin GUI zelf niet meer reageert, moet dit algemene artikel niet de eerste stap zijn. Daarvoor is er de gerichte handleiding Sophos Firewall WebAdmin GUI opnieuw starten.

Advanced Shell openen

Voor servicecommando’s is de Advanced Shell nodig. Toegang gebeurt meestal via SSH met de gebruiker admin.

Wanneer SSH nog niet voorbereid is, helpt Sophos Firewall via SSH verbinden. SSH-toegang mag alleen vanuit vertrouwde adminnetwerken worden toegestaan. Voor de login moet de SSH-fingerprint worden gecontroleerd, vooral na reimage, hardwarevervanging of IP-wissel. De passende hardening staat in Device Access en Local Service ACL op Sophos Firewall.

Sophos sluit inactieve SSH-sessies na 15 minuten. Bij langere analyses moet men daarom lopende commando’s, open logweergaven en mogelijke onderbrekingen bewust inplannen.

Na de login opent men de Advanced Shell via:

5. Device Management > Advanced Shell

De Advanced Shell biedt vergaande systeemtoegang. Commando’s moeten daar alleen worden uitgevoerd wanneer de betrokken service en de verwachte impact duidelijk zijn.

Wanneer alleen de status gecontroleerd of een logbestand gelezen moet worden, moet het eerst bij lezende commando’s blijven. Herstarts, Stop/Start en debug zijn ingrepen en horen in een bewust analysevenster.

Services weergeven

Een lijst van de beschikbare services toont:

service -S

Wanneer een bepaalde service wordt gezocht, kan men de uitvoer filteren:

service -S | grep strongswan
service -S | grep zebra
service -S | grep dns

Technische servicenamen spreken niet altijd voor zich. Voor een herstart moet de servicenaam daarom worden vergeleken met het betrokken functiegebied.

• strongswan: Site-to-Site IPsec en IPsec Remote Access; tunnelstatus, peer, geplande onderbreking, strongswan.log
• zebra: routing en statische routes; routingtabel, SD-WAN/gatewaystatus, betrokken locaties
• dnsd: DNS-service van de firewall; DNS Request Routes, clienttest, dnsd.log
• dhcpd: DHCP-lease-uitgifte; betrokken zone, leasebereik, testclient, dhcpd.log
• awed: Wireless Controller; betrokken Access Points, Central- of lokaal beheer, wireless logs

De uitgebreidere toewijzing staat in Sophos Firewall Troubleshooting: Services en logs.

Service opnieuw starten

Het basispatroon voor een herstart luidt:

service <service>:restart -ds nosync

Voorbeeld voor de routingservice zebra:

service zebra:restart -ds nosync

Belangrijk is de syntax met spatie: -ds nosync. Varianten zoals -dsnosync zijn niet hetzelfde en moeten niet uit oude notities worden overgenomen.

Bij een herstart wordt de service gestopt en opnieuw gestart. Afhankelijk van de service kan dat actieve verbindingen onderbreken. Bij routing, VPN, DNS, DHCP, Web Proxy, WAF of Wireless moet men daarom vooraf beoordelen wie getroffen kan worden.

Wanneer de service bij een securityrelevante module hoort, moet na de herstart niet alleen de status worden gecontroleerd. Doorslaggevend is of de verwachte beschermings- of verbindingsfunctie weer werkt en of nieuwe foutmeldingen in het log ontstaan.

Service stoppen en starten

Wanneer een service niet netjes op restart reageert of Sophos Support het zo voorschrijft, kan men Stop en Start apart uitvoeren:

service zebra:stop -ds nosync
service zebra:start -ds nosync

Tussen Stop en Start moet men niet onnodig lang wachten wanneer de service productief nodig is. Daarna moeten status en een functionele test worden uitgevoerd.

Service-status controleren

service zebra:status -ds nosync

Daarnaast moet het passende logbestand worden gecontroleerd. Bij routing is dat bijvoorbeeld:

tail -n 80 /log/zebra.log

Een succesvolle status is niet altijd voldoende. Doorslaggevend is of de betrokken functie weer werkt: VPN-tunnels verbinden, DNS antwoordt, DHCP geeft leases uit, WebAdmin laadt of routing functioneert.

Voorbeelden van veelvoorkomende services

De volgende voorbeelden tonen typische service-herstarts en vervangen geen analyse van de oorzaak.

Wireless Controller opnieuw starten

service awed:restart -ds nosync

SMTP Service opnieuw starten

service smtpd:restart -ds nosync

VPN IPsec Service opnieuw starten

service strongswan:restart -ds nosync

DNS Service opnieuw starten

service dnsd:restart -ds nosync

Bij IPsec-problemen moet aanvullend Sophos Firewall IPsec Troubleshooting worden gebruikt. Bij DNS-problemen is vaak DNS Request Routes op Sophos Firewall configureren of de DNS-/DHCP-toewijzing in Sophos Firewall Troubleshooting: Services en logs relevanter dan een pure service-herstart.

Gevoelige servicegebieden bewust behandelen

Niet elke service-herstart heeft dezelfde impact. Sommige services raken alleen een beheerinterface, andere liggen direct in het datapad of sturen authenticatie, VPN, routing of lokale diensten. Hoe dichter een service bij productieve traffic ligt, des te belangrijker zijn onderhoudsvenster, logcontrole en terugvalplan.

• IPsec / SSL VPN: Tunnels of Remote-Access-sessies kunnen afbreken; Gebruikers en locaties vooraf informeren, tunnels daarna actief controleren
• DNS / DHCP: Naamresolutie of lease-uitgifte kan kort verstoord zijn; Clienttest en logcontrole na de herstart inplannen
• Routing / SD-WAN: Paden, gateway-monitoring of locatieverbindingen kunnen geraakt worden; Routingtabel, gatewaystatus en bereikbaarheid controleren
• Web Proxy / IPS / TLS Inspection: Webtoegang of inspection kan kort worden beïnvloed; Log Viewer en betrokken policies na de herstart controleren
• WAF / Reverse Proxy: Gepubliceerde applicaties kunnen kort onbereikbaar zijn; externe URL en backend-bereikbaarheid testen
• WebAdmin: Admin-toegang wordt kort onderbroken; alternatieve toegang via SSH of lokale console gereedhouden
• Reporting / database / opslag: Analyse, reports of GUI-stabiliteit kunnen betrokken zijn; niet blind opnieuw starten, eerst opslagruimte en logs controleren

Wanneer een servicegebied niet eenduidig is, moet men eerst in Sophos Firewall Troubleshooting: Services en logs kijken voordat een herstart wordt uitgevoerd. Bij database-, opslag- of reportingthema’s is een ongerichte herstart zelden de beste eerste maatregel.

Na de herstart valideren

Na een service-herstart moet men niet alleen controleren of het commando zonder foutmelding terugkomt. Belangrijk is de functionele test.

Zinvolle checks:

• Service-status met service <service>:status -ds nosync controleren.
• Passend logbestand in /log op nieuwe fouten controleren.
• Betrokken functie met een echte test valideren.
• Log Viewer controleren wanneer firewallregels, NAT, web, IPS of VPN betrokken zijn.
• Bij HA-clusters controleren of de actieve node nog steeds zoals verwacht werkt.
• Debug deactiveren wanneer die voor of tijdens de herstart werd geactiveerd.
• Tijdelijke SSH- of Device-Access-vrijgaven verwijderen wanneer ze alleen voor de supportcase werden gezet.
• Bij terugkerende fouten logs veiligstellen en oorzaak analyseren, in plaats van services herhaaldelijk opnieuw te starten.

Afhankelijk van de service is een andere functionele test zinvol:

• IPsec / strongswan: Tunnelstatus, Log Viewer, strongswan.log, bereikbaarheid van een host aan de andere kant
• DNS / dnsd: interne en externe naamresolutie, DNS Request Routes, dnsd.log
• Routing / zebra: Routingtabel, gateway-monitoring, ping of traceroute via het betrokken pad
• WAF / Reverse Proxy: gepubliceerde URL extern testen, reverseproxy.log, backend-bereikbaarheid
• WebAdmin / tomcat en apache: Login, Dashboard, Log Viewer en tomcat.log controleren
• DHCP / dhcpd: Lease-uitgifte met testclient en dhcpd.log controleren

Wanneer een reboot beter is

Een volledige reboot is invasiever dan een service-herstart, maar kan zinvol worden wanneer meerdere centrale services hangen, opslag- of databaseproblemen zijn verholpen, Sophos Support het vraagt of de firewall na gerichte herstarts instabiel blijft.

De beslissing moet niet op gevoel vallen. Een service-herstart is beter wanneer een afzonderlijke module duidelijk betrokken is en de firewall verder stabiel werkt. Een reboot past eerder wanneer de toestand systeembreed onduidelijk of na een gerichte herstart nog steeds beschadigd is.

• Afzonderlijke service hangt: Ja, wanneer service en impact duidelijk zijn; Alleen wanneer de herstart niet helpt
• Meerdere services tonen fouten: Eerst logs en opslagruimte controleren; Ja, wanneer systeemtoestand in totaal instabiel is
• Firmware- of hotfixvenster loopt: Niet als vervanging voor geplande herstart; Ja, wanneer het updateproces het voorziet
• HA-cluster is instabiel: Alleen na rolcontrole en supportvrijgave; Alleen met onderhoudsvenster en HA-plan
• Opslagruimte of database werd opgeschoond: Alleen voor betrokken service; Ja, wanneer Sophos Support het als afsluiting vraagt
• Remote toegang is onzeker: Voorzichtig, laatste toegang kan afbreken; Alleen met lokale of alternatieve toegang

Voor een reboot moeten back-up, onderhoudsvenster, locatietoegang, HA-gedrag en impact op VPN, RED, Wireless, routing en gepubliceerde diensten bekend zijn. Bij remote locaties is daarnaast een terugweg nodig voor het geval de firewall na de herstart niet netjes online komt: lokale contactpersoon, out-of-band-toegang, werkende HA-tegenzijde of een duidelijk supportproces.

Na de reboot moet dezelfde validatie plaatsvinden als na een service-herstart, alleen breder: HA-status, licentiestatus, VPN-tunnels, SD-WAN-gateways, centrale logs, WebAdmin, Central-verbinding en de belangrijkste gepubliceerde diensten controleren. Voor recoverythema’s past daarnaast Sophos Firewall Backup en Restore goed plannen.

Beheerchecklist

• Betrokken module en servicenaam geïdentificeerd.
• Passend logbestand voor de herstart gecontroleerd.
• Mogelijke impact op gebruikers, VPN, routing of locaties beoordeeld.
• Indien nodig onderhoudsvenster of HA-context verduidelijkt.
• SSH-toegang en host-key-controle netjes voorbereid wanneer Advanced Shell nodig is.
• Service gericht opnieuw gestart.
• Status en logbestand na de herstart gecontroleerd.
• Functie met een echte test gevalideerd.
• Debug en tijdelijke toegangen na de analyse weer teruggebouwd.
• Terugkerende fouten gedocumenteerd en niet door herhaalde herstarts gecamoufleerd.

FAQ