Spiegati i misteriosi protocolli SPF, DKIM e DMARC

Tratto da: Security Blog Libraesva
Autore: Rodolfo Saccani – 2 novembre 2020
 
 

 

La posta elettronica è una cosa antica, è nata molto più tempo prima di Internet.

Il primo sistema di posta elettronica è nato nel 1965 al MIT. A quel tempo la comunicazione e-mail era limitata entro i confini di un unico mainframe, quei computer multiutente enormi, molto costosi e delicati che occupavano intere stanze climatizzate e richiedevano una supervisione continua.

Nel 1971 avvenne la prima trasmissione di un’e-mail tra computer collegati. È stato un piccolo passo per una singola email, ma un primo enorme passo per l’umanità.

Nel 1982 nacque il protocollo SMTP, questo è il protocollo che utilizziamo ancora oggi per lo scambio di email su Internet.

Il problema principale dell’email (e dell’SMTP) è che, essendo nato in un ambiente collaborativo in cui la sicurezza non era affatto un problema, essendo progettato in un momento in cui l’abuso non era nemmeno un’opzione teorica, il protocollo non aveva alcuna sicurezza a tutto tra i suoi requisiti di design.
Nessuna autenticazione del mittente: chiunque potrebbe fingere di essere chiunque.
Nessuna riservatezza : i messaggi sono stati scambiati e archiviati in chiaro.
Nessun controllo di integrità : non è stato possibile impedire o addirittura rilevare la manipolazione del contenuto dell’email lungo il percorso.
Nessuna protezione sui messaggi non richiesti : chiunque può inviare qualsiasi quantità di e-mail a qualsiasi destinatario.

Poi la posta elettronica è diventata popolare e questi problemi hanno iniziato a comparire rapidamente.

È diventato chiaro che dovevamo fare qualcosa per affrontare questa mancanza di sicurezza nel protocollo. Nessuno ci aveva pensato prima perché nessuno immaginava che l’e-mail sarebbe diventata ciò che è oggi: la principale forma di comunicazione elettronica su cui si basano le nostre società , qualcosa su cui tutte le organizzazioni, le imprese e gli individui fanno affidamento ogni giorno per gestire la propria vita .

Come tutti abbiamo imparato a nostre spese negli anni seguenti, aggiungere la sicurezza in seguito è molto più difficile che inserirla in fase di progettazione. Questo è uno dei principi più importanti del GDPR: se vuoi una sicurezza reale, ne hai bisogno fin dalla progettazione.

Aggiungere la sicurezza come ripensamento è difficile. È ancora più difficile se devi garantire la compatibilità con le versioni precedenti. La posta elettronica è l’esempio più chiaro di quanto sia difficile aggiungere sicurezza a qualcosa che è già distribuito in tutto il mondo, dove è necessario garantire che la posta elettronica possa ancora essere scambiata con server che non sono stati aggiornati ai nuovi standard.

È qui che entrano in gioco gli acronimi che si trovano nel titolo di questo articolo: SPF , DKIM e DMARC sono tre standard che sono stati aggiunti all’email nel tentativo di renderla più sicura.

SPF ha un compito molto semplice: prevenire lo spoofing del dominio. La tua organizzazione può dichiarare al mondo un sottoinsieme di indirizzi IP autorizzati a inviare email per conto del dominio della tua organizzazione. Definendo questo criterio, è possibile impedire ad attori malintenzionati di inviare e-mail fingendo di essere la tua organizzazione.
La configurazione di una policy SPF è molto semplice e relativamente priva di rischi: è sufficiente mappare tutti gli indirizzi IP che la tua organizzazione utilizza per inviare email. Un piccolo sforzo per ciò che ricevi in ​​cambio e se hai enumerato correttamente tutti i tuoi indirizzi IP legittimi da cui invii email, nessuna email andrà persa.
SPF non è perfetto, però, e non è sufficiente per prevenire tutti i tipi di spoofing, ma è comunque molto meglio di niente.

DKIM ha uno scopo principale: garantire l’integrità del contenuto dell’email. Integrità significa che il destinatario può rilevare se l’email è stata modificata o manomessa lungo il percorso. Questo avviene tramite una firma elettronica: se la firma è valida, sai che puoi fare affidamento sul contenuto dell’email. Se la firma non è valida, è probabile che il messaggio sia stato manomesso. Questa firma viene aggiunta e controllata automaticamente dai server di posta e l’utente non deve fare nulla.
L’impostazione di DKIM richiede un po ‘più di sforzo rispetto a SPF ma è sicuro: se lo si configura male, l’email non andrà persa.

SPF e DKIM non risolvono ancora completamente il problema del phishing. L’e-mail è un po ‘come una semplice lettera di carta: il mittente e il destinatario scritti sulla busta vengono utilizzati per la consegna, ma il destinatario non vede la busta. Il destinatario vede semplicemente la lettera all’interno della busta e in quella lettera il nome e l’indirizzo del mittente possono essere falsificati. Fondamentalmente, il client di posta mostra il mittente che è scritto nella lettera, non quello sulla busta (che può essere protetta con SPF).

DMARC è stato progettato esattamente per questo scopo: assicurarti che il mittente mostrato dal tuo client di posta elettronica sia affidabile. Ciò viene eseguito pubblicando un criterio DMARC che istruisce i destinatari a verificare se il mittente visualizzato dal destinatario corrisponde a SPF o DKIM. L’email deve essere inviata da un indirizzo IP autorizzato per quel dominio (SPF è ok), oppure deve essere firmata con una chiave legittima di quel dominio (la firma DKIM è ok), altrimenti non verrà consegnata.

DMARC deve essere configurato dominio per dominio dall’amministratore di posta elettronica del dominio di invio. Fornisce un’ottima protezione contro lo spoofing e la rappresentazione, ma la configurazione non è semplice e gli errori nella configurazione possono portare alla perdita della posta elettronica . Pertanto, la configurazione di DMARC deve essere eseguita con competenza, senza improvvisare.

Ci sono altri standard che sono stati introdotti nell’email, come TLS (per crittografare l’email in transito) e S / MIME o PGP per la crittografia end-to-end. Queste sono cose di cui non devi preoccuparti. TLS è gestito automaticamente dai server di posta. S / MIME e PGP hanno un’adozione minuscola a causa delle complessità legate alla gestione delle chiavi da parte degli utenti finali.

Ti interessa SPF, DKIM e DMARC per la tua organizzazione? Dovresti.
Inizia con SPF, quindi procedi con DKIM e infine valuta DMARC.

Queste configurazioni non risolveranno tutti i problemi di sicurezza della posta elettronica, ma renderanno la tua comunicazione e-mail molto più sicura e affidabile.

3 Novembre 2020

Configurare Kaspersky Application Privilege Control per bloccare i ransomware

Il modulo Application Privilege Control di Kaspersky svolge un ruolo fondamentale nell’arginare la diffusione di malware di difficile individuazione con i metodi tradizionali.

In particolare per mitigare il rischio portato dai malware più sofisticati, quelli in grado di comprendere quando sono sotto analisi euristica rendendola inefficace, è importante effettuare una configurazione rigorosa di Application Privilege Control.

Il modulo discrimina in base alla firma dell’eseguibile, quelli noti da quelli sconosciuti, e concede l’accesso alle risorse in base al livello di fiducia.

kas application privilege control

Per poter essere il più efficace possibile la configurazione di default deve essere modificata e deve essere settata per l’opzione: “For unknown applications” il valore: “Automatically move to group: Untrusted“.

In questo caso avremo la certezza di bloccare l’esecuzione di tutte le applicazioni sconosciute, ed un malware rientrerà sicuramente in questa categoria.

Una configurazione così rigida porta a diversi casi in cui applicazioni poco diffuse possono rimanere bloccate.

Suggeriamo di monitorare il comportamento effettuando il log degli eventi di blocco da parte di Application Privilege Control in modo da rendere facile lo sblocco manuale delle applicazioni non pericolose.

argonavislabArgonavis è a vostra disposizione per fornirvi ulteriori informazioni su aspetti tecnici e commerciali, ed illustrarvi la convenienza nel proteggere i vostri sistemi con le tecnologie più efficaci.

Richiedi Informazioni

30 Giugno 2016

Eccezioni in Kaspersky modulo Application Privileges Control

