Scenario

Server di posta Microsoft Exchange 2010 utilizzato sia per l’invio (SMTP) che per la ricezione (POP3/IMAP4) di email.

Problema

Quantitativi di spam abnormi sulle mailbox degli utenti. Inutile dire che qualunque preventivo per un antispam degno di questo nome si aggirava, almeno, sui 5 mila euro.

Soluzione

Realizzare un sistema antispam basato su Centos 6, Postfix, Amavisd-new, Spamassassin e ClamAV.
Data la complessità del presente articolo, ho deciso di suddividerlo in varie sezioni, una per ciascuno dei suddetti software che concorrono alla creazione del nostro antispam.

Postfix

Il seguente servizio di posta è, a mio avviso, uno dei migliori in circolazione per ambienti Unix/Linux (addirittura superiore allo stesso exim/exim4, che ho utilizzato per anni). La regola che ho seguito durante la sua configurazione è la seguente: restringere il più possibile il range delle email accettate in ingresso affinchè sia possibile ridurre il carico sul sistema antispam vero e proprio (molto più oneroso in termini computazionali).
La configurazione di Postfix che ho realizzato si suddivide in 4 parti fondamentali, ovvero:

1) mydestination, che identifica il dominio per il quale l’antispam dovrà filtrare le email in ingresso;
2) myhostname e mydomain, che concorrono a formare l’FQDN dell’antispam (il quale deve, possibilmente, coincidere con il record PTR associato all’IP pubblico e con l’FQDN del record MX);
3) mynetworks_style e mynetworks, che identificano le subnet per le quali applicare delle misure di sicurezza più blande;
4) smtpd_helo_restrictions, in cui vengono discriminati i vari metodi utilizzati dai client per “presentarsi” al server;
5) smtpd_sender_restrictions, il cui compito è quello di scremare gli indirizzi di posta mittenti;
6) smtpd_recipient_restrictions, grazie alla quale è possibile impostare delle regole di filtraggio per gli indirizzi di destinazione;
7) smtpd_client_restrictions, per decidere quali elementi identificativi dei client utilizzati per l’inoltro delle email (ad esempio indirizzo IP sorgente, tipo di software usato, ecc.) sono consentiti e quali non lo sono.

Ecco la configurazione in todo:

mydestination = vostrodominio.com

myhostname = antispam
mydomain = vostrodominio.com

mynetworks_style = subnet
myneworks = 127.0.0.1, 192.168.11.1, 172.16.12.3

smtpd_helo_required = yes

smtpd_helo_restrictions =
 permit_mynetworks,
 reject_non_fqdn_helo_hostname,
 reject_invalid_helo_hostname,
 permit

smtpd_sender_restrictions =
 permit_mynetworks,
 check_sender_access hash:/etc/postfix/sender_access,
 reject_unknown_sender_domain,
 permit

smtpd_recipient_restrictions =
 permit_mynetworks,
 reject_unauth_destination,
 check_policy_service unix:private/policy
 reject_unauth_pipelining,
 reject_rbl_client zen.spamhaus.org,
 reject_rbl_client bl.spamcop.net,
 check_recipient_access hash:/etc/postfix/recipient_domains,
 permit

smtpd_client_restrictions =
 permit_mynetworks,
 check_client_access regexp:/etc/postfix/client_restrictions,
 check_client_access hash:/etc/postfix/rbl_permitip,
 reject_unknown_reverse_client_hostname,
 permit

In soldoni, per prima cosa faccio in modo che i client della LAN non siano soggetti a restrizione alcuna (permit_mynetworks) e successivamente impongo ai client esterni di “presentarsi” al server, usando obbligatoriamente l’FQDN (reject_non_fqdn_helo_hostname) e non ammettendo errori di sintassi durante l’inolto del comando HELO/EHLO.

Successivamente focalizzo la mia attenzione sugli indirizzi di posta mittenti. Come al solito, non imposto alcun filtro sui client della LAN. Successivamente, tramite il file sender_access e la direttiva check_sender_access, consento l’inoltro di messaggi di posta da parte degli indirizzi che ho specificato al suo interno (bypassando alcune restrizioni successive). Da notare che il file possiede come preambolo hash:, il che significa che per farlo digerire da Postfix è necessario lanciare il comando:

[root@antispam postfix]# postmap sender_access

in modo tale da creare un file recante lo stesso nome ma con estensione *.db, e successivamente:

[root@antispam postfix]# service postfix reload

Per completezza, il contenuto del file sender_access è simile al seguente:

indirizzo1@vostrodominio.com OK
 indirizzo2@vostrodominio.com OK
 indirizzo3@altrovostrodominio.com OK
 vostrodominio.com REJECT
 altrovostrodominio.com REJECT

