Performance: differenze tra iptables e nftables

Recentemente, grazie al progetto honeypot (discusso nell'articolo precedente) stiamo maneggiando una mole importanti di indirizzi IP da blacklistare. Con l'aumentare del numero, degradano drammaticamente le performance.

Condivido con i più esperti questo raffronto che ho realizzato oggi:

 

Throughput senza alcuna regola di firewalling:

 su questa macchina:

Il microserver ha 4 interfacce in bridge, il test è dall'host A all'host B con di mezzo il microserver. Quindi è stato abilitato ovviamente a livello di kernel:

echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo "br_netfilter" >> /etc/modules

iptables

Caricamento entry 

Ogni ip viene blacklistato in ingresso ed in uscita, con il logging. Pertanto ogni entry è da moltiplicare x4:

Le operazioni di caricamento sono durate davvero troppo e ci siamo fermati a circa 12000 ip blacklistati.

Le performance sono purtroppo drammaticamente distanti rispetto ad nftables, ma va detto che abbiamo abilitato il LOG sulle regole che, di fatto, raddoppiano con iptables le policy. 

12.000 ip blacklistati (x4, quindi effettivi 61858 policy) sono stati caricati in 11.000 secondi circa.

 

Throughput

 

Con circa 62k policy (per ogni ip c'è la policy di log in ingresso, log in uscita e blocco in ingresso ed in uscita) iptables crolla drammaticamente da 950Mbit a circa 5Mbit.

Senza log e policy solo in ingresso (-s)

Proviamo quindi ad alleggerire e carichiamo 41670 ip blacklistati in ingresso solamente, senza regole di log:

41670 policy effettive caricate in

Ancora non ci siamo.

 

nftables

Caricamento entry

Ogni ip viene blacklistato in ingresso ed in uscita, con il logging. Pertanto ogni entry è da moltiplicare x2 in quanto il logging è incluso nella policy:

35.535 ip blacklistati (x2) sono stati caricati in 460.1 secondi.

 

Throughput

IPSet

Per risolvere i problemi di performance, ipset è un tool che interagisce a livello kernel e si occupa di strutturare meglio (anche grazie a meccanismi avanzati di cache) le migliaia di policy.

 

Ecco i risultati:

 

 

 

 

Chiaramente si evince come al superamento delle 1000 policy sia assolutamente più conveniente utilizzare ipset, su tutta la linea.

Integro con questa interessante tesi di laurea che ho trovato online effettuando ricerche in merito: http://www.diva-portal.org/smash/get/diva2:1212650/FULLTEXT01.pdf

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

 

Le prime 2 ore di un server pubblico... un po' di statistiche per farci riflettere.

Cosa succede ad un server quando lo pubblichiamo su internet? IP nuovo... server nuovo... ma che vuoi che accada? Forza... vediamo un po'...

HoneyPot

Di recente abbiamo messo in piedi una rete di 13 HoneyPot in 13 nazioni diverse. I server HoneyPot sono dei server esca che espongono servizi trappola volontariamente vulnerabili così da farsi attaccare e raccogliere dati. Queste informazioni vengono da noi raccolte per poi essere catalogate per stilare una raccolta di indirizzi IP a cui viene assegnata una bassa reputazione. Il fine è di trasferire queste informazioni a oggetti (firewall o filtri hardware) in grado di bloccare questi IP a monte, prima che essi movimentino qualsiasi operazione verso i servizi leciti.

L'esperimento

Ebbene, accendiamo uno dei 13 HoneyPot su un indirizzo nuovo di zecca. Giusto il tempo di configurarlo e sistemare le esche... cosa avrà raccolto nelle sue prime due ore operative? Quanti attacchi vuoi che abbia mai preso questo server?

Nelle prime 2 ore di vita, il server ha ricevuto più di 5.400 attacchi sui servizi esposti e che è in grado di riconoscere. Che ovviamente sono solo una infinitesimale parte dei servizi che un server può esporre.

Attaccanti univoci

Entriamo nel dettaglio. "Certamente molti attacchi provengono dagli stessi IP"... nì... Dal grafico evinciamo che in media ogni IP ha veicolato circa 4 attacchi, il che significa che non siamo stati presi di mira da qualcuno in particolare, ma da tanti che fanno questo da mattina a sera mediante degli automatismi.

Geolocalizzazione degli attacchi

Andiamo a vedere chi ci attacca... maddai, sicuramente arrivano tutti da una zona... e invece no. Altro luogo comune da sfatare, gli attacchi arrivano da ovunque. Server forati utilizzati come ponte, VPS, telecamere e oggetti IoT vulnerabili, router vecchi, NVR per videosorveglianza (molto gettonati, devo dire)... qualsiasi oggetto può essere utilizzato, e chi ne risponde è il titolare della connessione che ospita il device vulnerabile.

Va detto, qui siamo stati particolarmente sfortunati, per mia esperienza normalmente la Turchia è un paese da cui provengono meno attacchi rispetto a Russia e USA.

Servizi e tipologia degli attacchi

Andiamo a scoprire quali servizi vengono presi di mira...

The winner is SAMBA! Aaah... che bello avere i propri file sempre con se anche fuori casa. Ma a chi vuoi che importi se espongo il mio filesystem? Bhè, a quanto pare a molti.

Avete presente poi quella stampante vecchiotta che lavora solo con SMBv1 ? Quel protocollo vecchio che quei cattivoni di Microsoft disabilitano ad ogni aggiornamento perchè vulnerabile e facile facile da forare? Eccolo qui...

Cosa abbiamo qui? Uh... anche il protocollo RDP... Quello che vogliamo a tutti i costi abilitare per accedere da casa al proprio server o al proprio computer... si si, proprio quello che "eh ma ogni volta devo stare a cliccare qui su Start VPN... inaccettabile!!!". Eh... mi sa che invece è proprio necessario... Perchè si da il caso che la maggior parte dei ransomware si prende proprio da lì, da attaccanti che hanno compromesso il server che esponeva il protocollo RDP (Desktop Remoto) senza VPN e crittografia.

Nota di colore, nelle prime 2 ore non ci hanno attaccato il famigerato log4j, ma comunque mentre sto scrivendo questo articolo già sono arrivate decine di tentativi.

Attacchi alle password

La mia password è inattaccabile!! Non serve l'autenticazione a due fattori!!! Ok... questi sono i tentativi (i maggiori, l'infografica li evidenzia in base al numero) arrivati in solo 2 ore... (sopra username e sotto password)

OS Focus

Maddai, non serve aggiornare Windows 7... ok...

Ah... quindi serviva?

Serve proteggere il proprio perimetro con un sistema di filtraggio supplementare?

Il grafico non lascia spazio a dubbi. Assolutamente si, motivo per cui la nostra area R&D è impegnata nello sviluppo di un sistema di filtraggio a sè stante, una blackbox che fa solo questo. Non è un firewall configurabile, ma un sistema di pre-filter in bridge.

Conclusioni

Faccio ormai da molti anni questo mestiere, con la speranza di riuscire a farlo al meglio delle mie possibilità e delle mie capacità, con passione e impegno. E nonostante sia un ventennio che mi occupo di questo, onestamente sono abbastanza sorpreso. Dall'ultima analisi che avevo fatto mi aspettavo sì un numero elevato di attacchi, ma non così elevato. Nell'ultimo anno sostanzialmente si sono triplicati, ma la cosa abbastanza sorprendente è la rapidità con cui gli attacchi hanno raggiunto un server su un nuovo IP.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

Bande sempre più performanti... ok, ma c'è un punto in cui casca l'asino! Parliamo di peering.

 Oggi parliamo di Peering (in maniera molto superficiale e con linguaggio adatto anche ai neofiti) per capire cosa accade realmente quando navighiamo o esponiamo dei servizi.

Oramai siamo abituati a connettività in fibra da 100, 200 e addirittura in Gigabit o 2,5 Gigabit. Siamo altrettanto abituati ad avviare uno speed test e darci una pacca sulla spalla quando leggiamo valori coerenti con quanto abbiamo acquistato. Una cosa che, tuttavia, non sarà scritta in nessun contratto, è quanto il nostro operatore è performante nel peering con altri operatori. Un esempio? Quando uno speed test restituisce valori bassi, in genere "bolliamo" la cosa con "il server su cui sto facendo il test è scadente". No, non sempre, anzi! E ora cerco di spiegarvi perchè.

Facciamo un passo indietro... cosa accade quando navighiamo?

Molto brevemente: poniamo il caso di voler contattare www.google.it. Tra il nostro client e i server di google ci saranno molti punti di routing (hop) che dovremo attraversare. Alcuni saranno interni al nostro operatore, altri saranno interni all'entità che vogliamo contattare (o Autonomous System, che nell'esempio è Google), al centro di essi vedremo tipicamente un Internet Exchange che si occupa di mettere in comunicazione i maggiori AS (Telecom, Vodafone, Wind, Fastweb, ma anche Google, Facebook e tutti quei operatori che hanno investito e deciso di collegarsi "direttamente" ai "fulcri" su cui si snoda la rete internet, ovvero i punti di interscambio) con degli accordi di Peering. I puristi non si scandalizzassero della banalizzazione e della non differenziazione tra Peering Privato e Peering Pubblico: è un articolo per neofiti!

