Compago

...free knowledge

 
  • Increase font size
  • Default font size
  • Decrease font size
Home Manuali Linux Consigli sulla configurazione del server Postfix

Consigli sulla configurazione del server Postfix

E-mail Stampa PDF

Questo articolo cercherà di descrivere brevemente alcuni dettagli sulla configurazione di un server di posta postfix, ma non sarà una guida all'installazione. Innanzitutto è bene chiarire un po' di concetti legati ai server di posta, in primo luogo le varie tipologie di software e le relative funzioni. Infatti potremo definire postfix come un server MTA ovvero mail transfer agent, cioè un software che trasferisce email da un computer ad un altro utilizzando il protocollo SMTP (Simple Mail Transfer Protocol).
In pratica una MTA può ricevere le email da un altro MTA oppure da un MSA (Mail Submission Agent) oppure da un MUA (Mail User Agent), che per intenderci potrebbe essere un software come Outlook. Solitamente sotto windows i software che gestiscono la posta sono solo dei MUA che delegano l'invio delle email ai MTA, i quali generalmente sono gestiti dagli ISP a cui ci si collega, e agiscono come un ufficio postale prendendosi carico del trasferimento della posta a ulteriori MTA e arrivando alla consegna della stessa.
Fisicamente il messaggio di posta può essere memorizzato in formato file, per cui avremo tanti file quanti sono i messaggi di posta, oppure inserito in un database, questo dipende solo da come è configurato l'MTA finale.

Giusto per essere chiari solitamente un server MTA è associato ad un server MDA ovvero Mail Delivery Agent, che invece si occupa dei messaggi già spediti e che i vari utenti vogliono leggere. Infatti quasi mai l'utente destinatario di una mail va a leggere l'email nel server dove è stata fisicamente consegnata, quindi tramite protocollo POP3 o IMAP il server MDA ha il compito di spedire i messaggi di un utente verso il suo email client (MUA) preferito. Un esempio di software MDA sono Dovecot, Courier, Procmail etc..

Riassumendo il server MTA entra in gioco quando si tratta di inviare un nuovo messaggio e consegnarlo al destinatario, mentre un MDA viene usato quando il destinatario vuole leggerlo.

Un altra cosa da chiarire è la configurazione di un record di tipo MX (Mail Exchanger) in un contesto di DNS (Domain Name System), infatti quando viene assegnato un dominio non solo dovremo indicare il classico indirizzo del webserver, ma anche l'indirizzo del server di posta (MTA) che potrebbe essere diverso da quello del webserver.

Veniamo ora all'argomento principale di questo articolo ovvero la configurazione di postfix in relazione alla sicurezza e allo spam. Per gli utenti che hanno una email ormai è un dato di fatto che la maggior parte del traffico di posta è rappresentato da messaggi commerciali indesiderati ovvero unsolicited commercial email (UCE). Gli amministratori dei server di posta dovrebbero implementare dei controlli per minimizzare questo tipo di traffico diretto agli utenti. Di seguito descriveremo come postfix deve essere configurato per filtrare questo tipo di traffico.

Prima di iniziare vediamo in cosa consiste una semplice transazione SMTP, dato che poi potrebbe servire per fare alcuni test sul funzionamento del server di posta.

Per testare il protocollo SMTP di un server di posta collegatevi ad esso con telnet sulla porta 25

telnet <IP> 25

dove <IP> sarà l'indirizzo del server MTA a cui ci vogliamo connettere.

Una volta connessi digitate i comandi per inviare una email:

EHLO <mio dominio>
MAIL FROM: <email-mittente>
RCPT TO: <email-destinatario>
DATA
<Testo email>

.

QUIT

Il comando EHLO o HELO a seconda della configurazione può essere obbligatorio o opzionale. Segue la dichiarazione di dominio, la dichiarazione del mittente e poi del destinatario. con la direttiva DATA inizia il testo del messaggio da spedire, il quale terminerà con la sequenza "riga a capo"+"."+"riga a capo".

Ecco un esempio di transazione SMTP:

220 www.esempio.it ESMTP Postfix
HELO tim.it
250 Hello mydomain.com, pleased to meet you
MAIL FROM: mittente@tim.it
250 mittente@tim.it ... Sender ok
RCPT TO: destinatario@esempio.it
250 destinatario@esempio.it ... Recipient Ok
DATA
354 End data with "." on a line by itself
Subject: messaggio di prova
From: mittente@tim.it
To: destinatario@esempio.it
Ciao,
questa è una prova.
.
250 Ok: queued as 20043
QUIT
221 Bye

