Skript på Sophos Firewall utan cronjobb: säkra alternativ
Den som vill köra ett kommando regelbundet på en Sophos Firewall börjar ofta leta efter cronjobb, startskript eller beständiga shell-filer. Den offentliga SFOS-administrationen beskriver dock ingen generell driftmetod för detta. Brandväggen är en säkerhetsappliance och bör inte användas som automatiseringsserver.
För konfigurationsändringar är XML API, Sophos Central eller inbyggda SFOS-funktioner bättre alternativ. Tillstånd och fel bör övervakas av externa system via Syslog, SNMP eller sFlow. En lokal shell-baserad lösning hör bara hemma på en brandvägg om Sophos offentligt beskriver den för det specifika fallet eller om Sophos Support eller Professional Services medverkar.
⚠️ Viktigt: En konfigurationsbackup bevisar inte att egna filer, startmekanismer eller bakgrundsprocesser säkerhetskopieras och återställs efter en återställning, en HA-failover eller en firmwareuppgradering.
Snabbval
Innan en teknisk lösning väljs måste det vara tydligt vilken uppgift som ska automatiseras. Den här indelningen förhindrar att ett litet skript obemärkt blir en verksamhetskritisk del av brandväggsdriften.
| Uppgift | Lämplig driftmetod |
|---|---|
| Återkommande konfigurationsändring | XML API från ett kontrollerat automatiseringssystem |
| Samma policy på flera brandväggar | Sophos Central Firewall Group |
| Regelbunden konfigurationsbackup | Schema under Backup & firmware > Backup & restore |
| Övervaka tillstånd, trafik eller fel | Syslog, SNMP, sFlow eller Sophos Central Reporting |
| Engångsdiagnos | WebAdmin, Device Console eller ett kommando som dokumenterats av Sophos |
| Produktspecifik lösning | Exakt Sophos-instruktion eller bekräftat supportärende |
Om ett skript regelbundet ska starta om tjänster, radera filer eller återställa anslutningar är det ingen automatiseringslösning. Det döljer sannolikt ett fel. Undersök då först loggar, lagring, firmwareversion och det konkreta felbeteendet.
Varför lokala skript är problematiska
Ett shell-skript kan vara tekniskt litet men ändå göra driften svår att kontrollera. Det ligger utanför den normala WebAdmin-konfigurationen, saknar ofta Audit Trail och kan efter en uppdatering påverkas av ändrade filer, tjänster eller behörigheter.
Fyra risker är särskilt relevanta:
- Backup och återställning: Sophos beskriver backupen som en säkerhetskopia av brandväggskonfigurationen. Det finns ingen generell garanti för att egna shell-filer eller startmekanismer kan återställas.
- HA: Sophos synkroniserar konfigurationen från Primary till Auxiliary. Av detta får man inte dra slutsatsen att valfria lokala filer eller egenutvecklade processer fungerar identiskt på båda noderna.
- Firmware: En uppgradering kan ändra interna sökvägar, tjänster eller körningsbeteenden. En lokal anpassning måste därför omprövas efter varje uppgradering.
- Support: Sophos stöder de officiella API:erna och oförändrade Sophos-skript. För egenutvecklade integrationer hänvisar Sophos till partner eller Professional Services.
Dessutom finns risker som hemligheter i klartext, okontrollerade loggmängder, oändliga loopar och felsökning där ingen längre säkert vet om SFOS eller den lokala speciallösningen orsakar beteendet.
Alternativ som stöds
Använd en inbyggd SFOS-funktion
Kontrollera först om SFOS redan kan utföra uppgiften. Schemalagda säkerhetskopior, aviseringar, routing, SD-WAN, övervakning och central loggning ska hanteras i de avsedda menyerna. För en återkommande säkerhetskopiering behövs till exempel inget shell-skript. Schemat finns under Backup & firmware > Backup & restore.
För routing- eller systemtrafikuppgifter är en korrekt policy ofta bättre än ett kommando efter varje omstart. Artikeln SD-WAN-routing för svarspaket och systemtrafik beskriver den metod som stöds.
Hantera flera brandväggar via Sophos Central
Om flera brandväggar ska få samma policy kan en Firewall Group i Sophos Central passa bättre än ett eget skript. Sökvägen är My Products > Firewall Management > Firewalls. Gruppolicyer tillämpas på de tilldelade brandväggarna och statusen visas under Tasks Queue.
Central-grupper är inte en universell kopieringsfunktion. Lokala och centralt hanterade regler kan påverka varandras ordningsföljd, och alla konfigurationer kan inte återges i alla gruppstrukturer. Testa därför först med en testgrupp och kontrollera sedan Tasks Queue och de regler som faktiskt har tillämpats.
Använd XML API från ett externt system
För återkommande ändringar av objekt eller policyer är XML API den avsedda programmatiska metoden. Automatiseringen bör köras på ett hanterat system där kod, hemligheter, loggar, schema och återställning kan kontrolleras.
Förbered brandväggen så här:
- Skapa en administratörsprofil med endast de behörigheter som verkligen behövs under Profiles > Device access och spara den med Save.
- Klicka på Add under Authentication > Users, ange User type som Administrator, välj den nya profilen, begränsa Login restriction for device access medvetet och spara med Save.
- Lägg till automatiseringssystemet som ett strikt avgränsat värdobjekt under Hosts and services > IP host.
- Välj API access under Administration > API access.
- Välj endast det förberedda värdobjektet under Allowed IP hosts, lägg till det med knappen Add och spara med Apply. SFOS tillåter högst 64 poster här.
- Kontrollera under Administration > Device access att HTTPS är tillåtet från den zon som behövs. För WAN-åtkomst bör en strikt avgränsad Local service ACL exception rule användas i stället för att generellt öppna HTTPS för WAN.
API access är inaktiverat som standard. Efter en uppgradering till SFOS 22.0 omvandlas tidigare tillåtna IP-adresser till värdobjekt med prefixet apiconfig. Dessa äldre behörigheter bör ingå i nästa åtkomstgranskning.
Artikeln Säkra XML API-åtkomst till Sophos Firewall beskriver tjänstekonto, MFA-beteende, administratörsport, Local Service ACL och skydd av hemligheter i detalj. För förberedda eller jämförda konfigurationsändringar kan även Sophos Firewall Config Studio vara till hjälp.
⚠️ API är inte automatiskt säkert: Begränsa käll-IP-adressen, använd inte ett personligt konto med fullständiga administratörsrättigheter, lagra inte hemligheter i ett kodarkiv, ärende eller shell-historik och testa skrivoperationer i en testmiljö först.
Kör övervakningen utanför brandväggen
Ett övervakningssystem bör observera brandväggen utifrån. Annars kan den lokala processen saknas just när själva brandväggen har problem. Beroende på målet passar SNMP-baserad maskinvaruövervakning, sFlow-övervakning eller Central Firewall Reporting.
För långsiktig händelse- och säkerhetsanalys är en extern Syslog- eller SIEM-mottagare mer lämplig än ytterligare lokala loggfiler. Då finns uppgifterna kvar även om brandväggen startas om, slutar fungera eller ersätts.
När en lokal speciallösning kan vara försvarbar
Vissa supportärenden eller molndistributioner kräver en strikt avgränsad speciallösning. Det avgörande är inte om kommandot fungerar tekniskt, utan om det finns en aktuell Sophos-instruktion eller en bekräftad supportanvisning för exakt det scenariot.
Före implementeringen måste version, plattform, HA-läge och återställningsväg stämma överens med instruktionen. Ett skript från ett gammalt communityinlägg, en annan appliancemodell eller en tidigare SFOS-version är inget tillförlitligt godkännande för den egna miljön.
Om det bara finns en egen lösningsidé bör den först diskuteras med Sophos-partnern eller Professional Services. En generell instruktion för att lägga in egna startskript skulle här vara farligare än hjälpsam.
Avveckla ett befintligt skript säkert
Radera inte ett befintligt skript omedelbart. Först måste det bli tydligt vilket beroende verksamheten har av det.
- Frys ändringarna: Ändra tills vidare inte skriptet, startmekanismen eller den berörda brandväggen ytterligare.
- Dokumentera syftet: Dokumentera symptom, utlösare, önskat resultat, sökväg, användare, schema, hemligheter och ansvarig person.
- Observera effekten: Dokumentera loggar, processstatus, skapade filer och påverkade rutter, tjänster eller gränssnitt. Kontrollera båda noderna separat vid HA.
- Välj målmetod: Koppla funktionen till en inbyggd SFOS-inställning, Central, XML API eller extern övervakning.
- Testa ersättningen: Testa den nya processen utanför den produktiva brandväggen och logga resultat, fel och återställning.
- Byt kontrollerat: Aktivera ersättningen under underhållsfönstret, inaktivera det lokala skriptet och utför funktionstestet.
- Planera efterkontroll: Kontrollera igen efter omstart, failover och nästa firmwareuppgradering, i den mån dessa händelser är relevanta för funktionen.
En aktuell säkerhetskopia ska ingå före ändringen. Skapa eller återställ en Sophos Firewall-backup beskriver Secure Storage Master Key, återställning och kompatibilitet. Backupen skyddar den dokumenterade konfigurationen men ersätter inte en separat inventering av lokala anpassningar.
Validering och återställning
Ett lyckat API-svar eller en process som körs bevisar inte att den avsedda uppgiften har genomförts. Efter bytet måste exakt det resultat testas som tidigare var beroende av skriptet: att regeln finns, rutten är aktiv, backupen har skapats, målet kan nås eller larmet har kommit fram till övervakningen.
Kontrollera dessutom Audit Trail och berörda objekt vid API-ändringar. Om trafiken påverkas ska Log Viewer, Rule ID, NAT Rule ID, Policy Test eller Packet Capture ingå i verifieringen. Central-ändringar kontrolleras i Tasks Queue och därefter direkt på en berörd brandvägg.
Återställningen består inte i att snabbt aktivera det gamla skriptet igen. Rulla först tillbaka den nya ändringen och återskapa det dokumenterade utgångsläget. Endast om den gamla speciallösningen medvetet har verifierats som reservlösning får den återaktiveras under en begränsad tid.
Driftsrekommendation
Lokala skript bör dokumenteras som ett tillfälligt undantag, inte som en normal brandväggsfunktion. Varje undantag behöver en ansvarig, ett granskningsdatum, en testad avvecklingsplan och en tydlig uppgift om vilka Sophos-versioner som omfattas.
För nya krav gäller följande ordning: inbyggd SFOS-funktion, Sophos Central, extern automatisering via XML API, extern övervakning och först därefter ett specialfall som bekräftats av Sophos. Då blir ändringarna spårbara, HA och återställning mer förutsägbara och brandväggen förblir närmare produktens stödda tillstånd.