Script su Sophos Firewall senza cronjob: alternative sicure

Chi desidera eseguire regolarmente un comando su Sophos Firewall tende subito a cercare cronjob, script di avvio o file shell persistenti. Tuttavia, la documentazione pubblica di amministrazione di SFOS non descrive una modalità operativa generale per questo scopo. Il firewall è una Security Appliance e non dovrebbe diventare un server di automazione.

Per le modifiche alla configurazione, XML API, Sophos Central o le funzioni native di SFOS rappresentano la soluzione migliore. Stati ed errori dovrebbero essere monitorati da sistemi esterni tramite Syslog, SNMP o sFlow. Un workaround shell locale deve essere installato sul firewall solo se Sophos lo descrive pubblicamente per il caso specifico oppure se è seguito da Sophos Support o Professional Services.

⚠️ Importante: un backup della configurazione non dimostra che file creati manualmente, meccanismi di avvio o processi in background vengano salvati e siano nuovamente disponibili dopo un ripristino, un failover HA o un aggiornamento del firmware.

Decisione rapida

Prima di scegliere una soluzione tecnica, è necessario definire con chiarezza quale attività deve essere automatizzata. Questa classificazione evita che un piccolo script diventi, senza che nessuno se ne accorga, una componente critica del funzionamento del firewall.

Se uno script deve riavviare regolarmente servizi, eliminare file o ripristinare connessioni, non si tratta di una soluzione di automazione. Probabilmente sta mascherando un malfunzionamento. In tal caso, occorre prima esaminare log, spazio di archiviazione, versione del firmware e problema concreto.

Perché gli script locali sono problematici

Uno script shell può essere tecnicamente piccolo e rendere comunque difficile il controllo operativo. Si trova al di fuori della normale configurazione WebAdmin, spesso non dispone di Audit Trail e, dopo un aggiornamento, può interagire con file, servizi o autorizzazioni differenti.

Quattro rischi sono particolarmente rilevanti:

• Backup e ripristino: Sophos descrive il backup come una copia della configurazione del firewall. Non esiste una garanzia generale di ripristino per file shell o meccanismi di avvio personalizzati.
• HA: Sophos sincronizza la configurazione dal Primary all’Auxiliary. Da ciò non si può dedurre che file locali arbitrari o processi realizzati internamente funzionino in modo identico su entrambi i nodi.
• Firmware: un aggiornamento può modificare percorsi interni, servizi o comportamento di esecuzione. Una personalizzazione locale deve pertanto essere rivalutata dopo ogni aggiornamento.
• Supporto: Sophos supporta le API ufficiali e gli script Sophos non modificati. Per le integrazioni sviluppate internamente, Sophos rimanda ai partner o a Professional Services.

A questi rischi si aggiungono Secrets in chiaro, quantità di log incontrollate, cicli infiniti e una ricerca degli errori in cui nessuno sa più con certezza se il comportamento sia causato da SFOS o dal workaround locale.

Alternative supportate

Utilizzare una funzione nativa di SFOS

Per prima cosa, verificare se SFOS svolge già autonomamente l’attività. Backup pianificati, notifiche, routing, SD-WAN, monitoring e registrazione centralizzata devono essere configurati nei menu previsti. Per un backup ricorrente, ad esempio, non serve uno script shell: la pianificazione si trova in Backup & firmware > Backup & restore.

Per le attività di routing o di System Traffic, spesso è sufficiente una policy corretta invece di un comando dopo ogni riavvio. L’articolo Routing SD-WAN per Reply Packets e System Traffic illustra la procedura supportata.

Gestire più firewall tramite Sophos Central

Se più firewall devono ricevere la stessa policy, una Firewall Group in Sophos Central può essere più adatta di uno script personalizzato. Il percorso è My Products > Firewall Management > Firewalls. Le policy di gruppo vengono applicate ai firewall assegnati; lo stato è visibile in Tasks Queue.

I gruppi Central non sono semplicemente una funzione di copia universale. Le regole locali e quelle gestite centralmente possono influenzarsi reciprocamente nell’ordine, e non ogni configurazione può essere rappresentata in qualsiasi struttura di gruppo. Per questo motivo, occorre prima effettuare una verifica con un gruppo di test e poi controllare la Tasks Queue e le regole effettivamente applicate.

Utilizzare XML API da un sistema esterno

Per modifiche ricorrenti a oggetti o policy, XML API è il metodo programmatico previsto. L’automazione dovrebbe essere eseguita su un sistema gestito, sul quale sia possibile controllare codice, Secrets, log, pianificazione e rollback.

Il firewall viene preparato come segue:

1. In Profiles > Device access, creare un profilo amministratore con i soli diritti effettivamente necessari e salvarlo con Save.
2. In Authentication > Users, fare clic su Add, impostare User type su Administrator, selezionare il nuovo profilo, limitare consapevolmente Login restriction for device access e salvare con Save.
3. In Hosts and services > IP host, registrare il sistema di automazione come oggetto host circoscritto.
4. In Administration > API access, selezionare API access.
5. In Allowed IP hosts, selezionare esclusivamente l’oggetto host preparato, aggiungerlo con il pulsante Add e salvare con Apply. SFOS consente un massimo di 64 voci.
6. In Administration > Device access, verificare che HTTPS sia consentito dalla zona necessaria. Per l’accesso WAN è preferibile utilizzare una Local service ACL exception rule restrittiva anziché abilitare HTTPS in modo generale per WAN.

