Sophos Firewall-scripts zonder cronjob: veilige alternatieven
Wie regelmatig een opdracht op een Sophos Firewall wil uitvoeren, zoekt al snel naar cronjobs, startscripts of persistente shellbestanden. De openbare SFOS-beheerdocumentatie beschrijft hiervoor echter geen algemene werkwijze. De firewall is een security appliance en mag geen automatiseringsserver worden.
Voor configuratiewijzigingen zijn de XML API, Sophos Central of native SFOS-functies de betere keuze. Statussen en fouten moeten door externe systemen via Syslog, SNMP of sFlow worden bewaakt. Een lokale shellworkaround hoort alleen op een firewall thuis wanneer Sophos deze voor het concrete geval openbaar beschrijft of wanneer Sophos Support dan wel Professional Services de uitvoering begeleidt.
⚠️ Belangrijk: Een configuratieback-up bewijst niet dat zelf aangemaakte bestanden, startmechanismen of achtergrondprocessen worden opgeslagen en na herstel, HA-failover of een firmware-upgrade opnieuw aanwezig zijn.
Snelle keuze
Voor elke technische oplossing moet duidelijk zijn welke taak moet worden geautomatiseerd. Deze indeling voorkomt dat een klein script ongemerkt een kritiek onderdeel van het firewallbeheer wordt.
| Taak | Geschikte werkwijze |
|---|---|
| Terugkerende configuratiewijziging | XML API vanaf een gecontroleerd automatiseringssysteem |
| Dezelfde policy op meerdere firewalls | Sophos Central Firewall Group |
| Regelmatige configuratieback-up | Planning onder Backup & firmware > Backup & restore |
| Status, traffic of fouten bewaken | Syslog, SNMP, sFlow of Sophos Central Reporting |
| Eenmalige diagnose | WebAdmin, Device Console of een door Sophos gedocumenteerde opdracht |
| Productspecifieke workaround | Exacte Sophos-handleiding of bevestigd supportgeval |
Wanneer een script regelmatig services moet herstarten, bestanden moet verwijderen of verbindingen moet resetten, is dat geen automatiseringsoplossing. Waarschijnlijk maskeert het een storing. Onderzoek dan eerst de logs, opslag, firmwareversie en het concrete foutbeeld.
Waarom lokale scripts problematisch zijn
Een shellscript kan technisch klein zijn en het beheer toch moeilijk controleerbaar maken. Het bevindt zich buiten de normale WebAdmin-configuratie, heeft vaak geen Audit Trail en kan na een update botsen met gewijzigde bestanden, services of machtigingen.
Vier risico’s zijn bijzonder relevant:
- Back-up en herstel: Sophos beschrijft de back-up als een beveiliging van de firewallconfiguratie. Voor eigen shellbestanden of startmechanismen bestaat geen algemene herstelgarantie.
- HA: Sophos synchroniseert de configuratie van de Primary naar de Auxiliary. Daaruit mag niet worden afgeleid dat willekeurige lokale bestanden of zelfgebouwde processen op beide nodes identiek functioneren.
- Firmware: Een upgrade kan interne paden, services of runtimegedrag wijzigen. Een lokale aanpassing moet daarom na elke upgrade opnieuw worden beoordeeld.
- Support: Sophos ondersteunt de officiële API’s en ongewijzigde Sophos-scripts. Voor zelfontwikkelde integraties verwijst Sophos naar partners of Professional Services.
Daar komen secrets in platte tekst, ongecontroleerde hoeveelheden logdata, eindeloze lussen en probleemoplossing bij waarbij niemand nog zeker weet of SFOS of de lokale workaround het gedrag veroorzaakt.
Ondersteunde alternatieven
Native SFOS-functie gebruiken
Controleer eerst of SFOS de taak al zelf uitvoert. Geplande back-ups, meldingen, routing, SD-WAN, monitoring en centrale logging horen thuis in de daarvoor bestemde menu’s. Voor een terugkerende back-up is bijvoorbeeld geen shellscript nodig; de planning staat onder Backup & firmware > Backup & restore.
Bij taken rond routing of system traffic helpt een correcte policy vaak beter dan een opdracht na elke herstart. Het artikel SD-WAN-routing voor reply packets en system traffic beschrijft de ondersteunde werkwijze.
Meerdere firewalls via Sophos Central beheren
Wanneer meerdere firewalls dezelfde policy moeten krijgen, kan een Firewall Group in Sophos Central beter passen dan een eigen script. Het pad is My Products > Firewall Management > Firewalls. Groepspolicies worden op de toegewezen firewalls toegepast; de status is zichtbaar onder Tasks Queue.
Central-groepen zijn niet simpelweg een universele kopieerfunctie. Lokale en centraal beheerde regels kunnen elkaars volgorde beïnvloeden en niet elke configuratie kan in elke groepsstructuur worden opgenomen. Test daarom eerst met een testgroep en controleer vervolgens de Tasks Queue en de regels die daadwerkelijk zijn toegepast.
XML API extern gebruiken
Voor terugkerende wijzigingen aan objecten of policies is de XML API de daarvoor bedoelde programmeerbare werkwijze. De automatisering moet op een beheerd systeem draaien waarop code, secrets, logs, planning en rollback kunnen worden gecontroleerd.
Bereid de firewall als volgt voor:
- Maak onder Profiles > Device access een beheerdersprofiel aan met uitsluitend de werkelijk benodigde rechten en sla dit op met Save.
- Klik onder Authentication > Users op Add, stel User type in op Administrator, selecteer het nieuwe profiel, beperk Login restriction for device access bewust en sla de configuratie op met Save.
- Leg onder Hosts and services > IP host het automatiseringssysteem vast als een strikt begrensd hostobject.
- Selecteer onder Administration > API access API access.
- Selecteer onder Allowed IP hosts alleen het voorbereide hostobject, voeg het toe met de Add button en sla de configuratie op met Apply. SFOS staat hier maximaal 64 vermeldingen toe.
- Controleer onder Administration > Device access of HTTPS vanuit de benodigde zone is toegestaan. Gebruik voor toegang via WAN bij voorkeur een strikt begrensde Local service ACL exception rule in plaats van HTTPS algemeen voor WAN open te stellen.
API access is standaard uitgeschakeld. Na een upgrade naar SFOS 22.0 worden eerder toegestane IP-adressen omgezet in hostobjecten met het voorvoegsel apiconfig; deze bestaande vrijgaven moeten tijdens de volgende toegangsreview worden gecontroleerd.
Het artikel XML API-toegang tot Sophos Firewall beveiligen behandelt het serviceaccount, MFA-gedrag, de beheerpoort, Local Service ACL en de bescherming van secrets uitvoerig. Voor voorbereide of vergeleken configuratiewijzigingen kan daarnaast Sophos Firewall Config Studio helpen.
⚠️ Een API is niet automatisch veilig: Beperk het bron-IP, gebruik geen persoonlijk account met volledige beheerdersrechten, plaats secrets niet in een repository, ticket of shellgeschiedenis en test schrijfbewerkingen eerst in een testomgeving.
Monitoring buiten de firewall uitvoeren
Een monitoringsysteem moet de firewall van buitenaf observeren. Anders kan het lokale proces juist ontbreken wanneer de firewall zelf een storing heeft. Afhankelijk van het doel zijn SNMP-hardwaremonitoring, sFlow-monitoring of Central Firewall Reporting geschikt.
Voor langdurige analyse van gebeurtenissen en beveiligingsmeldingen is een externe Syslog- of SIEM-ontvanger zinvoller dan extra lokale logbestanden. Daardoor blijven gegevens ook beschikbaar wanneer de firewall opnieuw wordt opgestart, uitvalt of wordt vervangen.
Wanneer een lokale workaround aanvaardbaar kan zijn
Voor sommige supportgevallen of cloudimplementaties is een strikt begrensde workaround nodig. Doorslaggevend is niet of de opdracht technisch werkt, maar of voor precies dit scenario een actuele Sophos-handleiding of een bevestigde supportinstructie bestaat.
Voor de implementatie moeten versie, platform, HA-modus en terugdraaipad bij de handleiding passen. Een script uit een oud Community-bericht, voor een ander appliancemodel of voor een eerdere SFOS-versie vormt geen betrouwbare goedkeuring voor de eigen omgeving.
Wanneer er alleen een zelfbedachte oplossing bestaat, moet deze eerst met de Sophos-partner of Professional Services worden afgestemd. Een algemene handleiding voor het integreren van eigen startscripts zou hier gevaarlijker dan nuttig zijn.
Een bestaand script veilig uitfaseren
Verwijder een bestaand script niet meteen. Eerst moet duidelijk worden welke afhankelijkheid de organisatie ervan heeft.
- Wijzigingen bevriezen: Wijzig het script, het startmechanisme en de betrokken firewall voorlopig niet verder.
- Doel vastleggen: Documenteer symptoom, trigger, gewenst resultaat, pad, gebruiker, planning, secrets en verantwoordelijke persoon.
- Werking observeren: Leg logs, processtatus, aangemaakte bestanden en beïnvloede routes, services of interfaces vast. Controleer bij HA beide nodes afzonderlijk.
- Doeloplossing kiezen: Koppel de functie aan een native SFOS-instelling, Central, XML API of externe monitoring.
- Vervanging testen: Test de nieuwe werkwijze buiten de productiefirewall en leg succes, fouten en rollback vast.
- Gecontroleerd omschakelen: Activeer tijdens het onderhoudsvenster de vervanging, schakel het lokale script uit en voer de functionele test uit.
- Nacontrole plannen: Controleer opnieuw na een herstart, failover en de volgende firmware-upgrade, voor zover deze gebeurtenissen relevant zijn voor de functie.
Voor de wijziging is een actuele back-up nodig. Een Sophos Firewall-back-up maken of herstellen legt Secure Storage Master Key, herstel en compatibiliteit uit. De back-up beschermt de gedocumenteerde configuratie, maar vervangt geen afzonderlijke inventarisatie van lokale aanpassingen.
Validatie en rollback
Een geslaagde API-respons of een actief proces bewijst nog niet dat de functionele taak is uitgevoerd. Na de omschakeling moet precies het resultaat worden getest waarvan het script voorheen afhankelijk was: regel aanwezig, route actief, back-up gemaakt, doel bereikbaar of waarschuwing in het monitoringsysteem ontvangen.
Controleer bij API-wijzigingen bovendien de Audit Trail en de betrokken objecten. Bij impact op traffic horen Log Viewer, Rule ID, NAT Rule ID, Policy Test of Packet Capture bij de acceptatie. Central-wijzigingen worden in de Tasks Queue en daarna rechtstreeks op een betrokken firewall gecontroleerd.
Rollback betekent niet dat het oude script overhaast opnieuw wordt ingeschakeld. Draai eerst de nieuwe wijziging terug en herstel de gedocumenteerde uitgangssituatie. Alleen wanneer de oude workaround bewust als terugvaloptie is getest, mag deze tijdelijk opnieuw worden geactiveerd.
Beheeraanbeveling
Lokale scripts moeten in de beheerdocumentatie als tijdelijke uitzondering worden opgenomen, niet als normale firewallfunctie. Elke uitzondering heeft een eigenaar, een reviewdatum, een geteste rollbackprocedure en een duidelijke vermelding nodig van de ondersteunde Sophos-versies.
Voor nieuwe vereisten geldt deze volgorde: native SFOS-functie, Sophos Central, externe XML API-automatisering, externe monitoring en pas daarna een door Sophos bevestigd uitzonderingsgeval. Zo blijven wijzigingen traceerbaar, worden HA en herstel beter planbaar en blijft de firewall dichter bij de ondersteunde productstatus.