Application Privilege Control è un componente fondamentale di Kaspersky Security Endpoint for Business, in grado di bloccare le minacce ancora sconosciute anche se talvolta corre il rischio di bloccare qualche applicazione non malevola.

In questi casi l’amministratore deve modificare la policy ed inserire nel gruppo trusted l’applicazione bloccata.

Il primo passo consiste nel entrare nella policy e modificare “Application Privilege Control”

Modifica della policy

In Application rules premere il pulsante “Settings…” più in alto.

modifica policy

Premere il pulsante “Add”modifica policy

Inserire in Application il nome dell’applicazione e premere Refresh, la schermata si popolerà dei dati sulle applicazioni raccolti sugli endpoint. Se viene inserito il nome l’applicazione incompleto, utilizzare * per fare una ricerca sulla maschera.

Trovate le applicazioni verificare quelli che non appartengono al gruppo trusted (premendo sulla colonna group vengono ordinati in base al gruppo), selezionarli ed in basso selezionare il gruppo in cui verranno spostati: Trusted.

selezione dell'applicazioneOra vedremo nel gruppo Trusted il nome degli eseguibili che abbiamo spostato. Confermiamo con il pulsante OK ed attendiamo che policy venga applicata per fare nuovamente dei test.

diritti

 

 

25 Gennaio 2016

Configurare LibraESVA LDAP per utenti Zimbra

LibraESVA ha diverse funzionalità che utilizzano gli utenti e le loro relative credenziali.

La più visibile è l’autenticazione sull’interfaccia web, per permettere all’utente di consultare le proprie code di quarantena, rilasciare un messaggio bloccato o agire sulle blacklist/whitelist private.

Le interfacce di configurazione in LibraESVA, sono come al solito, molto facili ed intuitive, ma la configurazione di LDAP comporta sempre qualche difficoltà nella scelta dei parametri corretti.

Dal menù “System”, si accede ad LDAP Set Definition

Configurazione LDAP

Aggiungiamo una nuova configurazione

Configurazione LDAP

Selezioniamo il dominio, fra quelli configurati su LibraESVA.

Se abbiamo più server LDAP nel cluster Zimbra ne possiamo indicare due, nel caso avessimo una installazione su singola macchina, mettiamo il nome del server Zimbra.

Nel campo Email Address DN: mettiamo la stringa cn=users,dc=domain,dc=ad sostituendo dc=domain,dc=ad con i dati relativi al nostro dominio (ad esempio se il dominio fosse: examples.it la stringa corretta sarebbe: cn=users,dc=examples,dc=it)

Nel campo User DN: mettiamo la stringa ou=people,dc=domain,dc=ad sostituendo dc=domain,dc=ad con i dati relativi al nostro dominio (nell’esempio di prima, con il dominio examples.it la stringa corretta sarebbe: ou=people,dc=examples,dc=it)

Nel campo Bind User: mettiamo la stringa uid=user,ou=people,dc=domain,dc=ad mettendo in uid un account valido, e sostituendo dc=domain,dc=ad con i dati relativi al nostro dominio (nell’esempio di prima, con il dominio examples.it ed utente ldap, la stringa corretta sarebbe: uid=ldap,ou=people,dc=examples,dc=it)

Nel campo Bind Password: mettiamo la password dell’utente inserito in Bind User

Nel campo Type: mettiamo il valore OTHER
Nel campo Username Field: mettiamo il valore uid
Nel campo Email Alias Field: mettiamo il valore mail
Nel campo Authentication Filter: mettiamo il valore mail=%%LOGIN%%

Schermata del 2015-05-22 12:41:35

Salvata la configurazione possiamo effettuare il test di connessione

Configurazione LDAP

Se il test dovesse fallire, avremmo un risultato simile a questo. Verificate che il firewall sia configurato in modo tale che LibraESVA possa raggiungere Zimbra sulla porta 389.

Configurazione LDAP fallita

Se il test ha esito positivo invece uscirà una schermata simile a questa, e verranno elencati tutti gli indirizzi che vengono trovati (incluse le liste di distribuzione).

Configurazione LDAP con successo

I tecnici certificati su LibraESVA di Argonavis sono a tua disposizione per supportarti sull’utilizzo di LibraESVA

Richiedi Informazioni

22 Maggio 2015