Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

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

giovedì 23 dicembre 2021

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.

 


venerdì 17 dicembre 2021

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.