DKIM Piergiorgio Venuti

DKIM, DMARC, SPF e Altri Meccanismi di Sicurezza per i Server di Posta Elettronica

Estimated reading time: 8 minuti

Introduzione

Nell’era digitale di oggi, la posta elettronica è diventata parte integrante delle comunicazioni sia per individui che per le aziende. Tuttavia, l’ampia diffusione dell’email la rende anche un obiettivo privilegiato per i criminali informatici che cercano di sfruttare le vulnerabilità e intraprendere attività malevole. Per garantire la sicurezza e l’integrità delle comunicazioni via email, è fondamentale implementare meccanismi di sicurezza robusti sui server di posta. In questo articolo, esploreremo DMARC (Domain-based Message Authentication, Reporting, and Conformance), SPF (Sender Policy Framework) e altri importanti meccanismi di sicurezza per l’email che dovrebbero essere implementati su un server di posta.

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

DMARC è un protocollo di autenticazione per l’email che offre ai proprietari di domini la possibilità di proteggere i loro domini dall’uso non autorizzato e prevenire l’usurpazione di identità nell’email. Consente ai proprietari di domini di specificare le politiche su come i ricevitori di email dovrebbero gestire i messaggi non autenticati provenienti dal loro dominio. Ecco come funziona DMARC:

  1. Meccanismi di autenticazione: DMARC si basa su due meccanismi di autenticazione dell’email esistenti: SPF e DKIM (DomainKeys Identified Mail). SPF verifica che il server di posta mittente sia autorizzato a inviare email per conto del dominio, mentre DKIM garantisce l’integrità e l’autenticità del contenuto dell’email.
  2. Politiche DMARC: I proprietari di domini possono specificare politiche DMARC che definiscono come i ricevitori dovrebbero gestire le email che non superano i controlli di autenticazione SPF e DKIM. Le politiche possono essere impostate su “nessuna” (modalità di monitoraggio), “quarantena” (posiziona le email sospette nella cartella spam del destinatario) o “rifiuta” (scarta l’email).
  3. Reporting: DMARC fornisce anche funzionalità di reportistica, consentendo ai proprietari di domini di ricevere feedback sui risultati dell’autenticazione delle email. Questi report forniscono informazioni preziose sull’ecosistema dell’email e aiutano a identificare potenziali minacce e configurazioni errate.

L’implementazione di DMARC su un server di posta fornisce un ulteriore livello di protezione contro l’usurpazione di identità nell’email, gli attacchi di phishing e l’abuso del dominio. Contribuisce a garantire che solo le email legittime da mittenti autorizzati vengano consegnate ai destinatari.

SPF (Sender Policy Framework)

SPF è un meccanismo di autenticazione dell’email che verifica se un server di posta è autorizzato a inviare email per conto di un dominio specifico. Funziona attraverso la configurazione di record SPF all’interno del dominio, che contengono informazioni sui server di posta autorizzati a inviare email per conto del dominio. Quando un server di posta riceve un messaggio, può verificare l’autenticità del mittente confrontando l’indirizzo IP del server di posta mittente con i record SPF del dominio.

L’implementazione di SPF su un server di posta aiuta a prevenire l’uso non autorizzato di un dominio per inviare email di spam o phishing. Se un messaggio proviene da un server di posta non autorizzato, il server di destinazione può rifiutarlo o contrassegnarlo come sospetto.

Altri Meccanismi di Sicurezza per l’Email

Oltre a DMARC e SPF, ci sono altri meccanismi di sicurezza che possono essere implementati per proteggere i server di posta elettronica. Alcuni di questi includono:

  1. DKIM (DomainKeys Identified Mail): DKIM è un altro meccanismo di autenticazione dell’email che garantisce l’integrità e l’autenticità del contenuto dell’email. Funziona attraversola firma digitale dei messaggi inviati dal dominio mittente. Il server di posta del destinatario può verificare la firma DKIM utilizzando una chiave pubblica pre-condivisa dal dominio mittente.
  2. TLS (Transport Layer Security): TLS è un protocollo di crittografia che offre una connessione sicura tra il server di posta mittente e il server di posta destinatario. La connessione TLS crittografa i dati in transito, proteggendo così le informazioni sensibili contenute nell’email.
  3. SPAM Filters: I filtri antispam sono strumenti utilizzati dai server di posta per identificare e bloccare email indesiderate o sospette. Questi filtri utilizzano una varietà di tecniche, come l’analisi delle parole chiave, il controllo degli indirizzi IP e l’analisi delle firme, per determinare se un messaggio è spam o legittimo.
  4. Anti-malware Scanning: I server di posta possono implementare scanner anti-malware per rilevare e rimuovere eventuali allegati o link dannosi presenti nelle email in arrivo. Questi scanner utilizzano database di firme di malware e algoritmi di rilevamento per identificare minacce potenziali.
  5. Content Filtering: I filtri di contenuto valutano il contenuto delle email in base a regole predefinite per identificare e bloccare email con contenuti inappropriati o non conformi alle politiche aziendali.

