The email files: se 40000 in blocklist vi sembran pochi

Vabbeh giusto un paio di giorni fa mi son trovato a discorrere di una richiesta di un SOC di mettere 40000 domini in una email-blocklist.

Ho cercato di spiegare che la cosa non ha senso, ma ho trovato una certa rigidità in merito.

Poi mi sono soffermato un attimo e mi son chiesto: io parlo di sicurezza, ma loro?

E mi son ricordato di quando cercavo di spiegare che mettere miliardi di regole su di un firewall dimostra solo di non aver capito come si configura un firewall per fare security 😂😁😎
Che faccio quindi? un update dell’articolo sotto per mettere alcuni punti in chiaro 🙂

The email Files: Blocklisting, la sottile arte di farsi del male da soli

https://thepuchiherald.com/the-email-files-blocklisting-la-sottile-arte-di-farsi-del-male-da-soli/

Blocklisting: un falso senso di sicurezza

Per qualche oscuro motivo una buona parte degli operatori di sicurezza informatica è convinta che gli attaccanti siano essenzialmente degli stupidi e che compiano azioni che riconoscerebbe anche un bambino.

Non riesco a spiegarmi in altro modo la propensione alle liste di blocco, sopratutto quando queste contengono decine di migliaia di entry.

Bloccare delle entry (tipicamente Indirizzi IP o domini) che sono già state individuate come malevoli è un po come chiudere le porte della stalla dopo che ne sono fuggiti gli animali.

Se pur vero che in minima parte certe entry, solitamente legate al perdurare di un attacco, possono essere attive, questo non è per sempre. Ma questo lo avevo spiegato in precedenza.

In compenso la gestione di liste gargantuesche comporta diversi problemi, sia prestazionali che di gestione vera e propria.

Che sia un email security gateway o un firewall tenere un approccio statico ai filtri raramente denota competenze specifiche nella sicurezza informatica.

Detto questo è sempre possibile che vi siano obblighi provenienti da sorgenti che non hanno nessun affinità con la materia, e quindi questo approccio diventa “necessario” alla sopravvivenza.

I motivi possono essere vari: “legali” o “politici” ma sicuramente non tecnici.

Ma proprio per questo difficilmente contestabili, mancando le basi minime di comprensione del fenomeno da parte di chi esegue la richiesta.

Quindi assumiamo che sia necessario, ancorché non sensato, dover implementare sui nostri sistemi statiche, stupide, chilometriche ed inutili liste di blocco. Dobbiamo in qualche maniera essere in grado di sopravvivere alla cosa.

Come sopravviverci?

Pur essendoci su internet diversi servizi di RBL mi soffermo qui sulla esigenza, prima espressa, di soddisfare una richiesta di implementare delle liste di blocco chilometriche all’interno del nostro servizio di sicurezza e non accedere a servizi pubblici di RBL.

Innanzi tutto è necessario ricordare che queste liste sono spesso un inutile accozzaglia di vecchie referenze che poco hanno a che fare col threat landscape corrente, occorre quindi NON affidarsi a queste ultime come unica sorgente di protezione.

In secondo luogo occorre prepararsi ad avere eventuali falsi positivi, nel malaugurato caso che domini legittimi utilizzati in attacchi finiscano in queste liste che probabilmente non sono sempre aggiornate.

In terzo luogo occorre che il security gateway che usiamo sia capace di processare queste liste anche in termini di consumo di risorse.

Il problema è presentato proprio dal fatto che spesso queste liste non sono legate a domini, IP o risorse web usate solo da criminali, ma anche da soggetti legittimi. In questo caso se le liste non sono aggiornate dinamicamente con una certa frequenza rischiamo di bloccare risorse lecitamente usate con le problematiche del caso.

La cosa è nota da anni, ed è il motivo alla base della diminuzione dell’uso delle RBL come strumento di filtro per meccanismo di analisi più efficienti (come ad esempio la reputazione dinamica delle risorse).

Le Real-time blackhole list (RBL) note anche come DNS Block List (DNSBL) sono generalmente liste pubbliche che raccolgono domini o IP che hanno una reputazione come emettitori di email illegittime (spam o peggio). Molti servizi su internet offrono questo tipo di liste ma, per mantenersi decentemente aggiornate, di solito non amano che un singolo utente richieda il blacklisting di un numero molto elevato di voci.

