Vai al contenuto
Avanet

Script Sophos Firewall senza Cronjob: Rischi e Alternative

Sophos Firewall

In casi particolari, gli script shell locali su una Sophos Firewall possono sembrare allettanti: un controllo ricorrente, un Heartbeat, una soluzione temporanea dopo un riavvio o una piccola modifica di rete che dovrebbe avvenire automaticamente. Proprio in questo caso bisogna essere molto cauti. Una Sophos Firewall è un dispositivo di sicurezza e non un server di automazione generale.

Gli script locali persistenti, le modifiche alle sequenze di avvio o i processi in background costruiti autonomamente possono complicare gli aggiornamenti, il comportamento HA, i casi di supporto, la sicurezza e la risoluzione dei problemi. In molti casi, la questione non è come sostituire un Cronjob, ma quale alternativa supportata o meglio controllabile risolve il problema reale.

⚠️ Attenzione: Le modifiche agli script shell o di avvio locali su una Sophos Firewall non dovrebbero essere utilizzate come standard operativo normale. Prima di ogni caso speciale, sono necessari backup, test, piano di rollback, finestra di manutenzione, responsabilità chiara e una valutazione se esiste un percorso supportato.

Decisione rapida

Quando viene proposto uno script locale, dovrebbe prima essere identificato il compito reale. Successivamente, è spesso facile capire se la firewall stessa è il luogo giusto per l’esecuzione.

  • Una configurazione deve essere modificata regolarmente?: Lo script modificherebbe oggetti firewall, regole, rotte o servizi. Verificare l’automazione esterna tramite XML API o Sophos Central.
  • Uno stato deve essere monitorato?: Lo script controlla interfaccia, servizio, VPN, memoria o raggiungibilità. Utilizzare monitoraggio esterno, SNMP, sFlow, Central Reporting o Syslog.
  • Un errore deve essere mascherato automaticamente?: Lo script riavvia servizi, elimina file o ripristina connessioni. Analizzare la causa, salvare i log e verificare il caso di supporto o la versione del firmware.
  • Un comportamento non supportato deve essere imposto permanentemente?: La modifica influisce sulla logica di avvio, sul routing, sull’elaborazione dei pacchetti o sui file locali. Modificare il design o utilizzare una funzione supportata.

Se nessuna di queste domande è risolta chiaramente, la soluzione temporanea non è ancora pronta per una firewall produttiva. In tal caso, il problema dovrebbe essere descritto più precisamente: sintomo, innesco, versione interessata, risultato desiderato e percorso operativo accettabile.

Perché gli script locali sono problematici

Uno script locale può sembrare piccolo, ma in un ambiente firewall può rapidamente diventare critico per l’operatività. La firewall elabora traffico produttivo, VPN, autenticazione, NAT, logging e funzioni di sicurezza. Un processo in background difettoso o una modifica non chiara al comportamento di avvio può quindi avere effetti molto più grandi rispetto a un normale sistema Linux.

Rischi tipici:

  • Supportabilità: Le sequenze di avvio modificate autonomamente sono difficili da classificare nei casi di supporto.
  • Aggiornamenti firmware: Gli aggiornamenti possono modificare file, servizi, percorsi o comportamenti. Uno script potrebbe quindi funzionare diversamente o non funzionare affatto.
  • Cluster HA: Le modifiche devono essere comprese per ogni nodo. Dopo un failover o un cambio di ruolo, uno script potrebbe mancare o avere un effetto doppio.
  • Sicurezza: Gli script spesso contengono credenziali, URL o logica interna che non è adeguatamente protetta e documentata.
  • Prestazioni e archiviazione: Cicli infiniti, output di log o chiamate di rete frequenti possono sovraccaricare CPU, memoria o partizioni.
  • Risoluzione dei problemi: Uno script può coprire i sintomi. Quindi la causa reale non viene risolta.

Se si verificano già problemi di memoria, reporting o log, la causa dovrebbe essere esaminata per prima. A tal fine, sono adatti Pulizia della memoria e dei report di Sophos Firewall, Risoluzione dei problemi di Sophos Firewall: Servizi e Log e Salvataggio dei log di Sophos Firewall per supporto e analisi.

Prima esaminare l’alternativa adatta

