Fin’ora abbiamo visto come identificare e bloccare buona parte dello spam. Adesso, però, vorrei soffermarmi sul cosiddetto greylisting. Esso, se configurato in modo corretto, consente di droppare ben il 99% delle email sospette.

Il greylisting

La tecnica del greylisting è piuttosto banale: per ogni email ricevuta viene memorizzata una tripletta di informazioni, ovvero indirizzo email sorgente, indirizzo email di destinazione ed indirizzo IP sorgente. Quando questa triade viene “vista” per la prima volta dal nostro server antispam, il mittente si becca un errore 450 e la sua email verrà temporaneamente respinta (per un periodo ben definito, solitamente 5 minuti). Trascorsi i 5 minuti un ulteriore invio della suddetta email darà esito positivo (con successivo recapito sulla mailbox di destinazione). Ma su cosa si basa tale logica di funzionamento? Semplice. Solitamente gli spammer contattano migliaia di indirizzi di posta elettronica in brevissimo tempo e quando ricevono un errore di recapito (qualunque esso sia), dato il gran numero di mailbox bersaglio, non tentano un nuovo invio.

Postfix e greylisting: postgrey

Abilitare la suddetta funzione sul nostro server antispam che si avvale di Postfix come MTA è piuttosto semplice. Basta, infatti, installare un applicativo denominato appunto postgrey utilizzando yum:

[root@antispam ~]# yum install postgrey

oppure da *.rpm:

[root@antispam ~]# wget ftp://fr2.rpmfind.net/linux/dag/redhat/el2.1/en/i386/dag/RPMS/postgrey-1.34-1.el2.rf.noarch.rpm

[root@antispam ~]# rpm -ivh postgrey-1.34-1.el2.rf.noarch.rpm

Una volta installato il suddetto software, occorre modificare il file di configurazione di Postfix, ovvero /etc/postfix/main.cf, inserendo tale direttiva:

 check_policy_service unix:postgrey/socket

nella sezione:

smtpd_recipient_restrictions

Un esempio di configurazione potrebbe essere il seguente:

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

Adesso ricarichiamo la configurazione di Postfix per rendere effettive tali modifiche:

[root@antispam ~]# service postfix reload

ed abbiamo finito.

Nel caso in cui alcune triplette garantiscano l’invio di email lecite, le si può semplicemente whitelistare editando il file /etc/postfix/postgrey_whitelist_clients, aggiungendo al suo interno il nome (o l’indirizzo IP) degli MTA mittenti.

Fine del post, alla prossima.

Su questo blog ho già discusso di un valido tool di monitoraggio/alerting che prende il nome di swatch. Il suo funzionamento è abbastanza semplice: gli si da in pasto un determinato file di log e si fa in modo che vada a ricercare pattern specifici da noi precedentemente definiti.

Detto ciò, vediamo quale potrebbe essere una valida configurazione per il suddetto applicativo:

#SMTP Domain not found
watchfor  /Domain not found/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Domain not found
#SMTP Sender address rejected
watchfor  /Access denied/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Access denied
#SMTP Cannot find your reverse hostname
watchfor  /cannot find your reverse hostname/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Cannot find your reverse hostname
#SMTP SPF reject
watchfor  /openspf/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: SPF reject
#SMTP Relay access denied/
watchfor /Relay access denied/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Relay Access Denied
#SMTP Amavis blocked
watchfor /Blocked/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Amavis Blocked
#SMTP Spam
watchfor /SPAM/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Spam
watchfor /SPAMMY/
     echo     
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH ANTISPAM: Spammy

In particolare:

1) il pattern /Domain not found/ identifica tutte le email il cui @dominio non esiste (ad esempio @xvfz.com);

2) con /Access denied/  identifico tutti i client (o indirizzi IP) che sono in blacklist sul mio server di posta/antispam (rbl, client restrictions e così via);

3) con /cannot find your reverse hostname/ si identificano tutti i client non dotati di PTR che hanno provato ad inviare email tramite il nostro server;

4) con /openspf/ individuo tutte le email respinte dal Sender Protocol Framework;

5) il pattern /Relay access denied/ indica tutti i tentativi di inoltro di email verso domini esterni, ovvero non direttamente gestiti dal nostro server di posta (attraverso la direttiva transport_maps);

6) con /Blocked/ individuo tutti i messaggi di posta bloccati da Amavisd-new (poichè contenenti virus, worm, macro o software malevolo in genere);

