Mail in SPAM? Facciamo chiarezza

Spam

Quante volte ci è capitato di trovarci le mail di un sito nella cartella spam?

Al sottoscritto molte, moltissime volte!
Con questo articolo vi spiegherò come prendere una serie di accorgimenti per rendere le mail dei vostri siti, più presentabili agli occhi degli anti spam.

Premessa

Di seguito avrai modo di leggere degli esempi ma ci tengo a ricordati che non esiste una versione giusta o sbagliata, bensì ci saranno configurazioni più o meno adatte alle tue esigenze.
Tutto ciò servirà per farti prendere spunto o per avere un punto di partenza nella realizzazione del tuo setup.

Gli obiettivi che andremo ad affrontare sono i seguenti:

  1. Definire l’hostname del proprio server SMTP ed impostare la risoluzione inversa.
  2. Inviare le proprie mail su connessioni cifrate
  3. Capire il funzionamento dei record SPF/DKIM/DMARC ed imparare a configurarli.
  4. Riferimenti a tool di terze parti per effettuare analisi

Mentre i software che ho utilizzato per questo articolo sono:

  1. CentOS 7
  2. Postfix
  3. OpenDKIM
  4. Let’s Encrypt – Certbot

Configuriamo l’hostname di Postfix

Una delle verifiche più primitive che esistano nel mondo degli anti spam, è la corrispondenza tra l’hostname del nostro SMTP ed il record PTR.
Per verificare l’hostname di Postfix è sufficiente effettuare una connessione tramite telnet:

[root@26 ~]# sleep 1 | telnet localhost 25
    Trying ::1…
    Connected to localhost.
    Escape character is '^]'.
    220 26.207.XX.XX.provider.ext ESMTP Postfix
    Connection closed by foreign host.

Postfix assume come valore di default il nome del server, in questo caso “26.207.XX.XX.provider.ext”.
Il nome del nostro server è facilmente identificabile tramite il comando:

[root@26 ~]# hostname -f
    26.207.XX.XX.provider.ext

Possiamo procedere a valorizzare correttamente l’hostname del server SMTP – specificandolo in forma fqdn – tramite due differenti strade.

  1. Variare l’hostname del server tramite il comando:
[root@26 ~]# hostnamectl set-hostname ilmioserver.dominio.ext
  1. Impostando la variabile “myhostname” all’interno del file /etc/postfix/main.cf.
[root@ilmioserver ~]# echo 'myhostname = ilmioserver.dominio.ext' >> /etc/postfix/main.cf

Qualsiasi delle due strade si decidesse di adottare, il risultato – a seguito di un riavvio del demone – sarà lo stesso:

[root@ilmioserver ~]# systemctl restart postfix
[root@ilmioserver ~]# sleep 1 | telnet localhost 25
     Trying ::1…
     Connected to localhost.
     Escape character is '^]'.
     220 ilmioserver.dominio.ext ESMTP Postfix
     Connection closed by foreign host.

Modifichiamo la risoluzione inversa dell’IP del nostro server.
Come detto nella sezione precedente, è necessario che venga effettuato positivamente il match tra l’hostname del nostro server SMTP e la risoluzione inversa. La risoluzione inversa è una tipologia di query DNS che traduce un indirizzo IP (dato in ingresso), in un hostname.
Possiamo verificarlo in autonomia tramite il seguente comando (o usando tool online):

[root@ilmioserver ~]# nslookup XX.XX.207.26
     26.207.XX.XX.in-addr.arpa      name = 26.207.XX.XX.servereasy.it. 

La risoluzione inversa dell’indirizzo IP è chiamata anche:

  • Record PTR
  • Reverse Hostname
  • Reverse Lookup
  • RDNS

Tale modifica va richiesta al provider che fornisce la connettività internet, tramite l’ausilio dei portali web o tramite un ticket.
Terminata la configurazione ed atteso il tempo necessario (possono volerci diverse ore), verifichiamo che il record sia corretto:

