Configurare Sophos Firewall Mail Protection in modalità MTA

Sophos Firewall può accettare direttamente il traffico SMTP in modalità MTA, controllarlo e inoltrarlo al server di posta interno o al mailhop successivo. Il firewall non è quindi solo una pubblicazione della porta TCP 25, ma un Mail Transfer Agent attivo con routing, controllo spam e malware, quarantena, spool e mail log.

Oggi consigliamo Mail Protection sul firewall soprattutto per scenari on-premises o ibridi pianificati consapevolmente, per esempio quando un Exchange locale o un altro server di posta interno deve essere protetto direttamente tramite il firewall. Per Microsoft 365, Google Workspace e molti ambienti di posta cloud moderni, Sophos Central Email o un altro cloud mail gateway è spesso l’architettura più pulita, perché MX, quarantena, header, TLS, SPF/DKIM/DMARC e supporto restano più vicini al servizio di posta effettivo.

Se Mail Protection viene usata in modalità MTA, l’articolo deve fare più di spiegare una funzione: MX record, regola MTA automatica, SMTP route and scan Policy, autorizzazioni relay, TLS, verifica destinatari, spool, quarantena e log devono combaciare. Altrimenti il firewall può respingere email legittime, ritardare la posta o risultare raggiungibile involontariamente come relay.

Quando Mail Protection sul firewall ha senso

Mail Protection su Sophos Firewall ha senso soprattutto quando il traffico SMTP deve passare intenzionalmente dal firewall e il firewall deve fare più che inoltrare semplicemente la porta 25.

Scenari tipici:

• Le email in ingresso devono essere prima accettate e controllate sul firewall.
• Un server di posta interno non deve essere raggiungibile direttamente da Internet.
• Il controllo di spam, malware, tipi di file o contenuti deve avvenire prima della consegna.
• Le email in uscita devono essere inviate in modo controllato tramite il firewall o uno smarthost.
• Quarantena, mail spool e log SMTP devono essere tracciabili sul firewall.

Non ogni configurazione mail dovrebbe passare dal firewall. Se Sophos Central Email, Microsoft Defender for Office 365 o un altro cloud mail gateway gestisce già l’intero mailflow, Mail Protection sul firewall non dovrebbe essere inserita in aggiunta senza documentare precisamente il flusso mail. Gateway doppi portano rapidamente a responsabilità poco chiare per quarantena, header, SPF/DKIM/DMARC, TLS e troubleshooting.

Distinguere modalità MTA, Legacy mode e SMTP Relay

Con Sophos Firewall bisogna separare chiaramente tre aspetti:

• MTA mode: Il firewall accetta email, le controlla e le consegna. Mailflow SMTP in ingresso o in uscita con policy.
• Legacy mode: vecchia elaborazione mail basata su proxy. Ambienti esistenti che vengono migrati o mantenuti volutamente.
• SMTP Relay come servizio locale: sistemi interni inviano tramite il firewall. Stampanti, scanner, applicazioni o sistemi di monitoring.

Il MTA mode è la modalità di destinazione normale per scenari moderni di Mail Protection sul firewall. Il servizio locale SMTP Relay, invece, è un tema di Device Access. Dovrebbe essere raggiungibile solo da reti interne definite. Un’apertura troppo ampia può favorire l’abuso del relay. L’hardening dei servizi locali è descritto in Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Requisiti

Prima della configurazione, questi punti devono essere chiariti:

• Sophos Firewall con Email Protection valida o bundle adeguato.
• Non tutti i modelli supportano il MTA mode. XGS 87/87w e XGS 88/88w sono appliance senza supporto MTA mode.
• Zona DNS pubblica e record MX sono noti.
• Server di posta interno, porta di destinazione e percorso di consegna sono documentati.
• Indirizzo IP pubblico o indirizzo WAN per il traffico SMTP in ingresso è definito.
• Il firewall può instradare e raggiungere il server di posta interno.
• L’accesso DNS in uscita del firewall funziona.
• La strategia TLS e certificati desiderata è chiarita.
• Il processo di quarantena e rilascio è definito a livello organizzativo.

Prima di modificare il mailflow dovrebbe essere pianificata una finestra di manutenzione. Un test su record MX produttivi senza piano di fallback è rischioso, perché le email in ingresso possono essere rapidamente ritardate o rifiutate a seconda del mittente.

