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 🙂
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:
- Implementa una RBL o DNSBL interna con cui può parlare il tuo Gateway
- 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