Le prime 3 righe marcano come lecite alcune email il cui indirizzo mittente reca come dominio uno di quelli gestiti dal nostro server di posta. Infatti, per evitare il cosiddetto email address spoofing, è buona regola bloccare tutte le email di questo tipo provenienti dall’esterno, fatta eccezione per alcuni casi particolari (vedi, ad esempio, un webform su un server remoto che sfrutta il nostro server antispam per inviare messaggi di posta ad una o più caselle di posta interne). Successivamente vedremo come, nonostante il nostro antispam non preveda autenticazione e consenta il passaggio di alcune email aventi come indirizzo mittente uno appartenente ai nostri domini interni, non sia possibile effettuare uno spoofing degli stessi (grazie al Sender Policy Framework).

Successivamente faccio in modo di impedire l’inoltro di tutte le email provenienti da domini inesistenti (riducendo di un buon 30% la mole totale di spam). Infatti, qualunque open relay accessibile da Internet, consentirà di impostare come indirizzo email mittente uno completamente casuale, appartenente a domini anch’essi casuali.

Passiamo adesso ai filtri sui destinatari. Come al solito, la prima cosa da fare è consentire il traffico proveniente dalla nostra LAN e successivamente bloccare il traffico avente come destinatario un’indirizzo email non appartenente a nessuno dei nostri domini interni (reject_unauth_destination), grazie alla quale impediamo al nostro server di posta antispam di funzionare come un open relay.
Mediante la direttiva check_policy_service unix:private/policy siamo in grado di sfruttare l’SPF per filtrare ulteriormente la posta in ingresso (successivamente mi soffermerò sull’abilitazione/integrazione di tale protocollo con Postfix); con reject_unauth_pipelining si impedisce agli scanner/bot di inviare più comandi email in una sola riga (allungando i tempi associati ai loro tentativi); con reject_rbl_client possiamo definire quali ACL pubbliche offerte dai servizi antispam (come, ad esempio, spamhaus.com e spamcop.net) utilizzare per filtrare le email in ingresso. Infine, con check_recipient_access ed il file /etc/postfix/recipient_domains si istruisce il nostro antispam su quali domini può recapitare la posta in ingresso. Il file recipient_domains ha una struttura simile alla seguente:

vostrodominio.com OK
 altrovostrodominio.com OK

Come al solito lanciamo i comandi:

[root@antispam postfix]# postmap recipient_domains

e

[root@antispam postfix]# service postfix reload

per rendere operative tali modifiche.

Infine, impostiamo dei filtri relativi ai client che contattano il nostro server di posta/antispam per l’inoltro di email (all’interno del file client_restrictions).

Per prima cosa, tramite delle espressioni regolari (regexp), valuto alcuni parametri associati ai client che si connettono al server per l’invio della posta elettronica. Il file ha una struttura simile alla seguente:

### WHITE LIST mostly trusted host names ###
 /\.hotmail\.com$/ OK
 /\.google\.com$/ OK
 /\.yahoo\.com$/ OK

### Generic Block of DHCP machines or those with many numbers in the hostname ###
 /^(dhcp|dialup|ppp|adsl|pool)[^.]*[0-9]/ 550 S25R6 check

### BLACK LIST known spammer friendly ISPs ###
 /\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 550 domain check tpnet
 /^user.+\.mindspring\.com$/ 550 domain check mind
 /[0-9a-f]{4}\.[a-z]+\.pppool\.de$/ 550 domain check pppool
 /\.dip\.t-dialin\.net$/ 550 domain check t-dialin
 /\.(adsl|cable)\.wanadoo\.nl$/ 550 domain check wanadoo

I commenti riportati sono abbastanza esplicativi e non necessitano di ulteriori approfondimenti. Da notare che, trattandosi di un file che sfrutta le espressioni regolari, ho utilizzato il regexp come preambolo.

Mediante il file rbl_permitip specifico tutti gli indirizzi IP mittenti per i quali non bisogna effettuare alcun check sull’esistenza del record A/PTR. In particolare, tale check prende il nome di FCrDNS, ovvero Forward Confirmed Reverse DNS, implementabile tramite la direttiva reject_unknown_client_hostname. Esso, in soldoni, dapprima verifica che all’indirizzo IP mittente corrisponda un determinato hostname (reverse DNS query o query PTR). Una volta fatto ciò, viene verificato che a quell’hostname corrisponda effettivamente l’indirizzo IP mittente (consultando il record A DNS). Se entrambi i check vanno a buon fine l’email verrà recapitata, altrimenti nisba. Non ci vuole molto a capire che tale meccanismo è fin troppo stringente, causando il mancato inoltro di molte email lecite. E’ proprio per questo motivo che nella configurazione ho sostituito reject_unknown_client_hostname con reject_unknown_reverse_client_hostname, per il quale, dei 2 step precedentemente citati, viene effettuato solo il primo.