Definire l’architettura target

Per prima cosa va deciso quale direzione deve elaborare il firewall.

Mailflow in ingresso

Nel mailflow in ingresso, i record MX esterni puntano all’indirizzo pubblico su cui Sophos Firewall accetta SMTP. Il firewall controlla il messaggio e lo inoltra al server di posta interno.

Flusso tipico:

1. Il mittente esterno si connette via SMTP all’indirizzo MX pubblico.
2. Sophos Firewall accetta la connessione in MTA mode.
3. Mail Protection controlla mittente, destinatario, spam, malware, allegati e policy.
4. Il firewall consegna l’email al server di posta interno.
5. Il server di posta interno consegna nella mailbox o elabora ulteriormente il messaggio.

È importante che il server di posta interno non resti raggiungibile anche in modo non filtrato da Internet. Se in parallelo una regola DNAT punta ancora direttamente al server di posta, una parte del traffico può aggirare Mail Protection. Per pubblicazioni server normali, Pubblicare un server tramite DNAT è la base adatta, ma in MTA mode il firewall stesso è il punto di accettazione SMTP.

Mailflow in uscita

Nel mailflow in uscita, il server di posta interno invia tramite Sophos Firewall. Il firewall può controllare i messaggi, inoltrarli a uno smarthost o consegnarli direttamente, a seconda della configurazione.

Chiarire prima:

• L’IP pubblico del firewall può inviare email direttamente?
• SPF, DKIM e DMARC sono corretti per il percorso di invio scelto?
• Serve uno smarthost del provider?
• Il traffico SMTP in uscita deve essere limitato a sistemi interni specifici?
• Dove vengono monitorati i messaggi rifiutati o ritardati?

Per il traffico mail in uscita dovrebbe essere usata una struttura di regole e policy propria e tracciabile. Una regola generale LAN to WAN senza restrizioni chiare è di solito troppo ampia per server di posta. Le basi su ordine delle regole e profili di sicurezza sono in Capire e costruire correttamente le regole Sophos Firewall.

Preparare cambio MX e test esterni

Una modifica di Mail Protection diventa critica solo quando i mittenti esterni usano davvero il nuovo percorso. Per questo record MX, DNS TTL, raggiungibilità esterna e rollback devono essere verificati prima del cambio produttivo.

Prima del cambio:

• Documentare record MX attuale, priorità e TTL.
• Ridurre per tempo il DNS TTL se potrebbe servire un fallback rapido.
• Distinguere chiaramente vecchio percorso mail e nuovo indirizzo Sophos Firewall.
• Identificare vecchie regole DNAT dirette al server di posta.
• Definire destinatari e mittenti di test.
• Definire il piano di fallback: vecchio MX, vecchia regola DNAT o smarthost temporaneo.
• Preparare monitoring per spool, quarantena e queue del server di posta.

Controlli esterni utili da un sistema fuori dalla propria rete:

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

I comandi non sostituiscono un test completo del mailflow, ma mostrano rapidamente se DNS, porta 25 e STARTTLS sono fondamentalmente raggiungibili. example.com e mail.example.com devono essere sostituiti con il dominio reale e l’host mail reale.

Dopo il cambio, inviare subito una mail di test in ingresso e documentare l’intero percorso:

• Connessione visibile in Log Viewer?
• Voce presente in smtpd_main.log?
• Verifica destinatario riuscita?
• Consegna al server di posta interno avvenuta?
• Messaggio arrivato nella mailbox?
• Nessuna consegna diretta parallela che aggira il MTA?

Se il firewall accetta email ma non le consegna, non bisogna riportare subito indietro l’MX. Prima va chiarito se si tratta di un problema interno di routing, DNS, TLS o server di posta. Se però i mittenti esterni non riescono a connettersi al firewall o email legittime vengono rifiutate in modo ampio, un fallback rapido al percorso mail precedente è spesso più sensato di esperimenti prolungati nel percorso MX produttivo.

Attivare MTA mode

Le impostazioni di base si trovano in Sophos Firewall sotto:

Email > General settings

Per questa guida deve essere attivo MTA mode. Se il firewall è ancora in Legacy Mode, si passa con Switch to MTA mode.