L’implementazione di questi meccanismi di sicurezza insieme a DMARC e SPF contribuisce a garantire che le comunicazioni via email siano sicure, autentiche e protette da attività malevole.

La protezione dei mittenti: Politiche dei provider di posta sulla sicurezza degli server di posta.

La crescente preoccupazione per la sicurezza delle email ha portato molti provider come Google e Yahoo a implementare misure più rigorose per proteggere gli utenti da spam, phishing e altre minacce. Una delle politiche recenti adottate da questi provider è quella di non accettare più email da mittenti che utilizzano server di posta non sufficientemente protetti.

Questa decisione è stata presa per garantire che le email inviate agli utenti siano autentiche, sicure e provenienti da mittenti affidabili. I server di posta non protetti, noti anche come open relay, possono essere facilmente sfruttati da spammers e malintenzionati per inviare email non desiderate o dannose. Pertanto, i provider di posta hanno deciso di rifiutare le email provenienti da tali server per proteggere i propri utenti.

Per essere accettate da provider come Google e Yahoo, le email devono essere inviate da server di posta che soddisfano determinati standard di sicurezza, come l’autenticazione SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail). Questi protocolli consentono ai provider di verificare l’autenticità del mittente e garantire che l’email non sia stata alterata durante il trasporto.

Inoltre, i provider di posta possono anche utilizzare altri metodi di verifica, come il controllo delle liste nere degli indirizzi IP sospetti o il monitoraggio delle attività di invio delle email da parte dei mittenti. Queste misure aiutano a identificare e bloccare i mittenti che potrebbero essere coinvolti in attività di spam o phishing.

È importante notare che questa politica può causare problemi per i mittenti legittimi che utilizzano server di posta non protetti. Se un mittente riceve un messaggio di errore che indica che la propria email non è stata accettata da un provider, potrebbe essere necessario riconsiderare l’infrastruttura di posta utilizzata e implementare misure di sicurezza adeguate, come l’aggiunta di autenticazione SPF e DKIM al proprio dominio.

Hardening del server di posta per garantire la consegna delle email

Quando si utilizza il servizio di Webhosting di SOD per la gestione del proprio server di posta, è possibile effettuare l’hardening del server per garantire che le email inviate possano essere ricevute correttamente da tutti i provider di posta. L’hardening del server di posta implica l’implementazione di misure di sicurezza e configurazioni specifiche per migliorare la reputazione del server e aumentare la probabilità di consegna delle email.

Ecco alcuni passaggi che è possibile seguire per l’hardening del server di posta:

  1. Configurazione corretta del DNS: Assicurarsi che il record MX del dominio sia correttamente configurato per indicare il server di posta di SOD come server di posta autorizzato per il dominio.
  2. Implementazione di autenticazione SPF e DKIM: Configurare l’autenticazione SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail) per il dominio. Questi protocolli consentono ai provider di posta di verificare l’autenticità delle email inviate dal server di posta.
  3. Monitoraggio e pulizia delle liste nere: Verificare regolarmente se l’indirizzo IP del server di posta è inserito in liste nere di reputazione degli indirizzi IP. In caso affermativo, prendere le misure necessarie per rimuoverlo dalle liste nere.
  4. Configurazione corretta del reverse DNS: Assicurarsi che il reverse DNS sia correttamente configurato per l’indirizzo IP del server di posta. Questa configurazione consente ai provider di posta di verificare l’autenticità del server di posta.
  5. Monitoraggio delle metriche di reputazione: Monitorare regolarmente le metriche di reputazione del server di posta, come il punteggio di reputazione dell’indirizzo IP e la percentuale di email consegnate correttamente. In caso di problemi, prendere le misure necessarie per migliorare la reputazione del server.
  6. Implementazione di politiche anti-spam: Configurare il server di posta per applicare politiche anti-spam rigorose, come il filtraggio dei messaggi indesiderati e l’uso di liste di controllo degli accessi per impedire l’invio di spam dal server.
  7. Monitoraggio e gestione del flusso di posta: Monitorare attentamente il flusso di posta in uscita dal server e gestire eventuali segnalazioni di problemi di consegna o di email respinte dai provider. Effettuare le correzioni necessarie per risolvere tali problemi.

Effettuando l’hardening del server di posta in conformità con le linee guida di sicurezza e le raccomandazioni dei provider di posta, gli utenti del servizio di Webhosting di SOD possono migliorare la reputazione del proprio server e aumentare la probabilità di consegna delle email senza problemi a tutti i provider di posta.

Conclusioni

La sicurezza dell’email è fondamentale per proteggere le comunicazioni e prevenire attività malevole. L’implementazione di meccanismi di sicurezza come DMARC, SPF e altri meccanismi di autenticazione e protezione aiuta a garantire che solo email legittime e sicure vengano consegnate ai destinatari. È importante che i proprietari di domini e gli amministratori di server di posta comprendano l’importanza di questi meccanismi e li implementino correttamente per proteggere le loro comunicazioni via email.

