Capitolo 11. Servizi di rete: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

I servizi di rete sono i programmi con cui gli utenti interagiscono direttamente durante le loro attività quotidiane. Essi sono la punta dell'iceberg del sistema informativo ed in questo capitolo ci concentreremo su di loro; le componenti invisibili a cui si affidano sono l'infrastruttura che abbiamo descritto precedentemente. Di solito richiedono la tecnologia di crittografia descritta in Sezione 10.2, «X.509 certificates».

11.1. Server di posta

Gli amministratori della Falcot Corporation hanno scelto Postfix come loro server di posta elettronica per via della sua affidabilità e per la semplicità di configurazione. Allo stesso modo il suo design assicura che ogni operazione sia eseguita in un processo con l'insieme minimo di permessi richiesti, cosa che garantisce una misura ottimale contro i problemi di sicurezza.

ALTERNATIVA Il server Exim4

Debian utilizza Exim4 come server di posta predefinito (per questo l'installazione iniziale include Exim4). La configurazione è fornita da un pacchetto separato, exim4-config, e viene automaticamente personalizzata in base alle risposte fornite ad un insieme di quesiti posti da Debconf in modo molto simile a come avviene con le domande poste dal pacchetto postfix.

La configurazione può essere in un singolo file (/etc/exim4/exim4.conf.template) oppure suddivisa in parti all'interno della cartella /etc/exim4/conf.d/. In entrambi i casi, i file non sono utilizzati da update-exim4.conf come modelli per la generazione di /var/lib/exim4/config.autogenerated. Quest'ultimo è utilizzato da Exim4. Grazie a questo meccanismo, i valori ottenuti attraverso la configurazione debconf di Exim — che sono memorizzati in /etc/exim4/update-exim4.conf.conf — possono essere inseriti nel file di configurazione di Exim anche quando l'amministratore oppure un'altro pacchetto hanno cambiato la configurazione predefinita di Exim.

La sintassi dei file di configurazione di Exim4 ha le sue peculiarità e la sua curva di apprendimento. Una volta comprese queste peculiarità Exim4 è un server di posta veramente completo e potente come testimoniano le decine di pagine di documentazione.

→ https://www.exim.org/docs.html

11.1.1. Installare Postfix

Il pacchetto postfix include il demone SMTP principale. Altri pacchetti (come postfix-ldap e postfix-pgsql) aggiungono funzionalità addizionali a Postfix, incluso l'accesso ai database di mappatura. Dovrebbero essere installati solo se si ritiene di averne bisogno.

Saranno posti diversi quesiti Defconf durante l'installazione del pacchetto. Le risposte consentono di generare una prima versione del file di configurazione /etc/postfix/main.cf.

La prima domanda riguarda la tipologia di configurazione. Solo due delle risposte proposte sono rilevanti nel caso in cui il server sia connesso ad Internet: «Sito internet» e «Sito internet con smarthost». La prima opzione è appropriata per un server che riceve la posta in arrivo ed invia le email in uscita direttamente ai rispettivi destinatari: pertanto si adatta bene al caso della Falcot Corporation. La seconda opzione è appropriata per un server che riceve le email in arrivo normalmente ma che invia le email in uscita attraverso un server SMTP intermedio, lo «smarthost», anziché consegnarle direttamente al server del destinatario. Questo è particolarmente utile per chi ha con un indirizzo IP dinamico poiché molti server di posta rifiutano i messaggi che arrivano direttamente da questo tipo di indirizzo. In questo caso lo smarthost sarà generalmente il server SMTP dell'ISP che a sua volta è configurato per accettare ed inoltrare in modo appropriato le email provenienti dai clienti. Questo tipo di configurazione (con smarthost) è rilevante anche per i server che non sono costantemente connessi ad internet poiché evita di dover gestire una coda di messaggi non consegnabili da dover riprovare a inviare in seguito.

La seconda domanda riguarda il nome completo della macchina, utilizzato per generare gli indirizzi email a partire dal nome utente locale. Il nome completo della macchina appare dopo la chiocciola («@»). Nel caso della Falcot, la risposta dovrebbe essere mail.falcot.com. Questa è l'unica domanda posta in via predefinita tuttavia la configurazione a cui porta non è sufficientemente completa per le necessità della Falcot: per questo motivo gli amministratori eseguono dpkg-reconfigure postfix per poter personalizzare altri parametri.

Una delle domande addizionali chiede tutti i nomi di dominio relativi alla macchina. La lista predefinita include il suo nome completo oltre ad alcuni sinonimi per localhost, ma il dominio principale falcot.com dev'essere aggiunto manualmente. Più generalmente, bisognerebbe rispondere a questa domanda con tutti i nomi di dominio per i quali la macchina agirà come server MX; in altre parole‍, tutti i nomi a dominio per cui il DNS dice che questa macchina accetterà email. Questa informazione finisce nella variabile mydestination del file di configurazione principale di Postfix, /etc/postfix/main.cf.

Figura 11.1. Ruolo del record MX nel DNS durante l'invio di un'email

In alcuni casi l'installazione può anche chiedere quali reti devono essere autorizzate ad inviare email attraverso la macchina. Nella sua configurazione predefinita Postfix accetta unicamente email provenienti dalla macchina che lo ospita; la rete locale viene generalmente aggiunta. Gli amministratori della Falcot Corporation hanno aggiunto 192.168.0.0/16 alla risposta predefinita. Se la domanda non è posta, la relativa variabile nel file di configurazione è mynetworks come si vede nell'esempio qui sotto.

Le email locali possono anche essere consegnate con procmail. Questo strumento consente agli utenti di elaborare le loro email in arrivo attraverso le regole presenti nel file ~/.procmailrc. Sia Postfix che Exim4 suggeriscono procmail per impostazione predefinita, ma ci sono alternative come maildrop od i filtri Sieve.

Dopo questa prima fase gli amministratori dispongono del file di configurazione seguente; sarà utilizzato come punto di partenza per aggiungere alcune funzionalità addizionali nelle prossime sezioni.

Esempio 11.1. File /etc/postfix/main.cf iniziale

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

SICUREZZA Certificati SSL Snake oil

I certificati snake oil, come le "medicine" snake oil vendute da antichi ciarlatani, non hanno alcun valore: non si può fare affidamento su di loro per autenticare il server poiché sono generati automaticamente da certificati auto-firmati. Tuttavia, sono utili per migliorare la privacy degli scambi.

In generale dovrebbero essere usati solo per scopi di test, e il servizio normale deve usare certificati reali. L'iniziativa Let's encrypt offre certificati SSL/TLS gratuiti e affidabili, che possono essere generati utilizzando il pacchetto certbot come descritto in Sezione 11.2.2, «Adding support for SSL» ed utilizzati in postfix come questo:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in Sezione 10.2.2, «Infrastruttura a chiave pubblica: easy-rsa».

11.1.2. Configurare i domini virtuali

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

11.1.2.1. Domini virtuali alias

Un dominio virtuale alias contiene solo indirizzi alias, cioè indirizzi che si occupano di inoltrare le email ad altri indirizzi.

Questo tipo di dominio sarà abilitato aggiungendo il suo nome alla variabile virtual_alias_domains ed indicando un file di mappatura indirizzi nella variabile virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Il file /etc/postfix/virtual descrive le mappature con una sintassi piuttosto lineare: ogni riga contiene due campi separati da uno spazio; il primo campo è il nome dell'alias, il secondo campo è una lista di indirizzi email a cui reindirizza. La sintassi speciale @domain.com copre tutti i restanti alias di un dominio.

[email protected]  [email protected]
[email protected]    [email protected], [email protected]
# L'alias qui sotto è generico e copre tutti gli indirizzi all'interno 
# del dominio flacotsbrand.com che non sono altrimenti coperti in questo file.
# Questi indirizzi inoltrano le email allo stesso utente nel
# dominio falcot.com.
@falcotsbrand.com           @falcot.com

Dopo aver cambiato /etc/postfix/virtual la tabella postfix /etc/postfix/virtual.db deve essere aggiornata eseguendo sudo postmap /etc/postfix/virtual.

11.1.2.2. Caselle di posta su domini virtuali

I messaggi indirizzati ad una casella su di un dominio virtuale sono conservati in caselle di posta non assegnate ad un utente locale del sistema.

Abilitare una casella di posta in un dominio virtuale richiede di inserire il dominio nella variabile virtual_mailbox_domains fornendo un file di mappatura caselle in virtual_mailbox_maps. Il parametro virtual_mailbox_base contiene la directory dove le caselle di posta saranno conservate.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

I parametri virtual_uid_maps e virtual_gid_maps forniscono le mappature tra un indirizzo email e l'utente di sistema (o gruppo rispettivamente) che "possiede" la casella di posta corrispondente. Per assegnare tutte le caselle di posta allo stesso proprietario/gruppo la sintassi è static:5000.

Ancora una volta, la sintassi del file /etc/postfix/vmailbox è piuttosto lineare: due campi separati da uno spazio. Il primo campo è un indirizzo email all'interno di uno dei domini virtuali e il secondo campo è la posizione della casella di posta associata (relativamente alla directory specificata in virtual_mailbox_base). Se il nome della casella di posta termina con una barra (/) le email saranno conservate nel formato maildir, diversamente sarà utilizzato il formato tradizionale mbox. Il formato di maildir utilizza l'intera directory per conservare una casella di posta: ogni messaggio sarà conservato in un file separato. Diversamente, nel formato mbox, l'intera casella di posta elettronica è conservata in un file ed ogni riga che comincia con «From » (From seguito da uno spazio) segnala l'inizio di un nuovo messaggio.

# La posta di Jean è conservata come maildir, con
# un file per email in una directory dedicata
[email protected] falcot.org/jean/
# La posta di Sophie è conservata in un tradizionale file «mbox»,
# dove tutte le email sono concatenate in un unico file
[email protected] falcot.org/sophie

11.1.3. Restrizioni per ricezione ed invio

Il crescente numero di email massive non richieste (spam) richiede di essere sempre più rigorosi quando si stabilisce quali email devono essere accettate da un server. Questa sezione presenta alcune tra le strategie incluse in Postfix.

Se le regole di rifiuto sono troppo rigide, può succedere che anche il traffico legittimo di email venga bloccato. È quindi una buona abitudine testare le restrizioni e prevenire il rifiuto permanente delle richieste durante questo periodo usando la direttiva soft_bounce = yes. Facendo precedere una direttiva di tipo reject da warn_if_reject verrà registrato solo un messaggio di log invece di rifiutare la richiesta.

CULTURA Il problema dello spam

"Spam" è un termine generico utilizzato per indicare tutte le email commerciali non richieste (note anche come UCE) che inondano le nostre caselle di posta elettronica; gli individui senza scrupoli che le inviano sono definiti spammer. Costoro si preoccupano poco del disturbo che causano perché inviare email costa poco e basta che una piccola percentuale di destinatari sia attratta dalle loro offerte perché l'operazione di spam produca più denaro di quanto sia costata. Il processo è quasi completamente automatizzato e qualsiasi indirizzo email reso pubblico (per esempio in un forum, negli archivi di una mailing list, in un blog, ecc.) sarà probabilmente individuato dai robot degli spammer e sottoposto ad un flusso infinito di messaggi non richiesti. Anche ogni contatto trovato in un sistema compromesso viene preso di mira.

Tutti gli amministratori di sistema tentano di affrontare questo disturbo con i filtri anti-spam, ma naturalmente gli spammer continuano a lavorare per aggirare questi filtri. Alcuni di loro prendono persino in affitto da varie organizzazioni criminali reti di macchine compromesse da worm. Recenti statistiche stimano che fino al 95% delle email in circolazione su Internet sono spam!

11.1.3.1. Restrizioni d'accesso basate su IP

La direttiva smtpd_client_restrictions controlla quali macchine sono autorizzate a comunicare con il server di posta.

Quando una variabile contiene una lista di regole, come nell'esempio qui sotto, queste regole sono valutate in ordine, dalla prima all'ultima. Ogni regola può accettare il messaggio, rifiutarlo o lasciare la decisione alla regola seguente. Come conseguenza l'ordine è importante ed invertire due regole può causare un comportamento molto diverso.

Esempio 11.2. Restrizioni basate sull'indirizzo del client

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net

La direttiva permit_mynetworks usata come prima regola, accetta tutte le email provenienti da una macchina nella rete locale (così come definita nella variabile di configurazione mynetworks).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

SUGGERIMENTO Tabelle di accesso

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

La tabella /etc/postfix/access_clientip elenca gli indirizzi IP e le reti; /etc/postfix/access_helo elenca i nomi di dominio; /etc/postfix/access_sender contiene gli indirizzi email dei mittenti. Tutti questi file necessitano di essere trasformati in tabelle-hash (un formato ottimizzato per l'accesso veloce) dopo ogni modifica, con il comando sudo postmap /etc/postfix/file.

The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.

Le ultime quattro regole rifiutano ogni messaggio proveniente da un server elencato in una delle blacklist indicate. RBL è l'acronimo di Remote Black List, e RHSBL sta per Right-Hand Side Black List. La differenza è che la prima elenca gli indirizzi IP, mentre la seconda elenca i nomi di dominio. Ci sono diversi servizi di questo tipo. Essi elencano domini ed indirizzi IP con una cattiva reputazione, server mal configurati che gli spammer utilizzano per inoltrare le loro email, così come macchine infettate da worm o virus usate per inoltrare la posta elettronica.

11.1.3.2. Controllare la validità dei comandi `EHLO` o `HELO`

Ogni comunicazione SMTP inizia con un comando HELO (o EHLO), seguito dal nome del server di posta elettronica di invio. Controllare la validità di questo nome può essere interessante. Per far rispettare pienamente le restrizioni elencate in smtpd_helo_restrictions dev'essere abilitata l'opzione smtpd_helo_required. In caso contrario i client potrebbero saltare le restrizioni non inviando alcun comando HELO/EHLO.

Esempio 11.3. Restrizioni sul nome annunciato in EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org

La prima direttiva permit_mynetworks consente a tutte le macchine nella rete locale di presentarsi liberamente. Questo è importante poiché molti programmi di posta non rispettano in modo adeguato questa parte del protocollo SMTP e possono presentarsi con nomi senza senso.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.

Utilizzare permit_mynetworks come prima regola ha un interessante effetto collaterale: le regole seguenti si applicano unicamente agli host fuori dalla rete locale. Questo consente di inserire in blacklist tutti gli host che si presentano come parte della rete di falcot.com, per esempio aggiungendo la riga falcot.com REJECT Non sei nella nostra rete! al file /etc/postfix/access_helo.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Ogni messaggio ha un mittente annunciato dal comando MAIL FROM del protocollo SMTP. Ancora una volta questa informazione può essere verificata in diversi modi.

Esempio 11.4. Controlli sul mittente

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net

La tabella /etc/postfix/access_sender mappa alcuni trattamenti speciali riservati ad alcuni mittenti. Generalmente questo significa elencare alcuni mittenti in una whitelist oppure in una blacklist.

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from [email protected] are only accepted if such an address really exists.

Per concludere, la regola reject_non_fqdn_sender rifiuta le email che si presume provengano da un indirizzo senza un nome di dominio pienamente qualificato. In pratica questo significa rifiutare email provenienti da utente@macchina: l'indirizzo dev'essere annunciato come [email protected] o [email protected].

La regola reject_rhsbl_sender rifiuta i mittenti basandosi su un servizio RHSBL (basato sul dominio).

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Ogni email ha almeno un destinatario, annunciato con il comando RCPT TO del protocollo SMTP. Anche questi indirizzi concorrono alla validazione del messaggio, tuttavia sono meno rilevanti rispetto ai controlli effettuati sull'indirizzo del mittente.

Esempio 11.5. Controlli sul destinatario

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

reject_unauth_destination è la regola base che richiede ai messaggi provenienti dall'esterno di essere indirizzati ai noi: messaggi inviati ad indirizzi non gestiti da questo server saranno rifiutati. Senza questa regola un server diviene un open relay che permette agli spammer di inviare posta non richiesta; questa regola è quindi caldamente raccomandata, e dovrebbe essere posizionata preferibilmente vicino all'inizio della lista, per evitare che altre regole possano autorizzare l'inoltro del messaggio prima che la sua destinazione sia stata controllata.

La regola reject_unlisted_recipient rifiuta ragionevolmente i messaggi inviati a utenti locali che non esistono. Infine reject_non_fqdn_recipient rifiuta gli indirizzi non completamente qualificati: questo rende impossibile l'invio di email a jean o jean@macchina e richiede invece l'uso dell'indirizzo completo come [email protected] o [email protected].

La direttiva permit non è strettamente necessaria. Tuttavia, può essere utile alla fine di una lista di restrizioni per rendere esplicita la politica predefinita.

11.1.3.5. Restrizioni associate con il comando `DATA`

Il comando DATA di SMTP è emesso prima dei contenuti del messaggio. Non fornisce alcuna informazione di per sé, a parte l'annunciare quello che viene immediatamente dopo. Tuttavia può a sua volta essere soggetto a controlli.

Esempio 11.6. Controlli su DATA

smtpd_data_restrictions = reject_unauth_pipelining

La direttiva reject_unauth_pipelining fa sì che il messaggio sia rifiutato se il mittente invia un comando prima che sia inviata una risposta al comando inviato in precedenza. Questo protegge da una ottimizzazione comunemente utilizzata dagli spammer automatizzati poiché a loro non importa un fico secco delle risposte e si concentrano unicamente nell'invio del maggior numero di email nel minor tempo possibile.

11.1.3.6. Applicare restrizioni

Nonostante i comandi precedenti verificano informazioni nelle varie fasi dello scambio SMTP, Postfix, di default, invia l'effettivo rifiuto a seguito del comando RCPT TO.

Questo significa che anche se il messaggio viene rifiutato a causa di un comando EHLO non valido, Postfix conosce il mittente ed il destinatario quando annuncia il rifiuto e pertanto potrà poi inserire nel log un messaggio più esplicito di quanto avesse potuto fare nel caso la transazione si fosse interrotta all'inizio. Inoltre un certo numero di client SMTP non si attende problemi durante i primi comandi SMTP e questi client saranno meno disturbati da questo rifiuto posticipato.

Il vantaggio finale di questa scelta è di permettere alle regole di accumulare informazioni durante i vari passaggi dello scambio di SMTP; questo consente di definire permessi più dettagliati, come rifiutare una connessione non locale se si annuncia con un mittente locale.

Il comportamento predefinito è controllato dalla regola smtpd_delay_reject.

11.1.3.7. Filtrare in base al contenuto del messaggio

La validazione ed il sistema di restrizioni non sarebbero completi senza un modo per applicare controlli al contenuto dei messaggi. Postfix distingue tra i controlli applicati all'intestazione e quelli applicati al corpo del messaggio.

Esempio 11.7. Abilitare filtri basati sul contenuto

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Entrambi i file contengono una lista di espressioni regolari (spesso chiamate regexp o regex) e relative azioni da intraprendere quando l'intestazione (o il corpo) delle email corrisponde con l'espressione.

Esempio 11.8. File d'esempio /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT Io combatto lo spam (GOTO Sarbacane)
/^Subject: *La tua email contiene dei VIRUS/ DISCARD notifica di virus

FONDAMENTALI Espressioni regolari

Il termine espressione regolare (abbreviato con regexp o regex) fa riferimento ad una notazione generica per esprimere la descrizione dei contenuti e/o la struttura di una stringa di caratteri. Alcuni caratteri speciali permettono di definire alternative (per esempio pippo|pluto corrisponde sia con "pippo" che con "pluto"), insiemi di caratteri permessi (per esempio [0-9] significa "qualsiasi numero" e . — un punto — significa "qualsiasi carattere"), quantità (s? corrisponde a s o ad una stringa vuota, ovvero 0 oppure 1 occorrenza di s; s+ corrisponde ad una o più occorrenze consecutive del carattere s; e così via). Le parentesi permettono di raggruppare i risultati della ricerca.

La precisa sintassi di queste espressioni varia tra i vari strumenti che le utilizzano ma le funzionalità base sono similari.

→ http://it.wikipedia.org/wiki/Espressione_regolare

La prima controlla l'intestazione che fa riferimento al software email; se viene individuato GOTO Sarbacane (un software per l'invio massivo di email) il messaggio viene rifiutato. La seconda espressione controlla l'oggetto del messaggio: se indica la notifica di un virus possiamo decidere di non respingere il messaggio ma di limitarci a scartarlo immediatamente.

Utilizzare questi filtri è un'arma a doppio taglio poiché è facile produrre regole troppo generiche e perdere di conseguenza email legittime. In questi casi i messaggi vanno perduti ed inoltre i rispettivi mittenti ricevono messaggi d'errore non desiderati (e fastidiosi).

11.1.4. Impostare il greylisting

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.

Postfix non fornisce il greylisting nativamente ma esiste una funzionalità che permette di delegare la decisione riguardo il rifiuto o l'accettazione di un messaggio ad un programma esterno. Il pacchetto postgrey contiene proprio un programma di questo tipo, progettato per interfacciarsi con questo servizio per la delega delle politiche di accesso.

Una volta installato, postgrey si attiva come demone e si pone in ascolto sulla porta 10023. Postfix può quindi essere configurato per utilizzarlo, aggiungendo il parametro check_policy_service come restrizione aggiuntiva:

smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

Il principale svantaggio del greylisting è dato dal ritardo causato ai messaggi legittimi, cosa che non è sempre accettabile. Inoltre incrementa il carico sui server che inviano molte email legittime.

IN PRATICA Aspetti negativi del greylisting

Teoricamente il greylisting dovrebbe unicamente ritardare la ricezione della prima email da un dato mittente ad un dato destinatario e tipicamente questo ritardo si misura nell'ordine dei minuti. La realtà, purtroppo, può essere leggermente diversa. Alcuni grandi provider utilizzano cluster di server SMTP e quando un messaggio viene inizialmente rifiutato il server che riprova la trasmissione potrebbe non essere lo stesso. Quando ciò accade il secondo server ottiene un ulteriore messaggio d'errore temporaneo dovuto al greylisting e così via: in questi casi possono passare anche diverse ore prima che la trasmissione sia rieseguita da un server già coinvolto poiché normalmente i server SMTP incrementano gli intervalli tra un tentativo e l'altro dopo ogni fallimento.

Di conseguenza l'indirizzo IP di provenienza può variare nel tempo anche per un singolo mittente. Inoltre anche l'indirizzo email del mittente può cambiare. Per esempio molti server di mailing-list possono includere informazioni extra nell'indirizzo email del mittente per essere in grado di gestire i messaggi d'errore (spesso indicati anche con il termine bounce). Ad ogni nuovo messaggio inviato ad una mailing-list potrebbe essere richiesto di attraversare il greylisting cosa che richiede di essere conservato (temporaneamente) nel server del mittente. Questo può diventare presto un problema per le mailing-list molto frequentate (con decine di migliaia di iscritti).

Per mitigare questi effetti negativi, Postgrey gestisce una whitelist di siti, ed i messaggi da loro originati vengono immediatamente accettati senza passare attraverso il greylisting. Questa lista può essere facilmente adattata in base alle necessità locali, visto che è conservata nel file /etc/postgrey/whitelist_clients.

APPROFONDIMENTO Greylisting selettivo con milter-greylist

Gli effetti negativi del greylisting possono essere mitigati applicando il greylisting unicamente ad un sottoinsieme di client che sono già considerati come probabile sorgente di spam (poiché sono inseriti in una blacklist DNS). Questo non è possibile con postgrey ma milter-greylist può essere usato in questo modo.

In tal scenario, poichè le blacklist DNS non innescano mai un rifiuto definitivo, diventa ragionevole l'uso di blacklist aggressive, comprese quelle che includono tutti gli indirizzi IP dinamici assegnati dai Provider ai loro clienti (come pbl.spamhaus.org o dul.dnsbl.sorbs.net).

Poichè milter-greylist usa l'intrefaccia milter di Sendmail, il lato postix della sua configurazione è limitato a “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. La pagina del manuale greylist.conf(5) documenta /etc/milter-greylist/greylist.conf ed i numerosi modi di configurare milter-greylist. Inoltre sarà necessario modificare il file /etc/default/milter-greylist per consentire effettivamente il servizio.

11.1.5. Personalizzare i filtri in base al destinatario

La Sezione 11.1.3, «Restrizioni per ricezione ed invio» e la Sezione 11.1.4, «Impostare il greylisting» riportano molte delle possibili limitazioni. Tutte hanno un loro metodo per diminuire la quantità di spam ricevuto ma tutte hanno effetti collaterali. Quindi è sempre più comune personalizzare l'insieme di filtri in base al destinatario. Alla Falcot Corporation il greylisting è utile per la maggior parte degli utenti, ma ostacola l'attività di alcuni utenti che necessitano di una bassa latenza per le proprie email (come il servizio di supporto tecnico). Allo stesso modo il servizio di supporto commerciale incontra a volte delle difficoltà nella ricezione di email da alcuni provider asiatici che sono inseriti nelle blacklist: il servizio di supporto commerciale ha quindi richiesto un indirizzo email non filtrato per poter comunicare.

Postfix fornisce la personalizzazione sui filtri tramite il concetto di «restrizione di classe». Le classi sono dichiarate nel parametro smtpd_restriction_classes e sono definite come in smtpd_recipient_restrictions. La direttiva check_recipient_access definisce quindi una tabella che associa un destinatario ad un insieme appropriato di restrizioni.

Esempio 11.9. Definire classi di restrizione in main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Esempio 11.10. Il file /etc/postfix/recipient_access

# Indirizzi non filtrati
[email protected]  permissiva
[email protected]     permissiva
[email protected]  permissiva

# Filtraggio aggressivo per alcuni utenti privilegiati
[email protected]         aggressiva

# Una regola speciale per il manager della mailing-list
[email protected]       reject_unverified_sender

# Greylisting predefinito
falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SICUREZZA Discussione controversa sul software antivirus

L'uso di scanner antivirus, il cosiddetto software antivirus, è controverso. Di solito c'è un divario tra il rilascio di qualche malware e l'aggiunta di regole di rilevamento al database antivirus. Durante questa lacuna, non esiste una protezione basata sul software. Inoltre, l'utilizzo richiede spesso di eseguire software aggiuntivo, ad esempio per decomprimere gli archivi e scansionare tutti i tipi di eseguibili, il che aumenta drasticamente il potenziale sfruttamento del software antivirus stesso. L'utilizzo di tali soluzioni software non può quindi mai sostituire campagne di sensibilizzazione e semplici regole comportamentali (non aprire mai allegati inviati non richiesti, ecc.).

The Falcot administrators selected clamav from the homonymous package.

Il compito di interfacciare l'antivirus ed il server di posta è affidato a clamav-milter. Un milter (abbreviazione dell'inglese mail filter) è un programma di filtraggio realizzato appositamente per interfacciarsi con i server di posta. Un milter utilizza un'interfaccia di programmazione standard (API) che fornisce prestazioni nettamente migliori rispetto ai filtri esterni ai server di posta. I milter sono stati introdotti inizialmente da Sendmail e Postfix ha presto seguito l'esempio.