Dopo l’attivazione, Sophos Firewall crea automaticamente una regola firewall per SMTP/SMTPS con il nome Auto added firewall policy for MTA. Questa regola deve restare visibile e in alto nella base regole. Una regola MTA non deve essere trattata come una normale regola LAN-to-WAN o spostata incidentalmente verso il basso, perché altrimenti il traffico SMTP in ingresso non entra più nel percorso MTA previsto.

Poi si controllano le impostazioni di base:

1. In SMTP settings impostare SMTP hostname. È l’hostname che il firewall usa in contesti HELO e banner per messaggi generati dal sistema. Non inserire alla cieca il nome interno del mailserver se il nome mail pubblico è diverso.
2. Attivare Reject based on IP reputation se le connessioni SMTP in ingresso devono essere respinte in base a cattiva reputazione del mittente.
3. In SMTP TLS configuration scegliere un certificato pubblico attendibile adatto, se SMTP TLS deve essere presentato correttamente tramite firewall.
4. Attivare Disable legacy TLS protocols, salvo sistemi legacy consapevolmente documentati.
5. Attivare Scan outgoing mails se anche i messaggi in uscita dal mailserver devono essere controllati tramite firewall.

In ambienti esistenti non cambiare semplicemente tra Legacy mode e MTA mode senza testare il mailflow. Elaborazione, log e logica delle policy sono diversi. Prima di una migrazione vanno documentati configurazione firewall attuale, record MX, connettori del server di posta e impostazioni relay.

Configurare routing SMTP e domini

Per le email in ingresso, il firewall deve sapere quali domini accettare e dove consegnarli.

Creare Address Group per i domini mail

Per prima cosa si crea una Address Group per i domini mail protetti:

1. Aprire Email > Address group.
2. Fare clic su Add.
3. Verificare Group type su Email address/domain.
4. Lasciare Type su Manual se i domini vengono mantenuti manualmente.
5. In Email address/domain inserire il dominio, ad esempio example.com, e aggiungerlo.
6. Fare clic su Save.

Qui si lavora con domini, non con singoli indirizzi destinatario. Singoli indirizzi email esistenti o migrati possono continuare ad avere effetto a seconda della configurazione, ma nelle SMTP-route-and-scan-Policies attuali non dovrebbero essere pianificati come nuove voci. Per uno stato target pulito si dovrebbe quindi lavorare con domini e verifiche destinatario adatte.

Creare SMTP route and scan Policy

La vera MTA-Policy viene creata sotto questo percorso:

Email > Policies and exceptions > Add a policy > SMTP route and scan

Procedura tipica per mail in ingresso verso un server di posta interno:

1. Impostare un Name parlante, ad esempio Inbound example.com to Exchange.
2. In Protected domain selezionare la Address Group creata in precedenza.
3. Definire Route by:
   • Static host: per indirizzi IP fissi del server di posta interno.
   • DNS host: per un nome DNS come mailserver.example.com.
   • MX: se il firewall deve consegnare in base ai record MX.
4. Con Static host, selezionare il mailserver interno in Host list. Gli IP Hosts vengono creati se necessario in Hosts and services > IP host.
5. Impostare Global action su Accept se il dominio deve essere accettato e controllato in base alla policy.
6. Attivare Spam protection e decidere consapevolmente se lo spam deve essere avvisato, messo in quarantena, droppato o consegnato senza azione.
7. Attivare Malware protection. Per Zero-Day Protection con Single-Antivirus-Scan, Sophos deve essere usato come motore primario.
8. Attivare File protection e Data protection solo se gli effetti su allegati, messaggi grandi, SPX e DKIM sono compresi.
9. Fare clic su Save.

Con più server mail interni, il tipo di routing è importante. Con Static host si passa all’host successivo se il primo non è raggiungibile. Con DNS host e più A-Record, la consegna può essere distribuita. È pratico, ma deve combaciare con design del mailserver, certificati TLS e analisi errori.

Per server di posta interni, DNS è particolarmente importante. Il firewall deve poter risolvere correttamente le destinazioni interne, e i mittenti esterni devono raggiungere il record MX pubblico. Se la risoluzione DNS interna ha un ruolo, aiuta Configurare DNS Request Routes su Sophos Firewall.