Bloccare un dominio tramite una risorsa pubblica potrebbe generare anche possibili conflitti legali, da qui la attenzione dei gestori di DNSBL alle entry e anche al delisting.

Ma cosa dobbiamo fare, quindi, se qualche illuminato della sicurezza ci chiede di caricare decine di migliaia di entry sui nostri sistemi?

La soluzione potrebbe essere legata alla creazione di una RBL interna.

Sebbene si possa implementare una RBL attraverso un normale DNS server per motivi di performance e di amministrazione è meglio orientarsi a software specifici.

RBL vs Filtri al gateway

La domanda potrebbe essere: perchè non implementare direttamente un filtro al gateway invece di usare risorse esterne?

Ci sono alcuni ottimi motivi per evitare l’approccio diretto al gateway di cui citerò solo 2 banali ed ovvi:

• Performance
• Amministrazione

Per quello che concerne le performance, difficilmente i security gateway moderni nascono per ospitare liste con diverse migliaia di voci. la ragione è che sono disegnati per fare sicurezza in maniera dinamica, e quindi servizi e risorse sono ottimizzati a quello scopo.

Dal punto di vista amministrativo, analogamente, a meno che non si disponga,come si diceva in precedenza, di un software specifico la gestione di queste liste è manuale e spesso complicata.

Utilizzare un software specifico per la gestione delle liste di blocco invece consente di aggirare i due problemi visti sopra demandando al security gateway la sola chiamata di controllo alla RBL.

Concludendo?

Pur rimanendo convinto che un approccio basato su interminabili block list sia fondamentalmente errato sotto qualsiasi punto di vista, se proprio non puoi fare a meno di implementare una stupidata di questo tipo cerca la via meno dolorosa:

1. Implementa una RBL o DNSBL interna con cui può parlare il tuo Gateway
2. Gestisci periodiche verifiche delle entry per evitare che vi possano essere problemi di falsi positivi e legali.

Vediamo se è l’ultima volta che scrivo di queste cose 😂😎🤣
#security #email

The email Files: Safelisting email? Poi non lamentarti!

Ok sotto il cappello degli email files inizierò a scrivere riflessioni semiserie (come mio solito) sugli errori ed orrori di gestione della posta elettronica.

L’idea nasce da anni di militanza nel settore, ove ho realizzato 3 cose fondamentali:

1. la maggior parte degli utilizzatori non sa cosa sia e come funzioni la posta elettronica
2. la maggior parte degli amministratori non sa cosa sia e come funzioni la posta elettronica
3. i “cattivi” hanno capito benissimo come funziona la posta elettronica ed approfittano dei punti 1 e 2 per farne uno dei veicoli più efficaci ed efficienti di attacco.

Cercherò quindi in funzione di quel che mi passa per la mente, in maniera aperiodica e non regolare di scrivere quello che mi viene.

Oggi parlo di un argomento banale, il safelist o allowlist (una volta detto whitelist prima delle purghe del politically correct estremo).

Safelist: che cosa è

Iniziamo a capire di cosa parliamo.

Tutti gli strumenti di posta moderni hanno una serie di filtri più o meno evoluti che servono ad evitare che messaggi malevoli e pericolosi vengano consegnati alla mailbox dell’utente.

I motivi validissimi di questo approccio sono legati al fatto che:

1. gli utenti difficilmente hanno gli strumenti cognitivi per distinguere cosa sia pericoloso e cosa no (altrimenti non ci sarebbe questo successo devastante dell’uso delle email come veicolo di attacco)
2. la mail per le sue specifiche caratteristiche (vedetevi cosa sia l’SMTP, cosa significhi protocollo in chiaro, cosa significhi protocollo asicrono, cosa significhi protocollo unreliable cosa significhi avere doppie intestazioni tecniche e visibili…)

Il problema è che questi filtri non sono perfetti e si può incorrere in 2 spiacevoli estremi:

1. il filtro non blocca qualcosa che dovrebbe bloccare (ci si riferisce a questa evenienza come falso negativo)
2. il filtro blocca qualcosa che non andrebbe bloccato (ci si riferisce a questa evenienza come falso positivo)