Una volta che il pacchetto clamav-milter è installato, il milter deve essere riconfigurato per l'esecuzione su una porta TCP piuttosto che sul socket predefinito. Ciò può essere ottenuto con dpkg-reconfigure clamav-milter. Quando viene richiesta "L'interfaccia di comunicazione con Sendmail", verrà risposto “inet:[email protected]”.

La configurazione standard di ClamAV è adeguata per molte situazioni, ma alcuni parametri importanti possono comunque essere personalizzati con dpkg-reconfigure clamav-base.

Come ultimo passo è necessario istruire Postfix affinché utilizzi i filtri appena configurati. Per farlo è sufficiente aggiungere la seguente direttiva a /etc/postfix/main.cf:

# Controllo virus con clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

Se l'antivirus causa problemi, questa riga può essere commentata, e dev'essere eseguito systemctl reload postfix perché la modifica sia applicata.

IN PRATICA Verificare l'antivirus

Un volta configurato l'antivirus, è necessario verificare il suo corretto funzionamento. Il metodo più veloce per farlo è inviare un'email di prova con un allegato contenente il file eicar.com (o eicar.com.zip), che può essere scaricato online:

→ https://2016.eicar.org/86-0-Intended-use.html

Questo file non è un vero virus ma un file di test che tutti i software antivirus sul mercato riconoscono come un virus per consentire la verifica delle installazioni.