[root@ilmioserver ~]# nslookup XX.XX.207.26
     26.207.XX.XX.in-addr.arpa      name = ilmioserver.dominio.ext. 

Aumentiamo la sicurezza e non solo!
Uno dei fattori che penalizzano le mail agli occhi dei cloud provider (GMail, Office 365, etc..), è l’invio tramite protocollo non sicuro, che allarmano l’anti spam. Proviamo subito ad inviare una mail ad una casella Gmail per verificare lo stato del nostro invio:

[root@ilmioserver ~]# echo "Questa bellissima mail" | mail -s "Questa bellissima mail, evvai!" -a 'MIME-Version: 1.0' -a 'Content-Type: text/plain' -a "From: prova@dominio.ext" ilmioindirizzo@gmail.com

Appena ricevuta, noteremo la presenza di un lucchetto rosso sbarrato.
Ciò vuol dire che non stiamo inviando le mail in forma cifrata.
Dobbiamo quindi munirci di un certificato valido.
In questo caso ho provveduto a generarne uno gratuito tramite l’ausilio di Let’s Encrypt. (https://certbot.eff.org/lets-encrypt/centosrhel7-other)
Una volta ottenuto, provvediamo ad impostare alcuni parametri all’interno di Postfix:

[root@ilmioserver ~]# echo 'smtpd_tls_cert_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/fullchain.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_tls_key_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/privkey.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_use_tls=yes' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_tls_security_level = may' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_tls_cert_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/fullchain.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_tls_key_file = /etc/letsencrypt/live/ilmioserver.dominio.ext/privkey.pem' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_use_tls=yes' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtp_tls_security_level = may' >> /etc/postfix/main.cf

Ed eseguiamo un rapido restart:

[root@ilmioserver ~]# systemctl restart postfix

Inviando una seconda mai – se configurato tutto correttamente – noteremo l’assenza dello spaventoso lucchetto rosso:

[root@ilmioserver ~]# echo "questa seconda bellissima mail" | mail -s "questa seconda bellissima mail, yuppi!" -a 'MIME-Version: 1.0' -a 'Content-Type: text/plain' -a "From: prova@dominio.ext" ilmioindirizzo@gmail.com 

Configuriamo qualche record DNS.

In questa sezione vedremo degli esempi di configurazione dei record SPF, DKIM e DMARC.
Tutti e tre i sistemi servono per contrastare lo spoofing delle email, ma anche per aumentare il punteggio di affidabilità nei confronti degli antispam.

SPF (Sender Policy Framework) – https://tools.ietf.org/html/rfc7208
Si basa su un record di tipologia TXT e serve per definire “chi” è autorizzato a spedire delle email per conto di un dominio.
Il record SPF deve essere univoco per il dominio o sottodominio.
Di seguito un esempio di configurazione e la sua spiegazione:

     dominio.ext TXT "v=spf1 a mx ip4: -all"

In questo caso l’SPF effettuerà quanto segue:

  • abilitare l’invio dal server che corrisponderà alla risoluzione del record A (o AAAA) di “dominio.ext”
    es.
    dominio.ext A
    dominio.ext AAAA
  • abilitare l’invio dal server che corrisponderà alla risoluzione del record MX di “dominio.ext”
    es:
    mail.dominio.ext A
    dominio.ext MX 10 mail.dominio.ext
  • abilitare l’invio dall’indirizzo IPv4 specificato
  • negare l’invio da tutto il resto

Spesso si può trovare il parametro “include:”, serve ad abilitare il record SPF specificato all’interno dello stesso.
Solitamente è utilizzato dai provider per far ereditare le variazioni delle loro strutture, come l’aumento degli indirizzi IP da autorizzare.

DKIM (DomainKeys Identified Mail) – https://tools.ietf.org/html/rfc6376
Si basa su una coppia di chiavi (privata/pubblica) e serve per verificare la legittimità di un mittente.
La chiave privata sarà contenuta sotto forma di file all’interno del nostro server, mentre la chiave pubblica sarà definita tramite un record TXT nei nostri DNS.
A differenza dell’SPF, è possibile definire più record DKIM perchè il sistema si basa sui “selettori”.
Partiamo dal generare una coppia di chiavi, in questo caso ho adottato il selettore “default”:

[root@ilmioserver ~]# mkdir /etc/opendkim/keys/dominio.ext
[root@ilmioserver ~]# cd /etc/opendkim/keys/dominio.ext && opendkim-genkey -s default -d dominio.ext -b 2048 ; chown opendkim:opendkim default.private

Modifichiamo la configurazione di OpenDKIM per abilitare il supporto di chiavi multiple:

[root@ilmioserver ~]# echo 'KeyTable                /etc/opendkim/KeyTable' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'SigningTable            refile:/etc/opendkim/SigningTable' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'InternalHosts           refile:/etc/opendkim/TrustedHosts' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'AutoRestart             Yes' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'AutoRestartRate         10/1h' >> /etc/opendkim.conf
[root@ilmioserver ~]# echo 'SubDomains              Yes' >> /etc/opendkim.conf

Integriamo OpenDKIM in Postfix:

[root@ilmioserver ~]# echo 'milter_protocol = 2' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'milter_default_action = accept' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'smtpd_milters = inet:localhost:8891' >> /etc/postfix/main.cf
[root@ilmioserver ~]# echo 'non_smtpd_milters = inet:localhost:8891' >> /etc/postfix/main.cf

Configuriamo la coppia di chiavi creata in precedenza:

[root@ilmioserver ~]# echo 'default._domainkey.dominio.ext  dominio.ext:default:/etc/opendkim/keys/dominio.ext/default.private'  >> /etc/opendkim/KeyTable
[root@ilmioserver ~]# echo '*@dominio.ext default._domainkey.dominio.ext' >> /etc/opendkim/SigningTable

Riavviamo i nostri demoni:

[root@ilmioserver ~]# systemctl restart postfix ; systemctl restart opendkim

Infine creaiamo il record DNS (la nostra chiave pubblica):

[root@ilmioserver opendkim]# cat /etc/opendkim/keys/dominio.ext/default.txt

DMARC (Domain-based Message Authentication, Reporting, and Conformance) – https://tools.ietf.org/html/rfc7489
Si basa su un solo ed unico record TXT (valido anche per i sottodomini) e serve per definire le preferenze riguardo la validazione delle proprie email.
In aggiunta, è possibile configurare anche della reportistica.
Necessita che i precedenti meccanismi (SPF e DKIM) siano configurati affinchè lo stesso venga considerato valido dagli antispam.
Partiamo da una configurazione minima del record:

     _dmarc.dominio.ext TXT "v=DMARC1; p=none; sp=none"

In questo precedente caso, notiamo definiti la versione di DMARC e i valori “policy”.
Rispettivamente “p” definisce la policy del dominio principale, mentre “sp” definisce i sottodomini.
Il valore della policy consiste di specificare l’azione che deve intraprendere l’antispam destinatario se i controlli SPF/DKIM falliscono.
E’ definibile – in ordine di restrizione – con:

  • “none”, nessuna particolare azione da intraprendere
  • “quarantine”, segnala la mail come sospetta
  • “reject”, rifiutare la mail

Altri valori configurabili sono “rua” e “ruf”. Essi definiscono l’indirizzo email a cui inviare la reportistica, rispettivamente le versioni “aggregata” e “forense”.
Possiamo quindi arrivare a configurare un record più complesso come il seguente:

     _dmarc.dominio.ext TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:mail_rua@dominio.ext; ruf=mailto:mail_ruf@dominio.ext"

E ora? Facciamo un po’ di test.

Se hai configurato tutto correttamente, le tue mail avranno meno probabilità di finire nella cartella SPAM.
Ma come verificare tutto ciò? Semplicemente utilizzando alcuni tool:

Riattivare i Certificati Let’s Encrypt gestiti con Plesk

Certificati Let's Encrypt gestiti con Plesk

In un post precedente abbiamo spiegato come e perché dopo il 04/03/2020 i certificati Let’s Encrypt sarebbero stati revocati indistintamente anche con i processi avviati in auto-aggiornamento.
Leggete di più al post precedente: Let’s Encrypt scopre il bug CAA e revoca i certificati dei domini sui nostri siti.

Gli utenti i cui certificati sono programmati per essere revocati prima di allora, dovranno forzare manualmente il rinnovo. Questa piccola procedura ora si rivolge ai possessori di Pannelli Plesk, che non hanno ancora ufficializzato il bug. Questo per completare ed arricchire la soluzione del problema spiegato nel post precedente.

Saremo quindi in grado di aggiornare massivamente i certificati Let’s Encrypt anche per chi non ha dimestichezza nell’amministrazione di Web Server se non tramite l’uso del Pannello di Controllo Plesk, diffuso abbondantemente tra i nostri ISP come servizio aggiunto ai Server dedicati e VPS.

La Procedura

  • Connettersi in SSH al proprio server
    Potete Utilizzare un qualunque client con protocollo SSH (sempre che il vostro server lo permetta e sia attivato) come ad esempio Putty per Windows, o con il terminale se usate Mac/UNIX base OS.
  • Modificare o Creare il file /usr/local/psa/admin/conf/panel.ini con le seguenti informazioni:
[ext-letsencrypt]
renew-before-expiration = 365
  • Eseguire il task di rinnovo dei certificati Let’s Encrypt
plesk php -dauto_prepend_file=sdk.php '/usr/local/psa/admin/plib/modules/letsencrypt/scripts/keep-secured.php'
  • Ripristinare o Rimuovere le informazioni del punto 2

Se non siete amministratore di un server web, o non avete accesso alla console o ai servizi Plesk, chiedete informazioni al vostro ISP di fiducia per adempiere immediatamente alla soluzione del problema. Spesso molti siti sono ospitati in Hosting di servizio, dove non si ha il controllo dei certificati Let’s Encrypt.

Se avete bisogno di maggiori aggiornamenti, oppure chiarimenti su come configurare adeguatamente un server web, non esitate a contattarmi in privato, sono in grado di risolvere qualunque problema riscontriate nelle vostre configurazioni.

Non affidatevi al caso, ma in tema di sicurezza (in questo caso Certificati LET’S Encrypt HTTPS) affidatevi sempre ad una Persona di Competenza.

Un ringraziamento particolare a Lorenzo Crippa per la sua segnalazione.

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio
[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio

Let’s Encrypt scopre il bug CAA e revoca i certificati dei domini sui nostri siti

Let's Encrypt

Se i nostri siti vengono segnalati come non protetti, un motivo ci sarà!
Sfortunatamente, la maggior parte degli utenti Let’s Encrypt, se non tutti, dovranno forzare manualmente il rinnovo dei loro certificati entro mercoledì 4 Marzo. È almeno un processo facile.

Il bug segnalato

Recentemente, Let’s Encrypt ha annunciato di aver scoperto un bug nel suo codice CAA (Certification Authority Authorization).

Il bug apre una finestra temporale in cui un certificato potrebbe essere emesso anche se un record CAA nel DNS di quel dominio lo dovesse proibire. Di conseguenza, Let’s Encrypt sta commettendo un errore dal punto di vista della sicurezza piuttosto che della convenienza. Sarà revocato qualsiasi certificato attualmente emesso che non sia legittimato con certezza.

Hanno Dichiarato:

Unfortunately, this means we need to revoke the certificates that were affected by this bug, which includes one or more of your certificates. To avoid disruption, you’ll need to renew and replace your affected certificate(s) by Wednesday, March 4, 2020. We sincerely apologize for the issue.

If you’re not able to renew your certificate by March 4, the date we are required to revoke these certificates, visitors to your site will see security warnings until you do renew the certificate.

Purtroppo, ciò significa che dobbiamo revocare i certificati interessati da questo errore, che include uno o più certificati. Per evitare interruzioni, dovrai rinnovare e sostituire i certificati interessati entro mercoledì 4 marzo 2020. Ci scusiamo sinceramente per il problema.

Se non riesci a rinnovare il certificato entro il 4 marzo 2020, data in cui siamo tenuti a revocare tali certificati, i visitatori del tuo sito vedranno avvisi di sicurezza fino a quando non lo rinnoverai.

URL: https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591

Concetti relativi a sicurezza Internet, certificato SSL/TLS

Let’s Encrypt utilizza il software dell’autorità di certificazione chiamato Boulder. In genere, un server Web che serve molti nomi di dominio separati e utilizza Let’s Encrypt per proteggerli riceve un singolo certificato LE che copre tutti i nomi di dominio utilizzati dal server anziché un certificato separato per ogni singolo dominio.

Il bug LE scoperto è che, invece di controllare separatamente ogni nome di dominio per i record CAA validi che autorizzano il rinnovo di quel dominio da quel server, Boulder controlla un singolo dominio su quel server N° volte (dove N è il numero di LE domini serviti su quel server). Let’s Encrypt in genere considera buoni i risultati della convalida del dominio per 30 giorni dal momento della convalida, ma i record CAA in particolare devono essere controllati non più di otto ore prima dell’emissione del certificato.

Il risultato è che viene presentata una finestra di 30 giorni in cui i certificati potrebbero essere emessi a un determinato server Web da Let’s Encrypt nonostante la presenza di record CAA nel DNS che vieterebbe tale emissione.

La Soluzione

Dato che Lets Encrypt si trova nella posizione non invidiabile di aver emesso certificati che non dovrebbe avere, dal 4 Marzo 2020 saranno revocati tutti i certificati correnti che potrebbero non aver avuto il controllo dei record CAA corretto. Gli utenti i cui certificati sono programmati per essere revocati prima di allora, dovranno forzare manualmente il rinnovo.

Se un Web Server Administrator non esegue questo passaggio di rinnovo manuale, i browser che raggiungeranno i loro siti Web mostreranno avvisi di sicurezza TLS a causa dei certificati revocati.

I certificati Let’s Encrypt vengono emessi per intervalli di 90 giorni e Certbot li rinnova automaticamente solo quando rimangono 30 o meno giorni nel certificato, quindi ciò potrebbe significare circa due mesi di errori del browser se il rinnovo forzato manuale non viene eseguito.

Esistono molti client ACME e le loro procedure variano, ma se state usando Certbot, tutto ciò che è necessario fare è avviare questo comando una volta da shell:

certbot renew --force-renewal 

Fortunatamente, è un processo semplice.

Se non siete amministratore di un server web, o non avete accesso alla console, chiedete informazioni al vostro ISP di fiducia per adempiere immediatamente alla soluzione del problema. Spesso molti siti sono ospitati in Hosting Condiviso dove non si ha il controllo dei certificati Let’s Encrypt.

Se avete bisogno di maggiori aggiornamenti, oppure chiarimenti su come configurare adeguatamente un server web, non esitate a contattarmi in privato, sono in grado di risolvere qualunque problema riscontriate nelle vostre configurazioni.

Per chi amministra Server Web tramite Pannello di Controllo Plesk, vi consigliamo di affidarvi all’addendum, con le procedure descritte in questo Post: Riattivare i Certificati Let’s Encrypt gestiti con Plesk.

Non affidatevi al caso, ma in tema di sicurezza (in questo caso Certificati LET’S Encrypt HTTPS) affidatevi sempre ad una Persona di Competenza.

Corsi e Affini sulla Sicurezza dei Siti Web

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio
[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio