Obiettivo: dotare il mio server di posta di un antivirus efficiente e poco invasivo
Per l’ennesima volta il mio server di posta è stato inserito in una blacklist; questa volta è una blacklist assolutamente poco importante, e non ha creato in nessun modo danni ai miei clienti, ma la motivazione dell’inserimento nella BL era interessante e mi ha imposto di intervenire.
Risultava infatti che qualche mio cliente inviava posta infetta da virus!
In effetti il mio server non controllava se il contenuto della posta contiene virus, poiché ho sempre pensato che i client dovessero avere questo compito, ma questa situazione mi ha fatto cambiare idea.
Ho cercato delle soluzioni a questo problema, ma ho voluto impormi dei vincoli piuttosto stringenti.
Per prima cosa non voglio usare AMAVIS. Il motivo è semplice; AMAVIS utilizza l’opzione di postfix ‘content_filter’ che crea una nuova mail, la quale viene messa in coda ed esaminata. Ad ogni esame viene generata una nuova mail e a sua volta messa in coda. Per ogni mail vengono generate 2 o 3 mail ‘figlie’, messe in coda ed esaminate.
Questo sistema a me non piace; ad un mio cliente questo sistema genera una serie infinita di email (vedi esempio sotto, inviata dal loro server al mio), a cui ho posto limitato rimedio con un intervento mirato: questa è una situazione che desidero non sia presente sul mio sistema di posta.
Return-Path: <X.XXX@YYYY.it> Delivered-To: a.montanari@esseciesse.net X-Greylist: delayed 493 seconds by postgrey-1.34 at mailserver.esseciesse.net; Mon, 27 Mar 2017 10:53:13 CEST Received: from relaycdp.ZZZZZZZZZZ.it (mailserver.ZZZZZZZZZZ.it [XXX.YYY.ZZZ.KKK]) by mailserver.esseciesse.net (Postfix) with ESMTP id 5F744620A2 for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:53:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by relaycdp.ZZZZZZZZZZ.it (Postfix) with ESMTP id 024291A4D25 for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:32:06 +0200 (CEST) Received: from relaycdp.ZZZZZZZZZZ.it ([127.0.0.1]) by localhost (relaycdp.ZZZZZZZZZZ.it [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4Gh7PO5chiYh for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:32:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by relaycdp.ZZZZZZZZZZ.it (Postfix) with ESMTP id 9C1591A4D31 for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:32:05 +0200 (CEST) Received: from relaycdp.ZZZZZZZZZZ.it ([127.0.0.1]) by localhost (relaycdp.ZZZZZZZZZZ.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 82tpCFbht5Ip for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:32:05 +0200 (CEST) Received: from postacdp.ZZZZZZZZZZ.it (postacdp.ZZZZZZZZZZ.it [192.168.158.206]) by relaycdp.ZZZZZZZZZZ.it (Postfix) with ESMTP id 136B91A4D25 for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:32:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by postacdp.ZZZZZZZZZZ.it (Postfix) with ESMTP id C9CC12129B for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:42:53 +0200 (CEST) Received: from postacdp.ZZZZZZZZZZ.it ([127.0.0.1]) by localhost (postacdp.ZZZZZZZZZZ.it [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PuIFAQSYhUZd for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:42:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by postacdp.ZZZZZZZZZZ.it (Postfix) with ESMTP id 74553214C9 for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:42:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at postacdp.ZZZZZZZZZZ.it Received: from postacdp.ZZZZZZZZZZ.it ([127.0.0.1]) by localhost (postacdp.ZZZZZZZZZZ.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3Tu5N0CVFwnp for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:42:53 +0200 (CEST) Received: from [192.168.158.213] (vmwinxp.HHHHHHHH.lan [192.168.158.213]) by postacdp.ZZZZZZZZZZ.it (Postfix) with ESMTP id 3DB952129B for <a.montanari@esseciesse.net>; Mon, 27 Mar 2017 10:42:53 +0200 (CEST) To: a.montanari@esseciesse.net From: Roberto KKKKKKK <X.YYYYY@ZZZZZZZZZZ.it>
Altro vincolo: se invio una mail con un virus, questo non mi deve generare una mail di ritorno con un errore, ma voglio che la mia mail NON parta, e il client in tempo reale mi avvisi che sto mandando un virus (idea avuta dal comportamento di Gmail). Questo sistema implica che la mail venga controllata durante l’invio, con aggravio di CPU sul server, e che non venga controllata in coda. Lo svantaggio è che viene controllata in tempo reale durante il momento dell’invio, con aggravio di tempo e CPU; il vantaggio è che in tempo reale ho l’errore, e la mail non parte.
Ulteriore vincolo: le mail in arrivo dall’esterno infette non devono essere messe da nessuna parte, perche’ se siamo in presenza di un falso positivo c’e’ il rischio che vengano perse; se risultano infette devono essere marchiate ed evidenziate come infette, ma devono passare ed arrivare sul PC dell’utente, che deciderà cosa farne, in modo da non perdere niente.
Ultimo vincolo: i sistemi di antivirus devono essere due, Sophos Antivirus per Linux, e ClamAv, con l’estensione clamav-unofficial-sigs.
Sono riuscito ad ottenere BENE tutto quello che mi ero proposto, anche se il progetto è durato circa 2 mesi, e mi ha costretto a scrivere codice in Perl, studiare molto, e a provare una serie infinita di software e librerie per ottenere il risultato desiderato.
In questo documento presento il lavoro, ma non pubblico tutto il codice scritto, soprattutto perché attualmente è funzionante, ma è sporco, pieno di test commentati, e non ho il tempo di renderlo presentabile per un utilizzo di pubblico dominio.
Schema iniziale prima dell’introduzione degli antivirus
Questo è lo schema iniziale, presente allo startup del progetto.
E’ uno schema classico di gestione della mail, con due canali:
- Il primo in SMTPS, per l’invio della posta, con certificato SSL, autenticazione e OPENDIKIM per la firma.
- Il secondo per la mail dall’esterno, sulla porta 25, con un paio di controlli di antispam (postgrey e Spamassassin che controlla solo i DNSBL), in modo che comunque tutta la mail buona arrivi al client, anche se presente in una lista DNSBL. Da notare che postfix chiama direttamente Spamassassin (senza passare per Amavis), il quale che invoca il delivery-lda di dovecot, per cui la mail viene modificata da Spamassassin e inserita direttamente in casella.
Questo schema mi permetteva di avere per ogni mail una e una sola mail in coda.
Schema finale dopo l’introduzione dei sistemi antivirus
La situazione alla fine dell’introduzione dei sistemi antivirus risulta più complessa.
Innanzi tutto il flusso di ingresso (porta 25 smtp) segue logiche diverse dal flusso di uscita (porta 465 smtps).
Per il flusso di uscita ho usato un proxy smtp, che mi consente di controllare subito la presenza di virus e di generare immediatamente l’errore al client, mentre per il flusso di uscita ho usato Spamassassin, ma senza Amavis.
In entrambi i casi ho dovuto scrivere codice (le ellissi verdi nel disegno sopra) per interfacciarmi con Sophos, perché ho trovato in rete molto poco (codice e documentazione). Ho usato il codice che usa Amavis, per l’esattezza il protocollo SSSP, che ho modificato ed adattato per il mio scopo; ho adattato lo stesso codice anche a Spamassassin, partendo da uno scheletro fatto per ClamAv.
Partiamo dall’inizio.
ClamAV
Come primo passo ho installato ClamAv. L’operazione è molto semplice, si trovano decine di tutorial, e bastano veramente un paio di comandi.
Ho installato anche l’estensione al DB dei virus di ClamAv, che trovate qua. Questa ha aggiunto quasi 4 milioni di impronte di virus in più rispetto alla versione base, per cui penso che sia una upgrade corretto.
Magari ne esistono altre, fatemi sapere.
Una volta installati questi software li ho messi in sicurezza con sistemi di monitor, ho configurato un aggiornamento una volta al giorno, e la gestione corretta dei rotate del log.
Avevo gia’ installato (me lo ha installato nella prima vecchia installazione Postfix insieme ad Amavis) il pacchetto Perl di interfacciamento a ClamAv, che si può anche trovare su CPAN. Se non lo avete installato lo trovate qua
Sophos Antivirus per Linux, versione FREE
L’installazione e la configurazione di Sophos non è stata così semplice come quella di ClamAv.
Il pacchetto si trova facilmente presso il sito ufficiale, e l’installazione di per se è banale.
Spacchettate il pacchetto, e eseguite il comando di installazione, ./install.sh che trovate nella directory.
Viene installato tutto il software antivirus, che vi consente di controllare il vostro computer.
Peccato che la maggior parte di quel software non serve a nulla. L’ho capito dopo moltissimi studi, ricerche e tentativi vari. Servono solo le librerie e il DB delle impronte dei virus (piu’ di 13 milioni..), mentre il resto viene utilizzato se usate il sistema come un PC, per controllare i files mentre lavorate; se usate il sistema come server avete bisogno anche di altro.
Per cui disabilitate tutto. Andate nella directory di installazione, (per me /opt/ sophos-av/bin) e eseguite i comandi per fermare i demoni di controllo.
for i in savd savwebd sav-protect sav-web do ./savdctl disableOnBoot $i done
A questo punto dovete scaricare un altro software da Sophos. Si chiama SAVDI (SAV Dynamic Interface), e vi consente da programma di parlare con le librerie e il DB di SOPHOS, ma (ATTENZIONE..) non con il demone SAVD di Sophos (descrivo in seguito la questione).
Uno sguardo ai nomi utilizzati:
Sophos è la suite,
SAVD il demone utilizzato per lo scan manuale e lo scan in tempo reale, ma non per i nostri scopi. I comandi manuali che si trovano sotto la directory /opt/sophos-av/bin controllano e hanno bisogno di SAVD.
SAVDI è la libreria che utilizza il DB e il motore di Sophos, ma NON ha bisogno di SAVD (infatti sopra lo abbiamo spento..).
Il demone di SAVDI si chiama SAVDID e implementa un protocollo di comunicazione da e verso le procedure esterne chiamato SSSP. Parla in qualche modo (anche se non ho ben capito come .. immagino che carichi semplicemente le librerie.. ) con le librerie di SAVD.
SAVDI si trova attualmente (settembre 2017) in un’area riservata di SOHOS, si può scaricare gratuitamente previa registrazione. Trovate il download qua e la documentazione qua.
L’installazione fatela con questo comando, in modo che vi metta tutto in una directory conosciuta, altrimenti lo script installa sotto /usr/local e vi può creare qualche problema
./savdi_install.sh -v -d /opt/sophos-av
Utilizzate uno script di partenza tipo questo, in modo da avere start/stop/status disponibili
#!/bin/bash
#
# description: Sophos SAV Dynamic Interface
#
# processname: savdid
function echo_success
{
echo "OK !"
}
function echo_failure
{
echo "Problema..:( "
}
status() {
if [ -f /var/run/savdid.pid ]
then
p=`cat /var/run/savdid.pid`
a=`ps -ef | grep -v grep | grep ${p} | wc -l`
if [ $a -gt 1 ]
then
echo "OK"
return 0
else
echo "program con Pid ${p} Not running "
return 1
fi
else
echo "program Not running "
return 1
fi
}
SAVDID=/opt/sophos-av/savdid/bin/savdid
PIDFILE=/var/run/savdid.pid
CONF_FILE=/opt/sophos-av/savdid/savdi/savdid.conf
# source function library
#. /etc/rc.d/init.d/functions
RETVAL=0
prog="savdid"
case "$1" in
start)
echo -n $"Starting $prog: "
# Start savdid in daemon mode, no banner, and specifying
# the pidfile
$SAVDID -d -s -f $PIDFILE -c $CONF_FILE
RETVAL=$?
# Sleep a moment to let savdid get things worked out
sleep 1
# The presence of the pidfile indicates that it is still running
[ -f $PIDFILE ] && RETVAL=0
if [ $RETVAL -eq 0 ]; then
echo_success
touch /var/lock/savdid
else
echo_failure
fi
echo
;;
stop)
echo -n $"Shutting down $prog: "
# Tell savdid to stop dead
[ -f $PIDFILE ] && kill -INT `cat $PIDFILE`
while [ -f $PIDFILE ]; do sleep 1; done
echo_success
rm -f /var/lock/savdid
echo
RETVAL=0
;;
restart)
echo -n $"Shutting down $prog: "
# Tell savdid to exit gracefully
[-f $PIDFILE ] && kill -TERM `cat $PIDFILE`
while [ -f $PIDFILE ]; do sleep 1; done
echo_success
echo
$0 start
RETVAL=$?
;;
reload)
echo -n $"Reloading $prog"
if [ ! -f $PIDFILE ]; then
echo " $prog is not running"
RETVAL=1
else
kill -HUP `cat $PIDFILE`
RETVAL=0
fi
echo
;;
condrestart)
if [ -f /var/lock/savdid ]; then
$0 stop
$0 start
fi
RETVAL=$?
;;
status)
status savdid
RETVAL=$?
;;
*)
echo $"Usage: $0
{start|stop|restart|reload|condrestart|status}"
exit 1
esac
exit $RETVAL
Il file di configurazione può rimanere inalterato, aggiungere un path migliore per il log, e attivate il controllo anche sui file in formato mail
logdir: /var/log/savdi/ savists: Mbox 1 savists: Mime 1
Questo vi dovrebbe consentire di farlo partire correttamente.
Per effettuare un test provate un telnet alla porta 4010, e al prompt date questi comandi (in grassetto):
root@mailserver 17 - # > telnet 0 4010
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
OK SSSP/1.0
SSSP/1.0 QUERY SERVER
ACC 59A58FBD/1
version: SAV Dynamic Interface 2.5.0
method: QUERY SERVER
method: QUERY SAVI
method: QUERY ENGINE
method: OPTIONS
method: SCANDATA
method: SCANFILE
maxscandata: 0
maxmemorysize: 250000
maxclassificationsize: 4096
SSSP/1.0 QUERY ENGINE
ACC 59A58FBD/2
engineversion: 3.69.2
date: 06/27/2017
filename: rans-eob.ide
state: 0
type: 0
.
.
.
noofidefiles: 248
savversion: 5.42
viruscount: 13614527
virusdatachecksum: A8EE97BF
BYE
BYE
Connection closed by foreign host.
Questo dovrebbe darvi la garanzia di funzionamento dell’interfaccia al DB di Sophos.
L’aggiornamento del DB lo effettuate con il comando savupdate -v 5 (mettetelo in un cron e chiamatelo una volta al giorno), che aggiorna tutto il sistema, anche se il demone SAVD non è attivo…
Ricordatevi di mettere tutto in sicurezza con un monitor che fa ripartire il demone SAVDID in caso di blocco, e vi avverta se non riparte correttamente.
Come impazzire in informatica…
Vi segnalo un problema che mi ha fatto letteralmente impazzire, e che non ho risolto.
Essenzialmente il comando savscan manuale, usato da Sophos per lo scan del file system, è più potente di SAVDI.
Il comando savscan può essere eseguito solo se il demone di Sophos (SAVD) è attivo, perché si appoggia a lui. Immaginavo che anche SAVDI lo usasse e invece NON è così. SAVDI funziona anche se il demone di Sophos (SAVD) è down!. Ho concluso che si appoggia ai DB dei virus, utilizza le librerie, ma non il core di Sophos, ne usa uno proprio, meno potente.
Il problema è nato casualmente; all’inizio dello studio ho lanciato manualmente lo scan su tutte le mail di tutti gli utenti, e ho individuato qualcuna di queste con dei virus. Ho preso a caso una fra queste mail come riferimento per i miei test.
Una volta messo in piedi tutto il sistema di test, e inviata questa mail con il virus (una mail con allegato un file .zip che conteneva un eseguibile di nome invoice.exe, sicuramente un virus), SAVDI la faceva passare, e lo stesso comportamento lo aveva ClamAv.
Inizialmente ho pensato che il mio sistema non funzionasse, poi ho capito che il virus non veniva rilevato. Ho impiegato due settimane per capire perché a linea comando, invocando direttamente Sophos il file veniva individuato, e tramite SAVDI no.
Il motivo è che Sophos (o meglio SAVD) invoca un meccanismo, chiamato SXLLiveProtection (Sophos eXtensible List), che non può essere attivato da SAVDI, e che “The Sophos eXtensible List is a database of anti-spam data, which is maintained on the Sophos servers and provides a real-time lookup service for the Sophos anti-spam engine.”.
Ho interpretato che sia una sorta di controllo esteso su cloud, che viene fatto solo dal comando manuale.
Avevo interpretato che SAVDI chiedesse a SAVD, ma non è così; questo usa solo il DB locale, e non riesce a fare un lookup in tempo reale come fa SAVD.
Per adesso mi sono fermato a questa conclusione, e non sono riuscito ad attivare questa feature anche per SAVDI. Se seguo il manuale mi viene generato un errore, e il demone non parte. Se qualcuno ci riesce è pregato di comunicarmelo, e lo ringrazio in anticipo.
ClamAv non individua il virus perchè ha la metà dei virus, rispetto a Sohos, nel suo DB, e non riesce a trovarlo.
Ho anche pensato di utilizzare il comando savscan per ogni mail, invece di SAVDI. Il fatto è che il comando savscan, che utilizza SAVD, ad ogni invocazione impiega 5 secondi per partire, perchè alla partenza di legge tutto il DB dei virus; questo vuol dire che ogni mail lo farebbe partire, e poi lo terminare, e questo è troppo oneroso in termini di CPU e attesa anche per un server, per cui ho dovuto abbandonare anche questa strada.
Meccanismo di controllo in tempo reale per le mail inviate con autenticazione
L’obiettivo è quello di controllare ogni mail che viene inviata da un utente. E’ necessario pensare una procedura che controlli ogni mail inviata live, al momento dell’invio. Il primo passo è stata la ricerca di un sistema che possa essere invocato da Postfix, e che sia in grado di controllare il contenuto della mail.
Inizialmente mi sono concentrato sul meccanismo del “check_policy_service”, utilizzato da postgrey e da una serie di controlli di congruenza iniziali. Ho scritto un software, che ho testato. Il protocollo di comunicazione funzionava correttamente, solo che questo meccanismo non passa “completamente” il body della mail. Non ho trovato da nessuna parte, sulla documentazione, scritto esplicitamente che il body non è utilizzabile; ho fatto infiniti test sulla mail in coda, ma la coda, al momento del test, viene passata, ma NON è congruente; l’accesso alla mail in coda genera un errore molto strano, di cui ho trovato poca documentazione, poiché la mail in coda non è completamente definita. Situazioni strane, che spesso trovo, proprio perché mi spingo al limite !
Il meccanismo del policy service alla fine consente un completo controllo dell’header, ma non del body; per cui va bene per tutti i controlli relativi ai dati presenti nell’header (utenti, autenticazioni, domini, liste ecc..) ma non va bene per gli antivirus che hanno bisogno del body della mail completo.
Ho ripiegato sul meccanismo del milter, quello che utilizza anche OpenDkim; i manuali dichiarano esplicitamente cha viene usato per questo tipo di controlli, per cui mi sono concentrato su questo protocollo, ma ho desistito dopo qualche ora di tentativi: non ho trovato esempi recenti con linguaggi di scripting (sh e perl), ma solo esempi in C e linguaggi complessi, che esulano dai miei scopi di integratore di sistemi, ma che vanno bene per gli sviluppatori di software.
Ho cercato ancora, e ho trovato una alternativa al milter; Postfix mette a disposizione un meccanismo di proxy, per cui, appena ricevuta una mail, SENZA metterla in coda, la invia ad un software esterno con protocollo SMTP. Questo server la salva su file, eventualmente la elabora, e quindi, sempre con protocollo SMTP la inoltra ad una coda di Postfix, che la gestisce correttamente. Il proxy può rifiutare la mail, e, dato che non è ancora presente in coda, il sistema invia un messaggio di rifiuto direttamente al client. E’ il meccanismo desiderato !
Per attuare questo passaggio ho installato un software che realizza un proxy SMTP. Lo trovate qua, è molto semplice da installare e configurare.
Lo installate con
apt-get install proxsmtp
Il file di configurazione è in /etc/proxsmtp/proxsmtp.conf
Le principale modifiche sono:
# The address to send scanned mail to. OutAddress: 10025 FilterCommand: /path/controllo_virus_proxy.pl FilterType: file # Address to listen on (defaults to all local addresses on port 10025) Listen: 127.0.0.1:10026 User: clamav
Essenzialmente ho impostato le porte di ricezione e di invio in localhost, il file che deve essere invocato per il controllo della presenza di virus, il flag che genera un file e non un flusso di dati, e l’utente che deve essere lo stesso di clamav, perché altrimenti quest’ultimo ha problemi ad analizzare il file (savdid no perché gira come root).
Una volta messo in sicurezza il file con sistemi di monitoraggio e di restart (se si ferma non va più la posta…) lo si invoca da Postfix in questo modo
File mastes.cf
# SMTP over SSL on port 465. smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous -o smtpd_proxy_filter=127.0.0.1:10026
Questo invia al proxy la mail in arrivo dalla porta 465
e
127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
Questo riceve la mail dal proxy sulla porta 10025 e la mette in coda in Postfix per altre elaborazioni.
Il software di controllo
E’ necessario scrivere il software per controllare la mail. Essenzialmente questo software riceve un file, lo invia a SAVDID e quindi a ClamAv, e se non ha errori esce con codice 0, mentre se gli antivirus individuano un virus esce con codice 1, e sullo standard Error (NON sullo standard output… chissà perché ma è così… ) scrive il messaggio di errore.
Questo è un test con un virus di prova, per verificare la correttezza del comportamento, dal client di posta al momento dell’invio si vede questo messaggio
Questa mail contiene diversi virus, prelevati da archivi controllati. Il test è stato fatto per verificare la correttezza in presenza di più virus, in archivi di differente formato.
Il software deve dialogare sia con SAVDID sia con ClamAv.
Il dialogo con SAVDID può essere realizzato con questa libreria, ma ho avuto dei problemi di controllo ed errori inspiegabili, e ho preferito utilizzare un sistema testato; ho preso il codice di Amavis, e l’ho ‘cusotmizzato’ secondo le mie esigenze. Ho usato il protocollo SSSP, molto light e facilmente testabile, e l’ho adattato ai miei scopi. Ho creato una sorta di libreria, che mi è servita anche per Spamassassin. Lo stesso ho fatto con ClamAv, anche se per questo antivirus esistono librerie consolidare che sono risultate estremamente semplici da usare.
Il risultato è un programma in Perl che riceve un file, lo controlla e ritorna un codice ( 0 o 1 ) ed eventualmente un messaggio di errore se il codice è 1.
Integrazione con Spamassassin
Anche per l’integrazione con Spamassassin ho dovuto scrivere codice Perl.
Ho trovato qua una spiegazione su come integrare Spamassassin con ClamAv senza passare per Amavis. In questo articolo è presente del codice Perl, che ho preso ed adattato anche per SAVDID.
Per cui ho realizzato non solo l’interfaccia da Spamassassin verso ClamAv, ma anche verso SAVDID.
Il codice Perl che ho scritto per SAVDID ha la medesima struttura di quello per ClamAv, ma sfrutta le librerie che mi ero preparato nel programma precedente.
Dato che in Spamassassin realizzo 2 controlli, uno relativo alle blacklist DNS, e l’altro relativo alla presenza di virus, ho dovuto generalizzare il messaggio di errore, con l’opzione report della configurazione.
Il messaggio finale appare all’utente finale come questo:
Ho cerchiato in rosso un pezzo del messaggio, perché è una personalizzazione del codice di Spamassassin che ho realizzato. In pratica, in base al punteggio, personalizzo il messaggio di avvertenza.
La modifica è stata fatta direttamente sul codice, ed essenzialmente ho modificato l’output della macro _SUBVERSION_ che può essere usata nei report.
Al momento della invocazione della macro controllo il punteggio, e personalizzo il messaggio.
Questo è il codice:
file /usr/share/perl5/Mail/SpamAssassin/PerMsgStatus.pm
112
113 # SUBVERSION => sub { $Mail::SpamAssassin::SUB_VERSION },
114 SUBVERSION => sub {
115 my $pms = shift;
116 my $a=$pms->_get_tag_value_for_score(@_);
117 my $b=$pms->_get_tag_value_for_required_score(@_);
118 $a > 24.0 ? ( $a > 36.0 ) ? "Mail ad altissima probabilita' di spam o VIRUS".$a."/".$b : "Mail ad alta probabilita' di spam o Virus". $a."/".$b : "Mail a bassa probabilita' di spam o virus".$a."/".$b;
119
120 },
121
Integrazione con POSTFWD
Ho inserito anche un sistema che limita il numero di mail nel tempo. Ho trovato questo software, che utilizza il meccanismo del check_policy_service e che risulta essere molto flessibile.
Attenzione che questo software non si appoggia a file o db (come postgrey) ma tiene tutto in memoria. Se lo fermate perde tutta la storia.
Una volta installato con il comando
apt-get install postfwd
deve essere abilitato nel suo file di configurazione
root@mailserver 44 - ~/ # > cat /etc/default/postfwd # Global options for postfwd(8). # Set to '1' to enable startup (daemon mode) STARTUP=1 # Config file CONF=/etc/postfix/postfwd.cf # IP where listen to INET=127.0.0.1 # Port where listen to PORT=10045 # run as user postfw RUNAS="postfw" # Arguments passed on start (--daemon implied) ARGS="--summary=43200 --cache=600 --cache-rdomain-only --cache-no-size -t"
L’opzione –t lo pone in modalità test, e non lo fa agire.
Il file di configurazione per le azioni è il seguente:
root@mailserver 45 - ~/ # > cat /etc/postfix/postfwd.cf id=R01; action=rate(sender/250/86400/REJECT 452 4.5.3 Error: limite di 250 per giorno superato: Spam RISK [$$ratecount hits]) id=R02; action=rate(sender/50/600/REJECT 452 4.5.3 Error: limite di 50 mail per 10 min superato [$$ratecount hits] - Spam RISK - usare sistema di gestione liste)
Attenzione che l’opzione WARN in realtà non serve a nulla, viene scritto solo un messaggio nel file di log, secondo la politica di Postfix.
Ricordatevi sempre di mettere in sicurezza tutti i demoni, con un meccanismo di monitoraggio e di restart, perché se uno di questi di ferma il flusso delle mail si interrompe completamente.