Tutti i messaggi gestiti da Postfix passano ora attraverso il filtro antivirus.

11.1.7. Combattere lo spam con SPF, DKIM e DMARC

L'elevato numero di email non richieste inviate ogni giorno ha portato alla creazione di diversi standard, che mirano a convalidare che l'host di invio di un'email è autorizzato e che l'email non è stata manomessa. I seguenti sistemi sono tutti basati su DNS e richiedono, per il dominio in questione, che gli amministratori abbiano il controllo sia sul server di posta che sul DNS.

ATTENZIONE Discussione controversa

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrazione del Sender Policy Framework (SPF)

Il Sender Policy Framework (SPF) è utilizzato per convalidare se un certo server di posta è autorizzato ad inviare email per un determinato dominio. È per lo più configurato attraverso il DNS. La sintassi della voce (record) da inserire è spiegata in dettaglio su:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all

Diamo un'occhiata veloce alla voce falcot.org.

# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Esso afferma che l'IP del mittente deve corrispondere al record A per il dominio di invio, o deve essere elencato come uno dei Mail Exchange Resource Records per il dominio corrente, o deve essere uno dei tre indirizzi IP4 menzionati. Tutti gli altri host devono essere contrassegnati come non autorizzati ad inviare email per il dominio mittente. Quest'ultimo è chiamato "soft fail" e, di conseguenza, ha lo scopo di contrassegnare l'email, ma di accettarla comunque.