Il server prenderà il testo immesso e lo spedirà all'indirizzo da voi inserito. Modificando i vari parametri potrete testare se le regole impostate nel server di posta funzionano correttamente.

Ora vediamo con un semplice schema come funzionano i filtri in sequenza sul server postfix:

Accesso
Filtro accesso per i client SMTP
smtpd_client_restrictions
Protocollo SMTP
Filtro per direttiva HELO
smtpd_helo_restrictions
Filtro per i mittenti (direttiva MAIL FROM)
smtpd_sender_restrictions
Filtro per i destinatari (direttiva RCPT TO)
smtpd_recipient_restrictions
Email
Filtro sull'header della mail

Filtro sul corpo della mail

In breve prima vengono filtrati i client che si collegano al server, i client che passano la prima fase verranno ulteriormente sottoposti al controllo durante la fase di transazione SMPT; se il messaggio passa questa fase verrà controllato in ogni sua parte e se tutto va bene verrà trasferito.

Quali sono i problemi che affliggono un server MTA? beh innanzitutto non vi è una autenticazione, dato che chi vi invia una email non è tenuto a sapere nessuna password, tantomeno se il server è solo un server di passaggio. Inoltre nei vari campi che caratterizzano la transazione SMTP, se non sono presenti filtri, il client può inserire tutti i valori che vuole!
In particolare nella dichiarazione HELO il client dichiara la sua "identità" (il proprio dominio), ma senza alcuna verifica la sua validità lascia molto a desiderare...
La direttiva MAIL FROM dovrebbe contenere l'indirizzo del mittente e non il suo indirizzo ip o il suo dominio e non è da confondere col campo "from:" all'interno della mail. Capite bene che senza protezioni un malintenzionato potrebbe inserire un qualsiasi mittente e scrivere email per conto suo.
La direttiva RCPT TO serve ad indicare il destinatario della mail e anche qua sarebbe opportuno intervenire con delle limitazioni onde evitare problemi di spam. Ad esempio il server di posta di una ditta non dovrebbe in alcun modo permettere la ricezione di email per utenti esterni al proprio dominio o almeno limitarne l'uso.

Nella colonna più a destra della tabella sono elencate le direttive presenti nel file di configurazione del server e che contengono i permessi e le restrizioni delle varie fasi del filtraggio. In teoria sarebbe meglio eliminare la posta indesiderata alla radice quindi dall'accesso del client, ma procedendo in questo modo perderemo delle informazioni su chi e come sta cercando di usare illegalmente il server, quindi a volte si preferisce spostare il filtro sulle ultime parti del processo (smtpd_recipient_restrictions).

Occorre tenere presente che le regole all'interno dei filtri vengono applicate nell'ordine in cui sono state inserite, e la prima che riscontra un confronto positivo esegue l'azione prestabilita. Per questo motivo una regola di permesso generico va posta alla fine e non all'inizio, altrimenti le altre regole non verrebbero neanche prese in considerazione.

Un esempio di restrizioni sul client:

maps_rbl_domains = rbl.maps.vix.com  #alcune liste ora sono a pagamento e altre sono scomparse, quindi occorre cercarsele e provarle
mynetworks = 168.100.189.0/28, 127.0.0.0/8 smtpd_client_restrictions =
 reject_maps_rbl #Rifiuta tutti i client presenti nella black list specificata dalla variabile $maps_rbl_domains
reject_unknown_client
reject_unknown_reverse_client_hostname
permit_mynetworks #Accetta tutti i client specificati dalla variabile $mynetworks
permit

Un altro modo è quello di usare una propria lista si permessi e restrizioni : "check_client_access hash:/etc/postfix/maps/access_client"
Il file access_client conterrà un elenco di regole che determineranno l'accesso o il rifiuto al server:

94.36.206.14 REJECT
82.12.44.3 OK
72.44.31 REJECT
72.44.31.3 OK

Ogni riga è composta da un target e da un'azione, naturalmente per definire un target è possibile usare una "espressione regolare" o un dominio. In particolare possiamo notare che il server rifiuterà la connessione di tutti i client con IP appartenenti alla classe 72.44.31.0/24 tranne 72.44.31.3. Alla fine per compilare il file è necessario usare il comando.

postmap /etc/postfix/maps/access_client

Se provate a connettervi da un client vietato dovrebbe apparire un messaggio di errore di questo tipo:

220 mail.esempio.it ESMTP
helo prova.it
250 mail.esempio.it
mail from: mia@prova.it
250 2.1.0 Ok
rcpt to: utente@esempio.it
554 5.7.1 <dynamic-adsl-94-36-206-14.clienti.tiscali.it[94.36.206.14]>: Client host rejected: Access denied