Molti compiti per i quali in passato è stato creato uno script locale possono oggi essere risolti in modo più pulito tramite funzioni esistenti, automazione esterna o monitoraggio.

Il principio più importante: l’automazione dovrebbe funzionare il più possibile al di fuori della firewall. In questo modo, versioning, segreti, logging, monitoraggio, rollback e responsabilità sono meglio controllabili.

Quando discutere di uno script locale

Uno script locale è al massimo un caso speciale. Dovrebbe essere discusso solo se un problema concreto non è risolvibile tramite WebAdmin, Device Console, XML API, Central, Syslog, monitoraggio o un’altra funzione supportata.

Un approccio locale può essere sensato solo se tutti i punti sono soddisfatti:

  • Lo scopo è strettamente limitato e documentato.
  • Non si tratta di una sostituzione permanente per una funzione operativa mancante.
  • La modifica è stata testata in un ambiente di prova.
  • È disponibile un backup completo e un chiaro percorso di rollback.
  • L’impatto su HA, aggiornamenti firmware e supporto è stato valutato.
  • C’è una persona responsabile che verifica lo script dopo aggiornamenti e failover.

Se questi punti non sono soddisfatti, non dovrebbe essere costruita alcuna soluzione temporanea locale. È meglio modificare il design reale o automatizzare il compito esternamente.

Requisiti minimi prima di un caso speciale

Prima di un caso speciale, non si dovrebbe sperimentare direttamente sulla firewall produttiva. Prima, la modifica viene trattata come un piccolo cambiamento.

Backup e ripristino

Prima della modifica, deve essere disponibile un backup aggiornato. Inoltre, dovrebbe essere chiaro dove si trova il Secure Storage Master Key e se un ripristino su hardware di riserva, appliance virtuale o ambiente HA è stato realisticamente testato.

Per modifiche critiche, un semplice backup di configurazione non è sempre sufficiente. Se la modifica riguarda file o processi locali, deve essere documentato ciò che è stato modificato al di fuori della configurazione normale.

HA e Failover

Nei cluster HA non basta considerare solo la firewall attiva. Bisogna sapere:

  • Su quale nodo esiste la modifica?
  • Cosa succede dopo un failover?
  • La modifica funziona dopo, una volta o due volte?
  • Viene trattata allo stesso modo su entrambi i nodi durante gli aggiornamenti firmware?

Proprio per questo motivo, gli script locali sono particolarmente delicati negli ambienti HA.

Logging e controllo

Un caso speciale senza controllo non è un’operazione pulita. Deve essere visibile se l’automazione funziona, fallisce o produce effetti collaterali inaspettati. Per questo sono necessari obiettivo di log, monitoraggio e una semplice routine di controllo dopo riavvii, aggiornamenti e failover.

Se per il controllo è necessario SSH o Advanced Shell, l’accesso dovrebbe essere adeguatamente protetto in anticipo. Le basi sono in Connessione a Sophos Firewall tramite SSH e Risoluzione dei problemi CLI di Sophos Firewall: comandi importanti.

Cosa evitare

Alcuni schemi causano nella pratica più problemi che benefici.

  • Riavvii non sorvegliati: Una firewall non dovrebbe essere riavviata regolarmente per mascherare i sintomi. La causa deve essere circoscritta.
  • Cicli permanenti in background: I cicli infiniti possono sovraccaricare CPU, memoria, rete o log.
  • Logica di avvio persistente senza documentazione: Dopo aggiornamenti, ripristino o failover HA, altrimenti è poco chiaro quale stato sia valido.
  • Manipolazione diretta di pacchetti o routing tramite shell: Se sono coinvolti routing, SD-WAN, IPsec, NAT o MSS, dovrebbero essere prima verificate le funzioni supportate della firewall.
  • Segreti in chiaro: Credenziali, token o URL non dovrebbero essere inseriti in modo incontrollato negli script locali.
  • Soluzioni temporanee senza proprietario: Se nessuno è responsabile della revisione e della rimozione, la soluzione temporanea diventa un’eredità.

Per problemi di IPsec, routing o MSS, spesso altri articoli sono un punto di partenza migliore: Risoluzione dei problemi VPN IPsec di Sophos Firewall, Verifica MTU e MSS di Sophos Firewall in caso di problemi VPN, Adattamento della precedenza delle rotte su Sophos Firewall e Routing SD-WAN per pacchetti di risposta e traffico di sistema.

