La posta elettronica si è consolidata come standard di comunicazione aziendale. Grazie all'elevata efficienza economica delle email e ad alcune peculiarità legate alla citazione di testi e all'aggiunta di allegati, le email sono particolarmente adatte per lo scambio di documenti e per una comunicazione aziendale cordiale. Anche queste stesse caratteristiche hanno contribuito alla sua popolarità tra gli spammer. Di conseguenza, oggi la posta elettronica rappresenta un enorme oceano in tempesta di spam, in cui le email aziendali compaiono solo raramente. Per questo motivo, una delle priorità principali per l'amministratore di qualsiasi server di posta è la protezione contro le campagne di spam. Diamo un'occhiata a cosa si può fare in Zimbra Collaboration Suite Open-Source Edition.
Nonostante la gratuità della soluzione, Zimbra OSE è in grado di fornire all'amministratore di sistema un gran numero di strumenti estremamente efficaci per affrontare il problema della ricezione di email indesiderate. Abbiamo già parlato di utilità come Amavis, SpamAssassin, ClamAV e cbpolicyd, che consentono di filtrare in modo affidabile la posta in entrata, eliminando le campagne di spam e le email infette o di phishing. Tuttavia, il loro principale svantaggio è che operano su messaggi di posta già ricevuti e consumano risorse di sistema per filtrare messaggi inutili, che potrebbero essere utilizzate in modo molto più produttivo. Ma cosa fare se la tua azienda è sotto il tiro di un grande botnet, che inonda il tuo server di posta con tali quantità di email di spazzatura che la sola filtrazione consuma una parte significativa delle capacità del server MTA?
In teoria, ci si può proteggere da ciò attraverso la connessione a un servizio cloud per la filtrazione della posta in arrivo, tuttavia, nella pratica, questo metodo di protezione non è adatto a tutte le aziende, poiché in tal caso si dovrebbe affidare a terze parti l'elaborazione non solo dello spam, ma anche della corrispondenza commerciale, il che non è sempre sicuro e spesso contraddice la politica di sicurezza dell'azienda. Inoltre, sorgono rischi legati all'affidabilità del funzionamento del filtro spam cloud. Una soluzione a questa situazione potrebbe essere l'organizzazione della protezione del server con le proprie forze. A questo scopo, Zimbra ha integrato l'utilità Postscreen, progettata per proteggere il server di posta dalle email inviate da botnet, senza sovraccaricare il server di posta.
Il principio di funzionamento di Postscreen è che questa utilità esamina tutte le richieste di connessione al server di posta server e non consente la connessione al server ai client che le appaiono sospetti. Poiché, secondo le statistiche, circa il 90% dello spam nel mondo viene inviato proprio da botnet, Postscreen viene spesso utilizzato come primo livello di protezione del server di posta dalle campagne pubblicitarie indesiderate. Grazie a questo, il server di posta può funzionare in modo stabile senza sovraccarichi anche in condizioni di attacchi spam intensivi da parte di grandi botnet.
Il principio di funzionamento di Postscreen è piuttosto semplice: l'utilità è in grado di effettuare una serie di controlli di base sulle email in arrivo prima di trasmetterle al server di posta o ad altri servizi che effettuano un controllo più approfondito e dettagliato delle email in arrivo. Ogni controllo, di conseguenza, può essere superato o non superato. Sulla base dei risultati di ciascun controllo, Postscreen può applicare una delle tre azioni a scelta dell'amministratore di Zimbra: Drop, Ignore o Enforce. L'azione Drop interrompe forzatamente la connessione con il cliente nel caso in cui il controllo non venga superato, l'azione Ignore permette di ignorare i risultati del controllo nella decisione finale, ma consente di raccogliere informazioni e statistiche sui controlli effettuati, e l'azione Enforce permette di considerare i risultati dei controlli effettuati nella decisione finale, continuando comunque a eseguire tutti i test programmati dall'amministratore di sistema.
Un principio di funzionamento semplice non significa affatto facilità d'uso e configurazione. Infatti, un Postscreen configurato in modo errato può diventare la causa della mancata ricezione di molte email importanti per l'azienda. Proprio per questo motivo, è necessario affrontare la configurazione di uno strumento potente come Postscreen con grande cautela e testarlo continuamente per verificarne il comportamento in diverse situazioni.
Postscreen in Zimbra è abilitato di default, ma molti potrebbero non essere soddisfatti della configurazione iniziale. Ora esamineremo la configurazione ottimale dal punto di vista della sicurezza e dell'assenza di rischi per Postscreen. La sostanza è che, dopo il fallimento di uno dei controlli, Postscreen non interromperà bruscamente la connessione con il client, ma effettuerà tutti i controlli fino alla fine e, nel caso questi controlli risultino falliti, restituirà un messaggio di errore. Questo permetterà di notificare il mittente reale della mancata consegna dell'email nel caso in cui Postscreen lo consideri spam. Questo si ottiene impostando il valore enforce nei parametri di esecuzione dei controlli. Questo valore consente di completare i controlli avviati fino alla fine, senza interrompere la connessione con il client al primo fallimento, ma alla fine del processo di verifica, bloccare comunque l'email di spam, evitando di consegnarla al server.
Per abilitare i controlli necessari, è necessario immettere i seguenti comandi:
zmprov mcf zimbraMtaPostscreenDnsblSites ‘b.barracudacentral.org=127.0.0.2*7’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[10;11]*8’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[4..7]*6’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.3*4’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.2*3’
Questo comando consente di aggiungere un controllo DNS per le connessioni in ingresso basato su due delle più popolari liste pubbliche di spam, classificando le email in base a quale lista contiene l'indirizzo del mittente. Maggiore è il numero di "stelle" di penalizzazione accumulato dal cliente, maggiore sarà la probabilità che sia uno spammer.
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
Questo comando definisce l'azione intrapresa al termine del controllo DNS. In questo caso, il risultato del controllo viene memorizzato, mentre l'email stessa continua a subire ulteriori test.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Poiché nel protocollo SMTP, dopo la connessione diretta, il server inizia per primo la comunicazione con il client e, di conseguenza, Postscreen può inviare un saluto al client. Poiché molti client di spam iniziano a inviare comandi senza aspettare la fine del saluto, è facile riconoscerli. Questo comando consente di tenere conto dei risultati di questo controllo, ma nel contempo continuerà a eseguire ulteriori test.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
Nell'ambito di questo controllo, Postscreen consente di filtrare le connessioni che non provengono da client di posta. Poiché non inviano alcuna email, possono essere disconnessi dal server senza alcun problema.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
Questo controllo si basa sul fatto che, per impostazione predefinita, nel protocollo SMTP un client può inviare solo un comando alla volta e poi attendere la risposta del server a quel comando. Tuttavia, molti bot di spam si comportano diversamente, inviando più comandi senza aspettare la risposta dal server. Questo permette di identificare praticamente senza errori i bot di spam.
In linea di principio, questi controlli per Postscreen saranno più che sufficienti per filtrare dalla server la maggior parte dei bot di spam e ottenere una significativa riduzione del carico sul proprio server di posta. Allo stesso tempo, le persone reali riceveranno un messaggio che informa che la loro email non è stata recapitata, il che riduce notevolmente il rischio di perdere email importanti a causa delle impostazioni di Postscreen. Nel caso in cui ciò accada, puoi aggiungere mittenti fidati alla lista bianca di Postscreen. Per creare liste bianche e nere in Postscreen, è prima necessario creare un file. /opt/zimbra/conf/postfix/postscreen_wblist.
In questo file aggiungeremo l'elenco degli indirizzi IP e delle sottoreti autorizzati e vietati nel formato della tabella CIDR. Ad esempio, bloccheremo la sottorete 121.144.169.*, ma consentiremo la connessione al indirizzo IP da questa sottorete:
# Rules are evaluated in the order as specified.
# Blacklist 121.144.169.* except 121.144.169.196.
121.144.169.196/32 permit
121.144.169.0/24 reject
Si prega di notare l'importanza dell'ordine delle registrazioni. Infatti, Postscreen scansirà il file delle liste bianche e nere fino al primo match e se la sottorete bloccata appare prima dell'indirizzo IP consentito, il controllo non raggiungerà semplicemente la registrazione che indica che questo indirizzo IP è stato aggiunto alla lista bianca e la connessione al server non avverrà.
Dopo che il file con le liste bianche e nere è stato modificato e salvato, è possibile attivare il controllo corrispondente utilizzando i seguenti comandi:
zmprov mcf zimbraMtaPostscreenAccessList «permit_mynetworks, cidr: /opt/zimbra/conf/postfix/postscreen_wblist»
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce
Ora Postscreen, oltre ai controlli già impostati, si riferirà anche al file con le liste bianche e nere, consentendo all'amministratore di affrontare facilmente le questioni riguardanti l'impossibilità di collegarsi al server da parte dei mittenti affidabili.
Fonte: habr.com