L'errore viene dato alla fine delle dichiarazioni perché non era stato impostato il parametro:
smtpd_delay_reject = no (di default è "yes")

Per quanto riguarda le restrizioni sulla direttiva HELO prima dovremo attivarla, dato che di default è opzionale:

smtpd_helo_required = yes

Per il resto le restrizioni sono più o meno le stesse che si possono usare negli altri filtri:

smtp_helo_restrictions = 
reject_invalid_hostname
reject_non_fqdn_hostname #Rifiuta un client che non dichiara un Fully Qualified Domain Name
reject_unknown_hostname
permit_naked_ip_address #Permette l'uso di un indirizzo ip racchiuso da parentesi quadre, dato che alcuni client di posta usano questo formato.
permit

anche qui è possibile usare una mappa per filtrare gli accessi come abbiamo fatto precedentemente coi client (check_client_access maptype:mapname e anche check_helo_access maptype:mapname).

Per le restrizioni sul mittente si ripetono le stesse cose, ma ricordatevi ogni volta è possibile utilizzare le restrizioni del filtro precedente, ma non ha molto senso ripeterle dato che una volta rifiutato il client non arriva di certo al filtro successivo.

smtpd_sender_restrictions = 
 reject_unknown_sender_domain
reject_non_fqdn_sender
permit

A questo potremo aggiungere la solita lista di regole:  check_sender_access maptype:mapname .

Infine vediamo le restrizioni che riguardano i destinatari, che saranno anche quelle più numerose per via dei motivi spiegati precedentemente.

smtpd_recipient_restrictions = 
permit_mynetworks
permit_sasl_authenticated
reject_unauth_pipelining
reject_unauth_destination
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_rbl_client blackholes.easynet.nl
reject_rbl_client cbl.abuseat.org
reject_rbl_client proxies.blackholes.wirehub.net
reject_rbl_client bl.spamcop.net
reject_rbl_client sbl.spamhaus.org
reject_rbl_client opm.blitzed.org
reject_rbl_client dnsbl.njabl.org
reject_rbl_client list.dsbl.org
reject_rbl_client multihop.dsbl.org
permit

Come nei casi precedenti potremo inserire "check_recipient_access hash:/etc/postfix/maps/access_recipient" per controllare dettagliatamente i destinatari.
La novità è l'aiuto esterno che viene richiesto con le direttive reject_rbl_client , reject_rhsbl_sender e reject_rhsbl_client. In questo modo vengono verificati gli indirizzi dei mittenti o dei destinatari tramite delle black list esterne al server.
Le RBL (Real-time, IP Based Blacklist filtration) contengono gli IP di usati spesso dagli spammers, mentre le
RHSBL (Real-time, Domain Based Blacklist filtration) contengono i domini da cui spesso provengono gli attacchi. In questo modo noi deleghiamo il compito di giudicare se un IP o un dominio è da filtrare o meno a server esterni e quindi in qualche modo ci affidiamo a loro.
Dato che alcuni domini appartengono a degli internet server provider solitamente il filtro RHSBL risulta essere molto restrittivo e quindi io sconsiglierei di usarlo, dato che per colpa di qualche persona verrebbe filtrati tutti gli utenti connessi.

Filtro sul Header e sul Body
Questo filtro entra in funzione solo se tutti gli altri di cui abbiamo già parlato hanno dato esito negativo.

Header Checks
come prima cosa dovremo abilitarlo in configurazione e per fare questo dovremo indicare dove si trova il file con le regole da applicare:

header_checks = regexp:/etc/postfix/maps/header_checks
mime_header_checks = regexp:/etc/postfix/maps/mime_header_checks

Il formato di ogni linea (regole) nel file "header_checks" è il seguente:

/^HEADER: .*content_to_act_on/ ACTION

Gli HEADER elencati possono essere molto vari, ma alcune parole chiave risultano essere abbastanza consuete, per esempio:

/^Subject: .*Sesso Gratis!/ REJECT

Filtro Mime Header
Nel mime_header_checks file si possono elencare tutte le regole riguardanti le estensioni dei file che vogliamo bloccare, esempio:

/name=[^>]*\.(bat|com|exe|dll)/ REJECT

In questo modo verranno respinti tutti i messaggi con degli allegati che terminano con .bat, .com, .exe or .dll.

Filtro Body
Anche questa volta il filtro verrà abilitato inserendo il percorso del file contenente le regole da applicare al corpo del messaggio.

body_checks = regexp:/etc/postfix/maps/body_checks

Formato di regola all'interno del file "body_checks":

/content_to_act_on/ ACTION



Ultimo aggiornamento ( Martedì 30 Agosto 2011 13:41 )  
Loading

Login