Questo sito utilizza i cookie per migliorare servizi ed esperienza dei lettori. Se decidi di continuare la navigazione consideriamo che accetti il loro uso. Per maggiori informazioni sull uso dei cookies e su come eliminarli leggi l'informativa estesa

Informativa sulla privacy

GARR CERT: 20 anni e non sentirli

GARR CERT: 20 anni e non sentirli

| Leonardo Lanzi | servizi alla comunità
Articolo letto 100 volte

Alla scoperta delle attività del servizio che garantisce la sicurezza della rete GARR, tra nuove minacce e motivazioni sempre attuali

Andando a frugare in rete per cercare qualcosa sulle origini del GARR CERT, come si fa a volte nelle soffitte, si possono ritrovare le motivazioni per la nascita del servizio, che sono incredibilmente attuali. Nella descrizione degli interventi del secondo Workshop GARR, che si tenne nel lontano gennaio 2000, il neonato GARR CERT viene presentato come un “servizio per la gestione delle problematiche legate alla sicurezza software”. I due problemi principali di allora erano lo SPAM mail (o per meglio dire, la presenza di server mail non protetti che permettevano l’attività di SPAM) e le intrusioni, anche con gravi conseguenze, nei sistemi meno protetti. Una delle finalità del GARR CERT, se non forse la principale, era, allora come oggi, la sensibilizzazione degli utenti a questo tipo di problemi.

Una volta chiara la missione è più facile inquadrare le attività svolte dal CERT fin dall’inizio, come sono state aggiornate negli anni, e come altre si sono aggiunte via via. Partiamo da quella più nota: la gestione degli incidenti di sicurezza; questa segue una procedura di massima che in funzione della gravità della situazione, del tipo e del numero degli enti coinvolti, aiuta noi del CERT a guidare gli utenti verso la risoluzione del problema quando la causa è interna alla loro organizzazione, o a tutelarli nel modo migliore quando subiscono attacchi dall’esterno. Gli incidenti sono in rapida evoluzione sia come numero che come qualità. Nel corso degli anni le attività si sono ampliate, seguendo i concetti di prevenzione e proattività.

Tra queste citerei il servizio SCARR per l’esecuzione di scansioni di vulnerabilità sulle reti degli utenti, che da ottobre 2019, sono interamente attivate e gestite dagli APM, l’invio di avvisi automatici agli APM per più di 30 categorie di problemi di sicurezza (molte tra queste relative a configurazioni locali sfruttabili per attacchi come DDoS, o diffusione di botnet, ecc), e una lista di distribuzione ad iscrizione libera per gli alert di sicurezza relativi a sistemi operativi, applicazioni e servizi di rete di uso comune. Non ultima per importanza, l’attività collegata a tutorial e corsi sui vari aspetti della cybersecurity, coordinata con il team formazione e e-learning GARR.

Come sono cambiati gli incidenti di sicurezza

Dopo il primo anno di lavoro, la distribuzione degli incidenti era per circa la metà composta da spam e il restante 50% da attacchi di tipo smurf, storicamente uno dei primi tipi di attacco, o Denial of Service (DoS) distribuiti, scansione di porte e tentativi di connessione, compromissione di sistemi e BOT IRC. Soltanto il controllo dello spam era automatizzato, mentre per gli altri tipi le modalità di controllo erano ancora molto artigianali, se non completamente manuali.

Mentre venti anni fa lo spam imperversava perchè le soluzioni efficaci per ridurlo o prevenirlo erano appena nate, negli incidenti di oggi indichiamo con la stesso nome i casi relativi alle sorgenti di spam e phishing, quali account email o PC compromessi.

Gli attacchi (DoS) non hanno quasi più origine diretta dai nodi GARR, si sono evoluti come estensione e complessità: diversificati tra quelli di tipo reflection UDP su porte classiche come DNS, LDAP, NTP ecc. e i SYN-ACK reflection. Questi ultimi sfruttano l’alta densità di servizi aperti sulla nostra rete, preventivamente mappati con cura dagli attacanti, e sono diretti per lo più contro target esterni.Il più significativo è quello sferrato a fine ottobre 2019 contro l’AS di Lottomatica e che ha coinvolto tutta la

rete GARR. Altri ancora, anche se non importanti numericamente, sembrano molto specifici nella scelta dei nodi vittima che subiscono nell’arco di pochi giorni DoS ripetuti di tipologie differenti.

Le vulnerabilità delle applicazioni web e le compromissioni di dati personali sono diventate la componente maggioritaria, e meritano una considerazione speciale come vedremo più avanti.

Come sono cambiati gli incidenti in 20 anni, con le percentuali rispetto al totale. Per i dati del 2019 non sono state contate le segnalazioni di violazione di copyright (in totale 2003), che non sono considerate veri incidenti di sicurezza.
Come sono cambiati gli incidenti in 20 anni, con le percentuali rispetto al totale. Per i dati del 2019 non sono state contate le segnalazioni di violazione di copyright (in totale 2003), che non sono considerate “veri” incidenti di sicurezza.

Aggiornamento della procedura di gestione degli incidenti