Il server di posta postfix può controllare il record SPF per le email in arrivo usando il pacchetto postfix-policyd-spf-python, un agente di policy scritto in Python. Il file /usr/share/doc/postfix-policyd-spf-python/README.Debian descrive i passi necessari per integrare l'agente in postfix, quindi non li ripeteremo qui.

La configurazione è definita nel file /etc/postfix-policyd-spf-python/policyd-spf.conf, che è completamente documentato in policyd-spf.conf(5) e /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. I principali parametri di configurazione sono HELO_reject e Mail_From_reject, che configurano se le email devono essere rifiutate (Fail) o accettate inserendo nell'intestazione (False), se i controlli falliscono. Quest'ultimo è spesso utile, quando il messaggio viene ulteriormente elaborato da un filtro antispam.

Se il risultato dovrà essere usato da opendmarc (Sezione 11.1.7.3, «Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)»), allora Header_Type dev'essere impostato su AR.

Da notare che spamassassin contiene un plugin per controllare il record SPF.

11.1.7.2. Integrazione della firma e del controllo DKIM (DomainKeys)

Il Domain Keys Identified Mail (DKIM) è un sistema, standard, di autenticazione del mittente. L'agente di trasporto della posta, qui postfix, aggiunge nell'intestazione delle email in uscita una firma digitale associata al nome del dominio. La parte ricevente può convalidare il corpo del messaggio e i campi dell'intestazione controllando la firma con una chiave pubblica che viene recuperata dai record DNS del mittente.