Pianificare policy per spam, malware e allegati

Mail Protection è valida solo quanto le policy che si applicano davvero. Una policy non va solo creata, ma nominata con uno scopo chiaro.

Domande importanti sulle policy:

• Quali domini o gruppi di destinatari sono interessati?
• Viene elaborato traffico mail in ingresso, in uscita o in entrambe le direzioni?
• Cosa succede con spam, malware, allegati sospetti o tipi di file indesiderati?
• Le email vengono bloccate, messe in quarantena, consegnate o marcate con header?
• Deve essere usata Recipient verification via Callout o Active Directory?
• Chi può controllare la quarantena e rilasciare email?
• Quali processi per false positive esistono?

Con Spam Protection, SPF, RBL, Greylisting, BATV e Recipient verification non dovrebbero essere trattati come semplici checkbox. I match RBL o SPF non vengono elaborati come normali azioni spam, ma possono respingere direttamente i messaggi. Recipient verification riduce backscatter e destinatari non validi, ma può diventare essa stessa causa di errore in caso di problemi AD, TLS o mailserver.

Per i messaggi in uscita, DKIM è particolarmente sensibile. Cifratura SPX, prefissi nel subject, tipi di file bloccati, Data Protection o un banner in uscita possono modificare header o body. Questo può rompere un hash DKIM presso l’MTA destinatario. Se le firme in uscita sono importanti, bisogna decidere se la firma avviene sul mailserver, su Sophos Firewall o su un gateway successivo.

Se viene usata Zero-Day Protection, gli allegati email sospetti possono essere analizzati in aggiunta. Limiti, report e decisione di rilascio sono spiegati in Capire e gestire Sophos Firewall Zero-Day Protection.

Mettere in sicurezza relay e Device Access

Un errore frequente è confondere mailflow MTA e SMTP Relay aperto. Il firewall non deve poter essere usato come relay da reti qualsiasi.

Per le email in ingresso, SMTP sul lato WAN deve poter essere accettato in linea di principio, affinché i mailserver esterni possano consegnare il dominio. Per le email in uscita, invece, deve essere chiaro quali host interni possono relayare tramite firewall.

Verificare:

• Sotto Administration > Device access, SMTP Relay è attivo solo nelle zone davvero necessarie.
• Se vengono usate ACL Exception Rules, le sorgenti sono definite in modo stretto.
• In Email > Relay settings, sotto Host-based relay, solo mailserver, scanner o application server definiti sono inseriti come fonti consentite.
• Zone non necessarie, reti guest e reti untrusted non possono relayare in modo generico.
• Se servizi cloud come Exchange Online Protection devono consegnare o relayare tramite firewall, le aree sorgente consentite devono essere mantenute con molta precisione. Autorizzazioni ampie Any sono un rischio Open Relay.
• Il logging è attivo, così abusi o configurazioni errate sono visibili.

Se stampanti, scanner o applicazioni devono inviare email, va documentato un percorso relay interno dedicato. Tali sistemi non dovrebbero comunicare direttamente con destinazioni SMTP esterne arbitrarie se l’ambiente può evitarlo.

Testare il mailflow

Dopo la configurazione, un singolo invio riuscito non basta. Vanno eseguiti più test e documentati i risultati.

Test in ingresso

Verificare almeno:

• Il record MX esterno punta all’indirizzo atteso.
• La porta 25 è raggiungibile dall’esterno.
• Il firewall accetta la connessione in MTA mode.
• L’email viene inoltrata al server di posta interno.
• Il destinatario esiste e riceve il messaggio.
• Il test spam o malware viene trattato come previsto.
• La voce di quarantena o log è tracciabile.

Test in uscita

Verificare almeno:

• Il server di posta interno invia tramite la route attesa.
• La regola firewall e la mail policy si applicano.
• SPF, DKIM e DMARC corrispondono al percorso di invio.
• Il server di destinazione accetta il messaggio.
• Bounces o messaggi Deferred vengono monitorati.
• Nessun altro sistema interno invia direttamente verso l’esterno in modo non pianificato.

Controllare i log

Per un controllo visivo rapido aiuta Log Viewer. Per un’analisi più profonda sono importanti i file di log mail. La corrispondenza è in Troubleshooting Sophos Firewall: servizi e log.