La procedura di gestione degli incidenti ha un’anima “più RFC che ISO”, e non solo perché i CERT scrivono e pubblicano la propria RFC-2350. Infatti, lo spirito con cui la procedura viene definita non è quello di una ricetta calata dall’alto, ma di un processo collaborativo in cui la comunità può dire la sua, come avviene in IETF (Internet Engineering Task Force). Perciò, anche se l’ultima versione ufficiale è del 2007, intanto GARR CERT si è adattato all’evoluzione dei problemi di sicurezza; la transizione alla nuova versione in pratica è quasi impercettibile dagli utenti. Le novità riguardano i diversi percorsi seguiti rispettivamente per i casi in cui un nodo GARR sia sorgente o vittima dell’incidente, adesso distinti esplicitamente. È stata aggiunta una parte relativa agli incidenti che coinvolgono sorgenti o destinazioni multiple, come per esempio i SYN-Flood distribuiti, usati per generare dei SYN-ACK reflection. Sono stati infine eliminati i pochi riferimenti ad aspetti interni alla gestione incidenti non più conformi alle norme vigenti, perché nel frattempo ogni tipologia di incidente ha avuto il suo inquadramento normativo, e corrisponde ad almeno un articolo in un codice di procedura dello Stato italiano.

Per snellire eventuali aggiornamenti futuri della procedura, è prevista l’aggiunta del seguente punto in fondo alla GARR AUP: i problemi di sicurezza che coinvolgono utenti e nodi della rete GARR sono gestiti con la Procedura di Gestione Incidenti costantemente aggiornata e disponibile sul sito web del CERT.

Sperimentazione di una piattaforma di cyber intelligence e analisi preventiva dei rischi

Come già accennato, è il valore dei dati la chiave per spiegare non solo le attività illecite da quando esistono, ma anche quelle legali messe in atto dai grandi protagonisti della rete. Conoscere quali e quanti dati abbiamo dispersi in rete può aiutarci a intervenire prima che si manifestino le conseguenze, di solito attraverso un incidente di sicurezza. È un modo per avere una visione complementare alle analisi di sicurezza eseguite sui nostri sistemi e sulle nostre reti e farci un’idea più completa di quello che stiamo rischiando.

Su questi argomenti, grazie alla collaborazione di un noto esperto in materia, Raoul Chiesa, stiamo sperimentando per un anno la piattaforma Risk di Resecurity Inc. come prima rete della ricerca europea. Attraverso questa piattaforma, gli APM potranno ricevere informazioni su data breaches, botnet, sistemi compromessi, relativi ai propri domini, range di indirizzi IP, email e molte altre categorie di dati, tra informazioni provenienti sia da fonti aperte che dal darkweb e valutare i rischi informatici per la propria organizzazione. Come per altri aspetti che riguardano la sicurezza, in particolare per questo che coinvolge direttamente quella dei dati degli utenti, ribadisco la necessità e il piacere di coinvolgere attivamente gli esperti della nostra comunità per verificare e accrescere il valore dei risultati. Il fatto che poco dopo la pubblicazione della notizia alcuni enti connessi a GARR si siano “offerti volontari” (e altri lasciati facilmente convincere) credo che confermi questa convinzione. E state tranquilli: ci sono ancora posti liberi!

Attacchi SMURF :: Uno dei primi tipi di attacchi DoS distribuiti

Il nome era ispirato ad una nota serie di cartoni animati, “I Puffi”. Falsificando l’IP sorgente con quello della vittima designata, si inviavano richieste ICMP (ping) a indirizzi broadcast, ossia a tutti i nodi di una rete. Se il router corrispondente non filtrava questo tipo di richieste, e fino al 1999 era la configurazione predefinita, tutti i nodi attivi della rete rispondevano alla richiesta (amplificandone cosi’ l’effetto), inviando pacchetti all’IP vittima.

DoS di tipo reflection :: Attacchi distribuiti che generano disservizi (Distributed Denial of Service)

Anche se nei dettagli i protocolli sfruttati (UDP o TCP) e i singoli servizi sono diversi tra loro, il principio di funzionamento è lo stesso. Nei pacchetti inviati, gli attaccanti sostituiscono i loro indirizzi IP con quelli delle vittime prescelte (spoofing). In funzione del servizio aperto che viene sfruttato, i sistemi che ricevono questi pacchetti riflettono, cioè rispondono, verso gli IP delle vittime. Il rapporto tra la quantità di dati riflessi verso le vittime e quelli ricevuti dagli attaccanti rappresenta il fattore di amplficazione (per i tipi di DDoS noti, da poche unità a oltre 1000) e dà una stima di quanto può essere potente e invasivo l’attacco.

Un po’ più avanti

A lungo termine, per rispondere all’escalation e alla complessità delle minacce, l’obiettivo è quello di aumentare la partecipazione attiva e il più possibile proattiva degli utenti nel processo dell’evoluzione della sicurezza a tutti i livelli, non solo come soggetti da contattare all’apertura di un incidente. Come strumenti tecnologici a supporto, stiamo valutando soluzioni proposte da altre reti della ricerca, e recentemente anche dall’Agenzia europea per la sicurezza delle reti e dell’informazione, ENISA. Per continuare in questa direzione, che si allontana dalla tendenza attuale a soluzioni centralizzate ad intelligenza autonoma, contiamo molto su una “intelligenza distribuita” e più umana tipica della comunità GARR. Questa, infatti, per sua natura è l’ambiente ideale dove sviluppare la conoscenza e l’informazione sui pericoli attuali per la sicurezza dell’IT e magari pensare anche a come evolverà il quadro della cybersecurity nei prossimi anni, con la stessa consapevolezza e sensibilizzazione di quando è cominciato tutto.

GARR NEWS N° 22 - estate 2020

Altri articoli nella rubrica


Archivio GARR NEWS