Il punto 2 è quello di cui andiamo a parlare or ora.

Per evitare che i filtri non blocchino quello che non andrebbe bloccato tutti i sistemi e soprattutto tutti gli utenti invocano un rimedio che è stato identificato nel Safelosting.

Il procedimento è semplicissimo, si tratta di dire al sistema di non applicare questi filtri a specifici flussi di email. Il riconoscimento di questi flussi è di solito legato a:

uno specifico indirizzo di posta elettronica esempio: sonobuono@lasciamipassare.com

un dominio di posta elettronica come, ad esempio: @laciamipassare.com

Quindi una safelist consiste un una serie di voci: domini di posta e\o indirizzi che non vengono analizzati dai filtri di protezione del sistema

La base di questo approccio procedurale è basato dall’assunto: “non so cosa faccio, non ne capisco la tecnicalità dietro ma mi permetto di saltare, in pura incoscienza, i filtri di sicurezza confidando nella mia sopravvalutazione di essere capace di riconoscere eventuali rischi.”

Non intendo dire, con questo, che il safelisting sia una attività inutile, ma che va usata, per la sua natura di saltare i filtri di sicurezza, in maniera oculata e responsabile.

Ora non nego che le persone del marketing, sales, HR, Management assortito non abbiano la giusta preoccupazione di non avere mail importanti bloccate, il discutibile è che siano loro, privi delle competenze specifiche, a dettare vincoli che minano alla base la sicurezza di uno dei primi veicoli di attacco utilizzati dai threat actor.

Discutibile è anche il fatto che vi siano aspettative sulla posta elettronica ben lontane dalla realtà dello strumento. Aspettative legate, appunto, alla non conoscenza dello strumento stesso.

Se non si conosce uno strumento non lo si usa correttamente ne si è in grado di capire e valutare gli eventuali rischi connessi.

A fronte di questo oggettivo scenario, quindi, si decide arbitrariamente di mettere in sospensione i filtri? Non proprio la mossa più lungimirante se si guarda la cosa dal punto di vista della sicurezza informatica.

Ma allora che fare?

Falso positivo: ma di cosa si tratta davvero?

Il primo punto è capire cosa sia davvero un falso positivo:

Il falso positivo si ha quando i filtri di protezione individuano erroneamente un messaggio “buono” come “malevolo”

Raramente questa identificazione ha a che fare con la reputazione del mittente o la struttura delle intestazioni, proprio perchè stiamo parlando di falsi positivi. Questo significa che con grande probabilità la ragione del blocco è legata al contenuto del messaggio. Questo contenuto è per sua natura variabile e, a meno che non vi siano dei pattern ripetuti che incappano per qualche motivo nei filtri in essere, difficilmente provoca blocchi ripetuti e frequenti.

Esistono eccezioni a queste considerazioni, spesso newsletter o email marketing sono “malformate” (spoofing mittente, struttura HTML, componenti attivi, similitudine con campagne di attacco in corso e via dicendo)

A fronte di un evento puntuale, peròil safelisting pone una soluzione “statica” che blocca l’analisi dei contenuti di quei flussi di email in maniera permanente, questo di fatto aumenta sensibimente l’esposizione al rischio.

Procedimenti come il safelisting o il blocklisting non possono quindi non considerare le condizioni al contorno e specifiche del singolo messaggio. Il che non significa che non abbiano uso e scopo, ma che vanno gestiti in maniera coerente con la loro natura.

Safelisting: che fare

siamo onesti, in un mondo ideale con utenti preparati, consapevoli e capaci di gestire il rischio, emettitori di posta che fanno le cose per bene sapendo come si deve gestire lo strumento, gestori di mailserver e gateway che utilizzano approcci sensati e coerenti il safelisting non sarebbe quasi in uso.

Ma il mondo non è cosi, anzi.

La poca conoscenza del mondo delle email è imbarazzante, cosi come la scarsa comprensione delle esigenze di sicurezza di questo canale comunicativo quindi le liste di abilitazione ci accompagneranno per lungo lungo tempo.

Ma cosa fare allora per limitarne i danni?

Ci sono alcuni processi da mettere in piedi per gestire il safelisting che possono aiutare a diminuire la superficie di rischio.