File di log rilevanti:

• SMTP MTA: smtpd_main.log.
• Errori SMTP: smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Anti-Spam: sasi.log.
• Legacy SMTP/MTA: awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
• POP/IMAP Proxy: warren.log.

In caso di troubleshooting urgente, annotare l’orario del test, raccogliere mittente, destinatario, oggetto, IP sorgente e Message-ID, quindi correlare temporalmente Log Viewer e file di log.

Quarantena, spool e storage

Mail Protection genera dati locali. A seconda del volume, i messaggi finiscono in quarantena, spool o aree temporanee. Per questo spazio di storage, stato SSD e piano di recovery diventano più rilevanti che con una semplice regola firewall.

Domande operative pratiche:

• Chi controlla la quarantena e con quale frequenza?
• Come vengono rilasciati i false positive?
• Quando un messaggio viene eliminato invece che rilasciato?
• Come viene rilevato un mail spool in crescita?
• Esiste monitoring per spazio di storage e System Health?
• Dopo firmware update è previsto un breve test del mailflow?

Per temi di storage e reporting sono adatti Pulire storage e report di Sophos Firewall e Controllare Sophos Firewall SSD Health. In ambienti HA va inoltre considerato che quarantena mail e dati mail elaborati possono essere dati operativi legati al nodo. Le basi HA sono in Varianti di cluster HA Sophos Firewall.

Controllare la quarantena direttamente nel WebAdmin

Se un firewall viene gestito tramite Sophos Central, l accesso da Central e comodo. Per Mail Protection, pero, bisogna sapere anche dove si trova la quarantena localmente e come controllarla direttamente sul firewall.

Email > SMTP quarantine

Qui i messaggi in quarantena possono essere filtrati per periodo, mittente, destinatario, oggetto e motivo della quarantena. Per l operativita sono importanti soprattutto tre azioni:

• Delete: Elimina il messaggio dalla quarantena.
• Release: Rilascia il messaggio al destinatario.
• Release and report: Rilascia il messaggio e lo segnala come classificato in modo errato.

Con SFOS 22.0 MR1 esiste un caso particolare importante: se il firewall viene gestito tramite Sophos Central, azioni di quarantena come Release o Delete possono fallire con Invalid API request. Questo non significa automaticamente che il mailflow, la quarantena o la policy MTA siano difettosi. Il workaround pratico e accedere direttamente al WebAdmin locale del firewall e rilasciare o eliminare il messaggio in Email > SMTP quarantine.

Dopo un aggiornamento a SFOS 22.0 MR2 o successivo, il flusso va testato di nuovo: mettere in quarantena un messaggio di test innocuo, eseguire l azione tramite il percorso amministrativo previsto e poi controllare Log Viewer, quarantena e mailbox del destinatario.

Importante: i messaggi infetti da virus e i messaggi classificati come malevoli da Zero-Day Protection non possono essere semplicemente rilasciati. Per le voci Zero-Day Protection servono inoltre autorizzazioni adeguate se devono essere eliminate. Se la quarantena si riempie, le email più vecchie vengono ripulite. È un altro motivo per controllare quarantena e storage prima che arrivino reclami.

Troubleshooting

Le email esterne non arrivano

Controllare prima DNS e raggiungibilità: record MX, IP pubblico, porta 25, vecchie configurazioni NAT, MTA mode e dominio mail responsabile. Poi verificare in Log Viewer e in smtpd_main.log se la connessione raggiunge il firewall. Se non è visibile alcuna connessione, il problema è probabilmente prima di Mail Protection.

Il firewall accetta email, ma non le consegna

Allora sono più probabili server di posta interno, routing, DNS, porta di destinazione, TLS, verifica destinatario o policy. Verificare se il firewall può raggiungere il server di posta e se il server accetta la connessione. Reject log e log del server di posta devono essere valutati insieme nel tempo.

Molte email restano nello spool

Uno spool in crescita indica spesso problemi di consegna: server di posta interno non raggiungibile, requisito TLS non adatto, risoluzione DNS fallita o server di destinazione che rifiuta il messaggio. In questo caso non limitarsi a riconsegnare singoli messaggi, ma cercare la causa nel percorso di routing e SMTP.