Useful links:

Condividi


RSS

Piu’ articoli…

Categorie …

Tags

RSS Feed sconosciuto

RSS Feed sconosciuto

RSS Full Disclosure

  • SEC Consult SA-20250226-0 :: Multiple vulnerabilities in Siemens A8000 CP-8050 & CP-8031 PLC Febbraio 27, 2025
    Posted by SEC Consult Vulnerability Lab via Fulldisclosure on Feb 27SEC Consult Vulnerability Lab Security Advisory < 20250226-0 > ======================================================================= title: Multiple Vulnerabilities product: Siemens A8000 CP-8050 PLC Siemens A8000 CP-8031 PLC vulnerable version:
  • Re: MitM attack against OpenSSH's VerifyHostKeyDNS-enabled client Febbraio 27, 2025
    Posted by Jordy Zomer on Feb 27Hey all, First of all, cool findings! I&apos;ve been working on the CodeQL query and have a revised version that I think improves accuracy and might offer some performance gains (though I haven&apos;t done rigorous benchmarking). The key change is the use of `StackVariableReachability` and making sure that there&apos;s […]
  • MitM attack against OpenSSH's VerifyHostKeyDNS-enabled client Febbraio 21, 2025
    Posted by Qualys Security Advisory via Fulldisclosure on Feb 20Qualys Security Advisory CVE-2025-26465: MitM attack against OpenSSH&apos;s VerifyHostKeyDNS-enabled client CVE-2025-26466: DoS attack against OpenSSH&apos;s client and server ======================================================================== Contents ======================================================================== Summary Background Experiments Results MitM attack against OpenSSH&apos;s VerifyHostKeyDNS-enabled client DoS...
  • Self Stored XSS - acp2sev7.2.2 Febbraio 21, 2025
    Posted by Andrey Stoykov on Feb 20# Exploit Title: Self Stored XSS - acp2sev7.2.2 # Date: 02/2025 # Exploit Author: Andrey Stoykov # Version: 7.2.2 # Tested on: Ubuntu 22.04 # Blog: https://msecureltd.blogspot.com/2025/02/friday-fun-pentest-series-19-self.html Self Stored XSS #1: Steps to Reproduce: 1. Visit "http://192.168.58.168/acp2se/mul/muladmin.php" and login with "admin" / "adminpass" 2. In the field "Put the […]
  • Python's official documentation contains textbook example of insecure code (XSS) Febbraio 21, 2025
    Posted by Georgi Guninski on Feb 20Python&apos;s official documentation contains textbook example of insecure code (XSS) Date: 2025-02-18 Author: Georgi Guninski === form = cgi.FieldStorage() if "name" not in form or "addr" not in form: print("Error") print("Please fill in the name and addr fields.") return print("name:", form["name"].value) print("addr:",...
  • Re: Netgear Router Administrative Web Interface Lacks Transport Encryption By Default Febbraio 18, 2025
    Posted by Gynvael Coldwind on Feb 17Hi, This isn&apos;t really a problem a vendor can solve in firmware (apart from offering configuration via cloud, which has its own issues). Even if they would enable TLS/SSL by default, it would just give one a false sense of security, since: - the certificates would be invalid (public […]
  • Monero 18.3.4 zero-day DoS vulnerability has been dropped publicly on social network. Febbraio 16, 2025
    Posted by upper.underflow via Fulldisclosure on Feb 16Hello, About an hour ago, a group appearing to be named WyRCV2 posted a note on the nostr social network, which can be found at the following link: https://primal.net/e/note1vzh0mj9rcxax9cgcdapupyxeehjprd68gd9kk9wrv939m8knulrs4780x7 Save, share, use. The paste link includes a list of nodes that the attacker has instructed to target, along […]
  • Netgear Router Administrative Web Interface Lacks Transport Encryption By Default Febbraio 16, 2025
    Posted by Ryan Delaney via Fulldisclosure on Feb 16
  • [CVE-2024-54756] GZDoom <= 4.13.1 Arbitrary Code Execution via Malicious ZScript Febbraio 16, 2025
    Posted by Gabriel Valachi via Fulldisclosure on Feb 15In GZDoom 4.13.1 and below, there is a vulnerability involving array sizes in ZScript, the game engine&apos;s primary scripting language. It is possible to dynamically allocate an array of 1073741823 dwords, permitting access to the rest of the heap from the start of the array and causing […]
  • Re: Text injection on https://www.google.com/sorry/index via ?q parameter (no XSS) Febbraio 16, 2025
    Posted by David Fifield on Feb 15Today at about 2025-02-13 19:00 I noticed the "≠" is back, but now the type 0x12 payload of the ?q query parameter gets formatted into the string representation of an IP address, rather than being copied almost verbatim into the page. If the payload length is 4 bytes, it […]

Customers

Newsletter

{subscription_form_2}