Volendo schematizzare, quindi, lanciando un tracert da una connettività A (su fastweb) ad un punto B (su vodafone) nel nostro caso avremo i seguenti punti di routing:

 

I primi punti (omessi nell'immagine) sono il nostro router ed i router del nostro operatore. Gli ultimi punti (sempre omessi) sono, specularmente, i router dell'operatore e il router della connettività finale. Ma al centro avviene una magia: tutti i maggiori operatori si incontrano in uno o più Internet Exchange e comprano porte su switch (router) con cui smistarsi il traffico.

Nell'esempio di cui sopra, è plausibile pensare che 93.63.100.145 sia il router di fastweb al MIX-IT e 217.29.67.27 sia il suo corrispettivo di Vodafone. Il MIX ( https://www.mix-it.net/ consiglio un giro sul sito per maggiore approfondimento) è uno degli snodi italiani più importanti in cui questo avviene.

 

Dove casca l'asino?

Gli operatori, quindi, comprano delle porte e delle bande per smistarsi il traffico tra di loro. Pertanto, fin quando dall'operatore A finisco sempre sull'operatore A, il routing sarà interno. Quando dovrò attraversare il perimetro del mio operatore per contattarne un altro, dovrò necessariamente e ovviamente passare da un AS ad un altro.

Per farsi un'idea di quanto gli operatori hanno investito, questo straordinario sito riporta i Peer: https://peeringdb.com/

Ad esempio questi sono i Peer nel punto di interscambio di Francoforte: https://peeringdb.com/ix/31 (a destra le velocità).

Perchè uno speed test su server diversi restituisce risultati molto diversi?

Perchè il server è scadente? No, nella maggior parte dei casi no. Dopo tutta questa spiegazione, abbiamo gli elementi per dire che il peering potrebbe averci messo lo zampino.

Quando facciamo uno speed-test tipicamente finiamo su di un server del nostro stesso operatore. Quindi facciamo un bellissimo speed test in una condizione ottimale. 

Qui, ad esempio, Vodafone su Vodafone MI:

 

 

Ma quale percentuale di siti o servizi internet nel mondo si trovano ospitati per coincidenza proprio sul nostro operatore? Una percentuale irrisoria (a prescindere da quanto grande possa essere il nostro operatore), quindi potremo dire che nel 99% dei casi la nostra navigazione uscirà dal nostro operatore e attraverserà il suo perimetro, pertanto questo nostro speed test sarà sostanzialmente inutile.

 

Proviamo a fare uno speed test, sempre dalla nostra connessione di esempio, su OVH Graveline, uno dei provider di servizi in cloud più importanti d'europa (e su cui verosimilmente ci si trovi realmente in qualche maniera a far del traffico):

 

 

 

Proviamo a testare un salto di operatore andando, sempre dalla stessa connessione dell'esempio Vodafone, verso Wind:

 

 

 

Ora proviamo dalla stessa su di un server di un piccolo operatore locale (che certamente non ha le economie necessarie a comprare Terabit di banda negli Internet Exchange):

Non mi fraintendete, l'articolo non vuole puntare il dito verso un operatore specifico (anche perchè noi non abbiamo gli elementi per dire che la caduta di performance sia colpa dell'uno o dell'altro operatore): lo scopo è solo didattico.

Conclusioni

Capite bene che la velocità è relativa e condizionata da molti fattori. Fare uno speed test ci da solo un aspetto (condizionato, inoltre, dal carico di quel momento), e normalmente si tratta anche di un aspetto abbastanza aleatorio. Non c'è una risposta precisa alla domanda "si, ok, ma la mia connessione a quanto va?". La risposta più corretta è "dipende da te, dipende dal tuo interlocutore e dipende anche e soprattutto da quanto i rispettivi operatori hanno investito nel traffico di interscambio".

Di sicuro rimane sempre valido il consiglio, ad esempio, di interconnettere in VPN sedi diverse della stessa azienda possibilmente utilizzando sempre lo stesso operatore, proprio per evitare passaggi e latenze supplementari.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

Che succede? Attacchi, attacchi ovunque! Ma spesso la colpa non è dei clienti!

•  22 Ottobre 2021: San Carlo viene attaccata da una cyber-gang, parte dei dati vengono trafugati e pubblicati in rete a dimostrazione della violazione (carte di identità, dati di produzione, numeri di telefono, etc.). Viene chiesto un riscatto a scopo estorsivo. https://milano.repubblica.it/cronaca/2021/10/26/news/attacco_hacker_san_carlo_azienda_patatine_chiesto_riscatto_ransomware_gang_conti-323808439/

• 21 Ottobre 2021: SIAE viene attaccata, i dati (estremamente sensibili) di autori, cantanti e personale vengono trafugati e viene chiesto un riscatto di 3 milioni di euro. https://www.ilsole24ore.com/art/attacco-hacker-siae-esfiltrati-dati-chiesto-riscatto-AE5HBGr?refresh_ce=1
  

• 20 Ottobre 2021: L'IRAN subisce un attacco informatico che blocca le stazioni di rifornimento di carburante, bloccando di fatto l'intero paese. https://www.redhotcyber.com/post/l-iran-%C3%A8-a-secco-di-carburante-a-causa-di-un-attacco-informatico

Anche alla meno tecnica cronaca generalista certamente non è mancato di sottolineare l'attacco informatico a Regione Lazio, alla struttura sanitaria di San Giovanni Addolorata a Roma, a Luxottica e persino alla nota multinazionale informatica Accenture.

E nel nostro mondo più locale, personalmente in media ricevo un paio di telefonate a settimana di imprenditori che hanno prima sottovalutato il problema e poi si sono trovati ad essersi amaramente pentiti, con dati persi e quella sensazione di smarrimento che hai quando improvvisamente qualcosa che davi per scontato diventa (spesso) irrimediabilmente perduta.

Che succede? Succede che la consapevolezza che la sicurezza informatica sia un cardine delle attività produttive sta certamente aumentando, ma non sufficientemente. Ieri per l'ennesima volta sollecitavo una soluzione di backup in cloud ad una S.p.A. che non ne vuole proprio sapere di investire una quota irrisoria per un salvagente così importante.

Dal World Economic Forum la sicurezza informatica è stata inserita tra i principali rischi per l’economia globale. E' evidente: ci troviamo in un momento storico in cui non è più pensabile sottovalutare il problema, così come non è più pensabile lasciare la serranda e le porte di accesso alla propria azienda aperte di notte. 

 

Cari tecnici, spesso la colpa non è del cliente...

Va detto con estrema onestà intellettuale: ciò che è meno evidente è che non tutti gli operatori IT hanno la sensibilità e le competenze giuste per occuparsi di sicurezza. Così come un elettrauto non è solitamente in grado di riparare un paraurti ed un cardiologo non è un ortopedico, a prescindere da chi fa la parte gestionale o hardware, un supervisore della sicurezza delle infrastrutture IT potrà dare certamente un parere più specialistico e accurato per evitare errori spesso fatali (backup crittografabili, accessi lasciati aperti, permessi generosi, etc.). 

Nella stragrande maggioranza dei casi che mi trovo ad analizzare, l'incidente di sicurezza era estremamente evitabile e causato, perlopiù, da tecnici che mettono in atto pratiche francamente sconsiderate. In oltre vent'anni di esperienza, posso stilare un piccolo elenco di errori che spesso i tecnici (IT interni o aziende esterne) commettono in relazione alla sicurezza delle infrastrutture informatiche:

1. "comodità": "nnnah, devo fare un tunnel vpn per accedere al desktop remoto? Troppo impegno!"
2. "sottovalutazione": "non ho niente da nascondere! Che gliene importa dei miei dati!"
3. "ignoranza": "Tunnel chee? Io giro la 3389 e pace."
4. "errore umano": Questo caso è più raro, ma accade. Apro una porta sul firewall che mi serviva per testare qualcosa, la lascio aperta e dopo qualche mese diventa un ricettacolo di attacchi. Motivo per cui quando i miei tecnici installano un firewall, un primo tecnico lo installa e configura ed un secondo tecnico fa "pelo e contropelo" alla configurazione del primo. E randomicamente i firewall vengono ricontrollati da cima a fondo.
   
5. "sottomissione al cliente": "io ho proposto di avviare un Tunnel VPN... ma il cliente non vuole sapere di fare un click in più!".
   

E su quest'ultimo punto davvero ci sarebbe da scrivere un libro... Vuoi la sicurezza? Allora gioco mio e regole mie. Se invece il cliente proprio non ne vuole sapere di adottare delle pratiche corrette, mi permetto di suggerire un piccolo trucco che funziona sempre: vuoi la comodità e fare di testa tua? Allora mi firmi una liberatoria con assunzione di responsabilità. Non la firma nessuno.

Sulla sicurezza non si scherza. Andiamo sempre più verso un mondo informaticamente duro, complesso ed ostile. Facciamocene una ragione. Gli sforzi fatti oggi, vengono spesso premiati in futuro con uno sterile stato di "non succede niente". Agli occhi dei meno attenti "tutto funziona" è poca cosa, agli occhi di un esperto di sicurezza è certamente la soddisfazione più grande. Apprezziamo il "non succede niente"!

 

 

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

Le botti di ferro non esistono... Qualche riflessione sui ransomware recenti e gli attacchi mirati su Regione Lazio

Cosa sta accadendo nel mondo dei ransomware?

Andiamo con ordine, proviamo a dare un rapido sguardo a cosa accaduto a Regione Lazio.

Un gruppo di criminali ha attaccato il sistema sanitario di Regione Lazio attraverso l'infezione di una macchina di un tecnico che, quindi, aveva privilegi elevati. L'attacco ha messo fuori uso tutti i sistemi di backup, inclusa la tape library (almeno, da quanto ci è dato sapere).

La Tape Library è, per chi non lo sapesse, un sistema a cassette (tape) che vengono ciclate da un sistema meccanizzato all'interno di un "mangianastro" con lo scopo di mantenere delle copie di backup. I sistemisti affezionati al sistema lo richiedono ancora, seppur via via sempre con meno fermezza, considerandolo un sistema più sicuro dei NAS normalmente utilizzati allo scopo. Software come veeam backup si poggiano sui driver della tape e ne utilizzano le funzionalità per stoccare tipicamente copie di backup precedentemente effettuati sui NAS. Tecnicamente si tratta di un backup del backup, ma poco cambia. Oggi è utile? Non lo è? Personalmente non amo particolarmente questo strumento in quanto estremamente lento e costoso, ma andiamo con ordine.

Come molti sanno, un dato cancellato non lo è realmente fin quando quello spazio non viene sovrascritto (volontariamente o involontariamente) da altri dati. E' evidente, chi attacca un sistema, si assicura che i backup non vengano solo eliminati/crittografati, ma anche sovrascritti così da risultare effettivamente irrecuperabili. Questo è ovviamente accaduto su ogni fronte, tuttavia la Tape Library è un elefante lento e macchinoso, sovrascrivere tutto potrebbe richiedere svariati giorni... e poi diciamoci la verità, questo sistema è conosciuto appena, è "roba vecchia", "dai sù... basta una cancellazione dei nastri e pace" avranno pensato.

Quando tutto era perduto, gli specialisti hanno recuperato, invece, tutto quanto proprio dalla tape library che era stata sì cancellata, ma non sovrascritta. (ripeto, almeno così ci è dato sapere, ma a mio avviso è tecnicamente plausibile).

I sostenitori della Tape Library di tutto il mondo hanno stappato bottiglie di spumante agitando il proprio dito di biasimo esclamando "ve l'avevo detto io!!! E voi che non volevate spendere 10, 15 o 30 mila euro di tape library!!". Bhè, come dargli torto... ma a mio avviso la lezione è diversa.

I detrattori della Tape Library, invece, hanno saggiamente fatto notare che quindi la tape (ritenuta inviolabile e "offline") è vulnerabile tanto quanto i NAS, nè più nè meno. Ed è solo per pigrizia che gli attaccanti non hanno investito tempo su questo strumento... state certi che non accadrà più, perdere qualche decina di milione di dollari per un errore è un monito più che sufficiente ad indottrinare generazioni di attaccanti per qualche decennio almeno.

L'attacco ai sistemi di Regione Lazio ci ha insegnato qualcosa, motivo per cui la direzione che ha preso il GDPR circa la necessità di rendere noti i dettagli degli attacchi informatici è da me estremamente condivisa non solo per motivazioni legate ad eventuali lesioni derivanti dall'utilizzo improprio dei dati, ma anche per raccogliere eventuali errori e mettere in atto contromisure adeguate alla rapida evoluzione che il settore sviluppa. Ci ha insegnato che il vecchio detto che "solo oggetti spenti sono sicuri" (più o meno, al netto di WoL), è vero. E lo è sempre più. A tal punto che il backup totalmente offline o in un cloud a sè stante è una risorsa fondamentale. A patto di non commettere errori del tipo "portarsi il disco in chiaro a casa e farselo rubare dalla macchina". Un evergreen.

 

Certamente ci saranno nuove compromissioni e nuove contromisure da adottare, nessuno sa cosa ci attende nel futuro della sicurezza delle infrastrutture informatiche, ma di certo l'analisi degli attacchi gioca un ruolo fondamentale per strutturare una difesa sempre più attenta. Ed è certamente positivo che la sensibilità delle aziende stia crescendo, così come anche gli investimenti. Finalmente si sente la consapevolezza che quello che difendiamo non è "il server", ma il patrimonio informatico aziendale e che senza di esso un'azienda può persino cessare la sua attività. 

 

Sorprende, infine, che questi criminali, alla luce delle profonde radici etiche su cui l'hacking basa le sue origini, non abbiano sviluppato il benchè minimo senso di coscienza. Obiettivamente, come si può bloccare un sistema sanitario in piena campagna vaccinale? Come si può far chiudere un'azienda che dà lavoro a centinaia di famiglie? Come puoi bloccare un ospedale? Davvero si può diventare così inumani? Tu, attaccante, non avrai mai bisogno di un ospedale? Sono dubbi che non possono non assalire chi crede profondamente in quelle radici così onorevoli poc'anzi citate.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.