Un caso importante di ordine delle regole viene facilmente trascurato: se una regola firewall creata automaticamente o manualmente si trova sopra la regola MTA e matcha traffico SMTP, la vera regola MTA non viene più valutata. Le email possono quindi rimanere nel mail spool anche se DNS, porta 25 e server di posta sembrano fondamentalmente corretti.

Verificare:

1. Aprire Rules and policies > Firewall rules.
2. Controllare le regole sopra la regola MTA o SMTP.
3. Controllare nuove regole generate automaticamente, regole IPsec, regole hotspot o regole impostate manualmente su Top.
4. Eseguire di nuovo il test SMTP e confrontare Log Viewer, mail spool e smtpd_main.log.

La regola non deve essere spostata alla cieca verso il basso se svolge altri scopi produttivi. Il punto decisivo è se intercetta in modo inatteso traffico SMTP prima della regola MTA.

Digest di quarantena assente per indirizzi alias

Se gli utenti usano indirizzi alias, non bisogna controllare le impostazioni di quarantena solo per l’indirizzo mail primario. Secondo Sophos, le impostazioni di quarantena non vengono applicate automaticamente agli indirizzi alias per impostazione predefinita. Se mancano digest mail o rilasci per destinatari alias, gli indirizzi alias devono essere considerati insieme all’indirizzo primario nel contesto di quarantena o utente.

Un mittente legittimo viene riconosciuto come spam

I false positive non dovrebbero essere risolti subito con eccezioni ampie. Prima controllare dominio mittente, SPF/DKIM/DMARC, header, reputazione, policy match e destinatari interessati. Se serve un’eccezione, deve essere strettamente limitata e documentata con una data di revisione.

I sistemi interni non possono relayare

Verificare se SMTP Relay sotto Administration > Device access è consentito dalla zona corretta e se la sorgente corrisponde all’ACL. Poi controllare i log mail. Se uno scanner o un’applicazione deve relayare, la sorgente dovrebbe essere documentata come oggetto host e non va abilitata inutilmente un’intera rete.

Dopo firmware update la posta funziona diversamente

Dopo firmware update vanno controllati MTA mode, policy, certificati, mail spool, quarantena e log rilevanti. Per update più grandi è adatto anche Controllare Sophos Firewall prima dell’upgrade a SFOS 22.

L azione di quarantena segnala Invalid API request

Se Release o Delete fallisce con Invalid API request su un firewall aperto tramite Sophos Central, controllare prima la versione SFOS. Con SFOS 22.0 MR1 questo flusso puo essere interessato.

Il passo successivo non e ricostruire la mail policy. Prima passare al WebAdmin locale del firewall e gestire il messaggio in Email > SMTP quarantine. Poi documentare:

1. Versione e build SFOS.
2. Se l azione e stata tentata tramite Sophos Central o direttamente nel WebAdmin.
3. Mittente, destinatario, oggetto e motivo della quarantena.
4. Risultato dopo il test diretto nel WebAdmin.
5. Se un aggiornamento a SFOS 22.0 MR2 o successivo e pianificato o installato.

Checklist operativa

• Licenza Mail Protection e supporto appliance verificati.
• MTA mode scelto consapevolmente e documentato.
• Address Group per i domini protetti mantenuta correttamente.
• Record MX, IP pubblico e server interno di destinazione corretti.
• Cambio MX, test esterni e rollback preparati.
• Nessuna regola DNAT parallela non filtrata aggira il MTA.
• Policy in ingresso e in uscita nominate in modo comprensibile.
• L’ordine delle regole firewall non impedisce alla regola MTA di applicarsi.
• SMTP Relay consentito solo da sorgenti interne definite.
• TLS, DKIM, banner, SPX e Data Protection verificati per effetti collaterali.
• Processo di quarantena e false positive definito.
• Indirizzi alias considerati nel processo di quarantena e digest.
• Mail spool, spazio di storage e System Health monitorati.
• Log conservati localmente, in Sophos Central o via Syslog abbastanza a lungo.
• Dopo firmware update viene eseguito un test del mailflow.

Per conservazione più lunga e correlazione con altri eventi di sicurezza, verificare Central Firewall Reporting o Inviare Sophos Firewall Syslog a SIEM.

FAQ