7) con /SPAM/ identifico tutte le email considerate tali da Amavisd-new e Spamassassin (esse non verranno inoltrate in Posta indesiderata, ma verranno semplicemente respinte poichè si tratta di spam conclamato);

8) il pattern /SPAMMY/ indica le presunte email di spam individuate da Amavisd-new e Spammassassin che verranno inoltrate nella directory Posta indesiderata e non completamente respinte (poichè sembrano spam ma non si ha la certezza).

Avviamo swatch mediante il comando:

[root@antispam ~] swatch -c /etc/swatch.conf -t /var/log/maillog &

e modifichiamo il file /etc/rc.local in modo tale da garantire l’avvio automatico di tale software dopo ogni riavvio della macchina:

[root@antispam ~] nano /etc/rc.local

aggiungendo la direttiva:

#swatch
swatch -c /etc/swatch.conf -t /var/log/maillog &

Salviamo il file appena modificato ed abbiamo finito.

Alla prossima.

Terza ed ultima parte del tutorial dedicato alla realizzazione di un antispam open source basato su Centos 6. Nello specifico, vedremo come configurare Exchange in modo da consentire l’inoltro automatico dello spam nella cartella Posta Indesiderata (alias Junk E-mail).

Per prima cosa accediamo alla console di Management di Exchange e successivamente clicchiamo su Organization Configuration -> Hub Trunsport -> Transport Rule.

A questo punto creiamone una nuova , la quale ci consentirà di identificare tutte le email che hanno il campo X-Spam-Flag dell’header impostato a YES , associando loro un livello di spam confidence pari a 6 (in tal modo avremo la “certezza” che tutto lo spam verrà spostato nella cartella Posta Indesiderata).

Per verificare che tutto stia funzionando correttamente possiamo contattare il nostro server antispam via telnet:

[root@antispam ~]# telnet localhost 25

ed usare la seguente stringa come DATA del messaggio di posta:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Se la suddetta email viene marcata con il subject  ***SPAM*** e spostata direttamente in Posta Indesiderata significa che il nostro sistema antispam sta funzionando come dovrebbe.

Nel prossimo post vedremo come monitorare i tentativi di spam diretti al nostro mail server.

In questo post ho trattato principalmente la configurazione di Postfix, accennando solo marginalmente agli altri software che concorrono alla realizzazione del nostro antispam.

Tra i suddetti software il ruolo principale è sicuramente svolto da Amavisd-new, il quale non fa altro che “coordinare” l’operato del demone antispam vero e proprio (Spamassassin) e dell’antivirus (ClamAV).

A grandi linee, l’operato del suddetto applicativo si può riassumere in quanto segue:

1) Postfix prende in pancia l’email appena ricevuta, la analizza e controlla che sia lecita utilizzando i filtri che abbiamo precedentemente creato;

2) Successivamente, se l’email ha superato tutti i suddetti controlli, viene girata ad Amavisd-new, il quale procede dapprima con la scansione antivirus (sfruttando ClamAV) e successivamente, grazie a Spamassassin, assegna alla stessa un determinato ranking (Hits). Tutte le email recanti un valore di Hits superiore ad una certa soglia verranno marcate come spam (tramite l’aggiunta del campo X-Spam-Flag impostato a yes) all’interno dell’header dell’email (aggiungendo in modo automatico la flag ***SPAM*** all’oggetto dei messaggi di posta incriminati). In questo modo, Exchange 2010 (dopo aver configurato il Receive Connector in modo opportuno), sarà in grado di segnalarle come spam e di spostarle automaticamente nella directory Posta Indesiderata.

Installazione e configurazione di Amavisd-new

Per installare il pacchetto precompilato appositamente per la nostra distribuzione è necessario su yum i repository rpmforge ed rpmforge-extras:

[root@antispam ~]# yum --enablerepo=rpmforge,rpmforge-extras

A questo punto andiamo di yum install:

[root@antispam ~]# yum install amavisd-new

Ad installazione avvenuta facciamo in modo che tale demone sia attivo anche dopo un eventuale riavvio della macchina:

[root@antispam ~]# chkconfig --levels 2345 amavisd on

Passiamo, adesso, alla configurazione del demone in questione. Il file che dovremo editare è /etc/amavisd/amavisd.conf, in cui bisogna apportare le seguenti modifiche:

1) Non effettuare alcun tipo di controllo sulle email provenienti dalla LAN:

$policy_bank{'MYNETS'} = {   # mail originating from @mynetworks  originating => 1,  # is true in MYNETS by default, but let's make it explicit  os_fingerprint_method => undef,  # don't query p0f for internal clients
 bypass_spam_checks_maps   => [1],  # don't spam-check internal mail  bypass_banned_checks_maps => [1],  # don't banned-check internal mail  bypass_header_checks_maps => [1],  # don't header-check internal mail};

2) Definire i domini interni e le subnet della mia LAN:

@local_domains_maps = ( [".$mydomain", ".vostrodominio.com"] ); $@mynetworks = qw( 127.0.0.1 192.168.1.0/24);

3) Configurare il pathame corretto relativo al pid di ClamAV:

\&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"],

4) Impostare i parametri di funzionamento relativi a Spamassassin (identificati dal preambolo sa_):

$sa_tag_level_deflt  = -999;  # add spam info headers if at, or above that level
 $sa_tag2_level_deflt = 6.2;  # add 'spam detected' headers at that level
 $sa_kill_level_deflt = 6.9;  # triggers spam evasive actions (e.g. blocks mail)
 $sa_dsn_cutoff_level = 10;

In particolare, con $sa_tag_level_deflt  = -999;  sto facendo in modo che Spamassassin aggiunga sempre a comunque (quindi anche alle email lecite) il campo X-Spam-Flag nell’header delle email, impostandolo a yes in caso di spam ed a no in caso di ham.

5) Infine, imposto il comportamento di default in caso di email contenenti virus o spam:

$final_virus_destiny      = D_DISCARD;
 $final_banned_destiny     = D_BOUNCE;
 $final_spam_destiny       = D_PASS;
 $final_bad_header_destiny = D_BOUNCE;

Ovviamente consento comunque il passaggio dello spam, in quanto sarà Exchange a gettarlo direttamente tra la posta indesiderata.

Installazione di Spamassassin

Installiamo ora Spamassassin mediante il comando:

[root@antispam ~]# yum install spamassassin

Rendiamo automatico il suo avvio in fase di bootstrap del SO:

[root@antispam ~]# chkconfig --levels 2345 spamassassin on

Ed avviamolo:

[root@antispam ~]# service spamassassin start

Installazione di ClamAV

Anche l’installazione di ClamAV può essere eseguita mediante yum:

[root@antispam ~]# yum install clamav

Come al solito, rendiamo automatico l’avvio del demone in questione:

[root@antispam ~]# chkconfig --levels 2345 clamd on

modifichiamo il gruppo amavis aggiungendo l’utente clam:

[root@antispam ~]# usermod -a -G amavis clam

ed eseguiamolo:

[root@antispam ~]# service clamd start

Ovviamente un software antivirus non aggiornato è totalmente inutile. A tal proposito ecco uno qualche riga di codice bash che ci permetterà di automatizzare il download delle firme aggiornate (effettuando anche una scansione dell’intero sistema):

#!/bin/bash
 SCAN_DIR="/"
 LOG_FILE="/var/log/clamav/manual_scan.log"
 /usr/bin/freshclam
 /usr/bin/clamscan -i -r $SCAN_DIR >> $LOG_FILE
exit 0

Salviamolo col nome di manual_scan e rendiamolo eseguibile:

[root@antispam ~]# chmod +x manual_scan

Successivamente scheduliamo la sua esecuzione mediante /etc/crontab:

15    03    * * *     root          /root/script/manual_scan

A questo punto, sarà possibile avviare anche Amavisd-new:

[root@antispam ~]# service amavisd start

verificando che sia effettivamente in ascolto sulla porta di default, ovvero la 10024:

[root@antispam ~]# telnet localhost 10024

Ultime configurazioni per Postfix

Il nostro sistema antispam è quasi pronto, occorre semplicemente apportare alcune modifiche sul file di configurazione principale di Postfix (main.cf) e sul file che regola il funzionamento del processo principale di tale demone, ovvero master.cf.

All’interno di main.cf è sufficiente decommentare la seguente direttiva:

content_filter = smtp-amavis:[127.0.0.1]:10024

Mentre, all’interno di master.cf è necessario inserire le seguenti direttive:

smtp-amavis     unix    -       -       -       -       2       smtp
 -o smtp_data_done_timeout=1200
 -o smtp_send_xforward_command=yes
 -o disable_dns_lookups=yes
 -o max_use=20

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_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

Infine ricarichiamo la configurazione di Postfix:

[root@antispam ~]# service clamd start

ed abbiamo finito.

Nella terza parte parlerò della configurazione di Exchange 2010 per l’invio automatico dello spam nella cartella Posta Indesiderata.

Alla prossima.

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.