Adesso dobbiamo fare in modo che il nostro server di posta/antispam recapiti tutti i messaggi leciti al servizio SMTP di Exchange 2010 in ascolto sulla LAN (relay). Per fare questo è necessario specificare una transport_map, mediante la direttiva:

transport_maps = hash:/etc/postfix/transport

dove il file transport ha una struttura simile alla seguente:

vostrodominio.com smtp:[192.168.1.10]
 altrovostrodominio.com smtp:[192.168.1.10]

Come al solito, essendo un file di tipo hash, andiamo dapprima di postmap e successivamente di reload per il servizio Postfix.

Inoltre, poichè lo scopo di Postfix è quello di inoltrare le email al servizio SMTP di Exchange (il quale, a sua volta, le recapiterà alle mailbox di destinazione) è necessario che non venga effettuato alcun controllo sull’effettiva esistenza del destinatario, utilizzando la direttiva:

local_recipient_maps =

Come ultimo step, facciamo in modo che il contenuto delle email venga filtrato da Amavisd-new (la cui configurazione verrà trattata nei post successivi). Inseriemo dunque anche tale direttiva (come le precedenti) nel file di configurazione principale di Postfix, ovvero main.cf:

#content_filter = smtp-amavis:[127.0.0.1]:10024

Salviamo dunque il file in oggetto (lasciando la suddetta riga commentata) ed abbiamo finito con la configurazione di Postfix per quanto riguarda le regole di filtraggio ed il trasporto. Concentriamoci adesso sull’integrazione di SPF con il demone di posta in questione.

SPF e Postfix

Per prima cosa insieriamo tale direttiva all’interno del file master.cf presente in /etc/postfix:

policy unix - n n - - spawn
 user=nobody argv=/usr/lib/postfix/postfix-policyd-spf-perl

Disabilitiamo dunque SElinux:

[root@antispam postfix]# setenforce 0

e facciamo in modo che SElinux sia disattivo anche dopo eventuali riavvii della macchina:

[root@antispam postfix]# nano /etc/sysconfig/selinux

sostituendo:

SELINUX=enforcing

con

SELINUX=disabled

Scarichiamo lo scrip perl eseguibile grazie al quale sarà possibile effettuare i controlli SPF:

[root@antispam postfix]# wget http://www.openspf.org/blobs/postfix-policyd-spf-perl-2.001.tar.gz

salvandolo nella directory /usr/src e scompattandolo con un tar -xvf. A questo punto copiamo l’eseguibile policyd-spf-perl in /usr/lib/postfix/

lanciamo un reload di Postfix ed il filtro SPF sarà finalmente attivo.

SPF e record DNS di tipo TXT

Il Sender Policy Framework è un meccanismo piuttosto semplice grazie al quale è possibile controllare gli indirizzi email mittenti relativi ai propri domini. Ad esempio, mediante di esso, nessun cracker/spammer potrà spacciarsi per qualcuno di @vostrodominio.com pur utilizzando un open relay (che non effettua nessun controllo sugli indirizzi di posta mittenti e di destinazione). Questo perchè, mediante un record DNS di tipo TXT appositamente forgiato, sarà possibile elencare gli indirizzi IP autorizzati ad untilizzare uno dei nostri domini nell’ambito degli indirizzi di posta mittenti.

Il record TXT in oggetto avrà una forma simile alla seguente:

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 -all

dove 1.2.3.4 e 5.6.7.8 sono gli unici indirizzi IP sorgenti autorizzati ad inviare email con mittente @vostrodominio.com oppure @altrovostrodominio.com.

Salvate le modifiche appena effettuate sulla vostra zona DNS ed aspettate che tale record si propaghi. Per verificare che la propagazione sia effettivamente avvenuta basta andare di dig:

[root@antispam postfix]# dig -short vostrodominio.com TXT

La successiva risposta dovrebbe riportare il contenuto del record TXT da voi precedentemente creato.

Infine, una precisazione: tramite SPF state facendo in modo che nessuno possa spoofare uno dei vostri indirizzi email e quindi utilizzarlo come mittente verso una delle vostre mailbox interne (fruttando il server di posta/antispam che avete appena configurato). Non essendo, però, l’SPF mandatorio, utilizzando un open relay si potrebbe comunque spoofare uno dei vostri indirizzi email ed inoltrare dei messaggi di posta fraudolenti a delle mailbox che non sfruttano tale meccanismo per il controllo del mittente.

Ah, se non lo avete ancora fatto, abilitate l’avvio di Postfix in modo automatico per i runlevel 2,3,4 e 5:

[root@antispam postfix]# chkconfig --levels 2345 postfix on

Fine del post, nella parte 2 discuterò della configurazione di Amavisd-new, di spammassassin e di ClamAV.

Alla prossima.