API access è disattivato per impostazione predefinita. Dopo un aggiornamento a SFOS 22.0, gli indirizzi IP precedentemente autorizzati vengono convertiti in oggetti host con il prefisso apiconfig; queste autorizzazioni preesistenti devono essere incluse nella successiva revisione degli accessi.

L’articolo Proteggere l’accesso XML API su Sophos Firewall tratta in dettaglio account di servizio, comportamento MFA, porta amministrativa, Local Service ACL e protezione dei Secrets. Per preparare o confrontare modifiche alla configurazione può inoltre essere utile Sophos Firewall Config Studio.

⚠️ API non significa automaticamente sicurezza: limitare l’IP sorgente, non utilizzare un account personale con diritti amministrativi completi, non archiviare Secrets in repository, ticket o cronologia della shell e verificare prima le operazioni di scrittura in un ambiente di test.

Eseguire il monitoring al di fuori del firewall

Un sistema di monitoring dovrebbe osservare il firewall dall’esterno. In caso contrario, il processo locale potrebbe mancare proprio quando il firewall stesso presenta un problema. A seconda dell’obiettivo, sono indicati Monitoring hardware con SNMP, Monitoring con sFlow o Central Firewall Reporting.

Per l’analisi a lungo termine degli eventi e della sicurezza, un destinatario Syslog o SIEM esterno è più appropriato di ulteriori file di log locali. In questo modo, i dati restano disponibili anche quando il firewall viene riavviato, si guasta o viene sostituito.

Quando un workaround locale può essere accettabile

Alcuni casi di supporto o deployment nel cloud richiedono un workaround strettamente circoscritto. L’aspetto decisivo non è se il comando funziona tecnicamente, ma se per quello specifico scenario esiste una procedura Sophos aggiornata o un’istruzione di supporto confermata.

Prima dell’implementazione, versione, piattaforma, modalità HA e procedura di rimozione devono corrispondere alle indicazioni. Uno script tratto da un vecchio post della Community, da un altro modello di appliance o da una precedente versione di SFOS non costituisce un’approvazione attendibile per il proprio ambiente.

Se esiste solo una soluzione sviluppata internamente, è opportuno chiarirla prima con il partner Sophos o con Professional Services. Una guida generica per integrare script di avvio personalizzati sarebbe, in questo caso, più pericolosa che utile.

Sostituire in sicurezza uno script esistente

Non eliminare immediatamente uno script esistente. Prima occorre chiarire quale dipendenza operativa esista nei suoi confronti.

1. Bloccare le modifiche: per il momento, non modificare ulteriormente lo script, il meccanismo di avvio e il firewall interessato.
2. Documentare lo scopo: registrare sintomo, evento scatenante, risultato desiderato, percorso, utente, pianificazione, Secrets e persona responsabile.
3. Osservare gli effetti: documentare log, stato del processo, file generati e rotte, servizi o interfacce interessati. In HA, controllare separatamente entrambi i nodi.
4. Scegliere il percorso di destinazione: assegnare la funzione a un’impostazione nativa di SFOS, Central, XML API o monitoring esterno.
5. Testare la sostituzione: verificare il nuovo processo al di fuori del firewall di produzione e registrare esito, errori e rollback.
6. Eseguire una migrazione controllata: durante la finestra di manutenzione, attivare la soluzione sostitutiva, disabilitare lo script locale ed eseguire il test funzionale.
7. Pianificare i controlli successivi: eseguire una nuova verifica dopo un riavvio, un failover e il successivo aggiornamento del firmware, nella misura in cui tali eventi siano rilevanti per la funzione.

Prima della modifica è necessario disporre di un backup aggiornato. Creare o ripristinare un backup di Sophos Firewall spiega Secure Storage Master Key, ripristino e compatibilità. Il backup protegge la configurazione documentata, ma non sostituisce un inventario separato delle personalizzazioni locali.

Validazione e rollback

Una risposta API corretta o un processo in esecuzione non dimostrano ancora che l’attività operativa sia stata completata. Dopo la migrazione, è necessario verificare esattamente il risultato da cui dipendeva lo script: regola presente, rotta attiva, backup creato, destinazione raggiungibile o allarme ricevuto dal sistema di monitoring.

Per le modifiche API, controllare inoltre Audit Trail e gli oggetti interessati. Se vi sono effetti sul traffico, la verifica deve includere Log Viewer, Rule ID, NAT Rule ID, Policy Test o Packet Capture. Le modifiche effettuate tramite Central vengono controllate nella Tasks Queue e successivamente direttamente su uno dei firewall interessati.

Il rollback non consiste nel riattivare frettolosamente il vecchio script. Occorre prima annullare la nuova modifica e ripristinare lo stato iniziale documentato. Il vecchio workaround può essere riattivato per un periodo limitato soltanto se è stato verificato consapevolmente come opzione di ripiego.

Raccomandazione operativa

Nella documentazione operativa, gli script locali dovrebbero comparire come eccezioni temporanee, non come normali funzioni del firewall. Ogni eccezione necessita di un Owner, una data di revisione, una procedura di rimozione collaudata e un’indicazione chiara delle versioni di Sophos coperte.

Per le nuove esigenze, l’ordine da seguire è: funzione nativa di SFOS, Sophos Central, automazione esterna tramite XML API, monitoring esterno e solo successivamente un caso speciale confermato da Sophos. In questo modo le modifiche restano tracciabili, HA e ripristino diventano più pianificabili e il firewall rimane più vicino allo stato del prodotto supportato.

FAQ