Se esiste già uno script

Gli script locali esistenti non dovrebbero essere rimossi o adottati alla cieca. Prima è necessaria una valutazione.

Verificare:

  • Quale problema doveva risolvere originariamente lo script?
  • Chi lo ha creato e chi è responsabile oggi?
  • Dove si trova e come viene avviato?
  • Funziona dopo il riavvio, il failover HA e l’aggiornamento del firmware?
  • Contiene credenziali, token, URL interni o indirizzi IP fissi?
  • Ci sono log o monitoraggio?
  • Esiste un’alternativa supportata su cui migrare?

Successivamente si decide se lo script deve essere rimosso, sostituito, documentato o trasferito in un’automazione esterna. Prima di ogni modifica, dovrebbe essere creato un backup e pianificata una finestra di manutenzione.

Modello di documentazione per casi speciali

Se un caso speciale locale rimane temporaneamente nonostante i rischi, dovrebbe essere documentato in modo tale che un’altra persona possa comprenderlo dopo un aggiornamento, un failover o un caso di supporto.

  • Scopo: Quale problema concreto viene risolto?
  • Luogo: File, percorso, utente, meccanismo di avvio e nodo HA interessato
  • Innesco: Quando viene eseguito lo script: manualmente, all’avvio, ciclicamente o tramite un servizio?
  • Modifica: Quali comandi, file, servizi, rotte o interfacce vengono influenzati?
  • Rischio: Cosa succede in caso di errore, riavvio, aggiornamento firmware, ripristino o failover?
  • Controllo: Dove si vedono successo, errori ed effetti collaterali?
  • Rollback: Come viene completamente ripristinato lo stato?
  • Proprietario: Chi verifica il caso speciale dopo gli aggiornamenti e quando viene rimosso?

Questa documentazione non appartiene solo a un sistema di note personale. Nel runbook operativo o del cliente, impedisce che un successivo caso di supporto inizi con una ricerca di tracce sulla firewall.

Checklist

  • Lo scopo dello script è documentato concretamente.
  • Sono state verificate alternative supportate come WebAdmin, XML API, Central, Syslog, SNMP, sFlow o Config Studio.
  • Sono disponibili backup, Secure Storage Master Key e percorso di rollback.
  • Il comportamento HA è stato valutato.
  • È pianificato un ambiente di test o una finestra di manutenzione.
  • I segreti non vengono memorizzati localmente in chiaro.
  • Logging e monitoraggio sono definiti.
  • Sono stabiliti una persona responsabile e una data di revisione.
  • Dopo gli aggiornamenti firmware, il caso speciale viene consapevolmente riesaminato.

FAQ

Si possono usare i Cronjob su Sophos Firewall?

Non si dovrebbe basare il modello operativo sulla manutenzione di Cronjob locali o soluzioni temporanee di script di avvio sulla firewall. Per compiti ricorrenti, l’automazione esterna tramite interfacce supportate è generalmente più stabile, comprensibile e meglio gestibile.

Uno script Heartbeat sulla firewall è sensato?

Nella maggior parte dei casi no. Un sistema di monitoraggio dovrebbe controllare la firewall dall’esterno, non dipendere dalla firewall stessa. Altrimenti, un processo locale può nascondere un problema o fallire proprio quando è necessario.

Si dovrebbe riavviare automaticamente una Sophos Firewall regolarmente?

No. I riavvii ricorrenti sono un segno che un problema non è stato risolto correttamente. È meglio un’analisi di servizi, log, memoria, versione del firmware e funzioni interessate.

Cosa è più sicuro per modifiche ricorrenti?

Per modifiche ricorrenti, automazione esterna, XML API, Sophos Central, processi di cambiamento documentati o strumenti di monitoraggio e configurazione specializzati sono più adatti rispetto agli script locali sulla firewall.

Cosa è particolarmente importante nei cluster HA?

In HA deve essere chiaro su quale nodo esiste una modifica locale e cosa succede dopo un failover, un aggiornamento firmware o un ripristino. Se ciò non è chiaramente documentato e testato, non dovrebbe essere utilizzato alcun caso speciale locale in produzione.