→ http://dkim.org/

Gli strumenti necessari sono forniti dai pacchetti opendkim e opendkim-tools.

Per prima cosa dev'essere creata la chiave privata usando il comando opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR dev'essere un nome univoco per la chiave. Può essere semplice come "mail" o la data di creazione, se hai intenzione di ruotare le chiavi.

Esempio 11.11. Creare una chiave privata per firmare le e-mail da falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*

Questo creerà i file /etc/dkimkeys/mail.private e /etc/dkimkeys/mail.txt ed imposterà il corretto proprietario. Il primo file contiene la chiave privata, il secondo la chiave pubblica che dev'essere aggiunta al DNS:

Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("q").

[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

Le seguenti direttive nel file /etc/postfix/main.cf consentono a postfix l'uso del filtro:

milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected];"

Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. SMTP autenticato

Per poter inviare email è necessario un server SMTP che sia raggiungibile; ed inoltre è necessario dire al server SMTP di inviare email attraverso di esso. Per gli utenti in movimento, questo potrebbe dire di dover cambiare regolarmente la configurazione dei propri client SMTP, dato che il server SMTP della Falcot rifiuta i messaggi provenienti da indirizzi IP apparentemente non correlati con l'azienda. Esistono due soluzioni a questo problema: l'utente in movimento può installare un server SMTP sul proprio computer oppure continuare ad utilizzare il server aziendale con qualche tipo di autenticazione che lo riconosca come dipendente. La prima soluzione non è raccomandata dato che il computer non sarà connesso permanentemente e non sarà quindi in grado di ritentare l'invio dei messaggi in caso di problemi: ci concentreremo quindi sulla seconda soluzione.