Diminuire le voci in whitelist al minimo

questo sembra ovvio ma è il primo elemento da considerare.

Metter in whitelist tuttte le richieste provenienti dalle varie voci incoscenti dell’azienda non ha senso. Prima di safelistare qualcosa occorrerebbe verificare che non sia un evento ripetitivo. Un atteggiamento sensato consite nel sbloccare la email eventualmente bloccata, NON fare nessun safelisting ma iniziare a monitorare il comportamento di quel flusso di posta e procedere all’evetuale safelist solo in seguito a ripetuti blocchi errati.

Non mettere in whitelist interi domini

Se il safelisting espone ad un maggiore rischio, è evidente che inserire un intero dominio in whtelist significa aumentare il rischio in funzione del numerodi email generabili per quel dominio. Si deve considerare quindi che un dominio aperto significa tanti potenziali vettori di rischio.

Non mettere MAI in safelist domini di email pubbliche

Lo so che nessuno lo farebbe mai, ma allora perchè mi capita di vedere in queste liste robe tipo “gmail.com”, “yahoo.com”, “libero.it” e via dicendo?

Le email consumer free sono un veicolo ideale per sviluppare in maniera semplici attacchi anche sofisticati, il solo richiedere di “liberare” un tale dominio è dimostrazione più che evidente che il richiedente non ha idea di cosa sia la posta elettronica ne come si usi. Non importa se è il figlio del direttore HR, il cognato del vicepresidente del marketing, o il cane dell’amministratore delegato. Semplicemente queste richieste devono essere negate fermamente senza se, senza ma e senza forse. In alternativa ci si fa dare una bella mail che impone il cambio da poter mostrare al soggetto al primo attacco ransomware dicendo: “te lo avevo detto ma tu…” 🙂

Se proprio devi fare safelist almeno limita i danni

Uno dei primi concetti che impari quando si parla di sicurezza è che minore è la superficie di esposizione minore il rischio. Essendo il safelisting una procedura che espone a rischio gli utenti è buona norma spostarla il più vicino al richiedente in maniera da ridurre la esposizione per gli altri utenti.

Mi spego: abilitare un mittente a bypassare i filtri per l’intero numero di utenti della azienda non ha molto senso se la richiesta proviene da una risorsa specifica. Molti sistemi oggigiorno consentono di creare policy specifiche per singoli utenti e gruppi di utenti ristretti. Una scelta opportuna è operare safelisting a questi livelli piuttosto che per tutta la organizzazione.

Ha senso spostare il safelisting quindi nella struttura più vicina al richiedente, utente o gruppo di utenti che sia.

Sopratutto in caso di gestioni estremamente statiche del safelist questo consente di controllare un minimo la superficie di rischio.

Un safelist NON è per sempre

Diciamocelo chiaro, non esistono motivi per tenere una lista che permetta l’ingresso di “la qualunque” per sempre in maniera immutabile. Già le considerazioni precedenti dovrebbero aver aperto un minimo di consapevolezza sul fatto che il safelisting non è una panacea dal punto di vista della sicurezza.

Per evitare che queste liste crescano a dismisura e calcifichino email e domini in maniera perenne è opportuno periodicamente procedere ad una revisione delle voci della lista.

Questo significa che dopo un certo periodo di tempo sarebbe opportuno eliminare le voci (in modalità FIFO, First In First Out). Difficilmente gli errori, se la piattaforma di filtering è gestita correttamente, si ripeteranno.

Sapere come usare i propri strumenti non è una brutta cosa.

Mi si conceda una ultima battuta.

Come tutti gli strumenti anche la posta elettronica ha le sue specificità che andrebbero conosciute da chiunque la utilizzi, la pessima idea di sapere come usarla e non avere bisogno di formazione è tanto stupida quanto, purtroppo, radicata.

E non si pensi che la cosa sia limitata ai soli utenti o al magnifico management, spesso anche chi si occupa di IT e persino di posta non ha le competenze corrette per gestire questo strumento al meglio.

Ne sia un esempio questa domanda:

quanti sanno cosa siano

• SPF
• DKIM
• DMARC

e quali siano vantaggi e debolezze di ogniuno di questi protocolli di autenticazione della posta?

Meditate gente Meditate