L'autenticazione SMTP con Postfix fa affidamento su SASL (Simple Authentication and Security Layer). Richiede l'installazione dei pacchetti libsasl2-modules e sasl2-bin e la registrazione di una password nel database SASL per ogni utente che necessita di autenticarsi sul server SMTP. Questo è realizzabile per mezzo del comando saslpasswd2 che accetta diversi parametri. L'opzione -u definisce il dominio di autenticazione e deve corrispondere al parametro smtpd_sasl_local_domain nella configurazione di Postfix. L'opzione -c consente di creare un utente e -f permette di specificare il file da usare se il database SASL necessita di essere conservato in una posizione diversa da quella predefinita (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]

Notare che il database di SASL viene creato nella directory di Postfix. Per assicurare la coerenza modifichiamo /etc/sasldb2 in un collegamento simbolico che punta al database utilizzato da Postfix con il comando ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

A questo punto è necessario configurare Postfix affinché utilizzi SASL. Prima di tutto l'utente postfix dev'essere aggiunto al gruppo sasl così che possa accedere al database degli account SASL. Alcuni nuovi parametri sono inoltre necessari per abilitare SASL e il parametro smtpd_recipient_restrictions dev'essere configurato per consentire ai client autenticati da SASL di inviare email liberamente.

Esempio 11.12. Abilitare SASL nel file /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

EXTRA Client SMTP autenticati

La maggior parte dei client email sono in grado di autenticarsi presso un server SMTP prima di inviare i messaggi in uscita e per utilizzare questa funzionalità basta semplicemente configurare i parametri appropriati. Se il client in uso non fornisce questa funzionalità è possibile utilizzare un server Postfix locale e configurarlo per inoltrare le email attraverso il server SMTP remoto. In questo caso, il Postfix locale diventerà a sua volta il client che andrà ad autenticarsi con SASL. I parametri richiesti sono i seguenti:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

Il file /etc/postfix/sasl_passwd deve contenere il nome utente e la password da utilizzare per autenticarsi sul server mail.falcot.com. Ecco un esempio:

[mail.falcot.com]   joe:LyinIsji

Così come per tutte le mappe Postfix questo file dev'essere trasformato in /etc/postfix/sasl_passwd.db con l'impiego del comando postmap.