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.

venerdì 17 giugno 2022

Ondata di spam con corpo reale

Capita sovente che il nostro Osservatorio Spam incontri questa specifica tipologia di email fraudolenta, ovvero un'email inviata apparentemente da noi o da un nostro interlocutore e contenente del testo realmente inviato in passato.

 

Chi invia realmente?

A questo punto dobbiamo fare una distinzione: il mittente è davvero la nostra casella, oppure lo è solo la descrizione?

Il protocollo SMTP è un protocollo obsoleto che ha sulle spalle molti decenni, nato in un tempo dove gli attacchi informatici erano irrisori e spesso innocui. Non deve meravigliare che io possa mandare facilmente un'email fingendomi qualcun altro.

Leggendo il sorgente del messaggio posso fare una distinzione tra quello che è il campo "Descrizione" e quella che è la reale casella di posta.

Caso 1: 

From: "Barack Obama" <b.obama@whitehouse.gov> (descrizione corretta, casella corretta [alterata])

In questo caso ho potenzialmente inviato un'email a nome di Obama. La descrizione è corretta (e chiunque può scrivere quel che vuole, non è nemmeno oggetto di controllo) ed il campo della casella è stato alterato.

Presupponendo che non sia stata violata proprio la casella originaria, non ci dobbiamo preoccupare troppo di questo caso in quanto, se il MailServer ricevente è stato correttamente configurato (per effettuare check su SPF, DKIM, DMARC, rDNS PTR), si renderà conto che l'indirizzo che invia questa email non è autorizzato a farlo scartandone il contenuto.

Quindi:  

  • SE la casella è stata violata, LA riceveremo.  
  • SE è un tentativo di invio per conto di terzi e tutto è configurato correttamente, NON la riceveremo.

 

Caso 2:

From: "Barack Obama" <pippo@pluto.jp> (descrizione corretta, casella diversa)

In questo caso la descrizione è corretta, tuttavia la casella da cui arrivano le email è pippo@pluto.jp che evidentemente non è quella di Obama.

In questo caso plausibilmente è stata violata la casella di Pippo che può lecitamente inviarci email, non possiamo far nulla se non segnalare questo spam al nostro sistema antispam affinchè il dominio pluto.jp venga considerato come compromesso. Ribadisco: nella descrizione purtroppo ognuno può scrivere ciò che vuole.


Caso 3:

From: "b.obama@whitehouse.gov" <pippo@pluto.jp> (descrizione corretta, casella diversa)

Questo caso è assolutamente identico a quello di prima, ma l'attaccante ha messo nella descrizione la casella originaria. Come abbiamo visto, ognuno nella descrizione ci può mettere quel che vuole, quindi per il mailserver di destinazione questo non è e non può essere oggetto di controllo. L'utente facilmente potrà passare con il mouse sulla descrizione e scoprire che sotto, in realtà, si cela una casella diversa.

Ricordate, una cosa è la descrizione, una cosa è la casella. Sono due cose diverse ed i client spesso visualizzano solo la descrizione e non la casella, accertarsi SEMPRE della casella che ha inviato è fondamentale.


Perchè c'è del testo reale nel corpo dell'email?

Questa è una bella domanda e non è semplice rispondere. Di sicuro qualcuno ha esfiltrato il contenuto delle email ed ora utilizza queste informazioni per veicolare una campagna di spam più efficace.

Deduciamo, tuttavia, che qualora ci avessero forato la casella di posta, le email sarebbero partite con il nostro indirizzo vero, quindi se il mailserver non vede traffico, le credenziali della casella non sono state compromesse.

Rimane però un dubbio: come ha fatto un attaccante ad accedere a queste email? Possiamo dedurre qualche scenario, ma prima dobbiamo comprendere che il transito di un'email avviene sostanzialmente su 3 momenti diversi:

 

  1. Nel primo momento, il Client comunica con il MailServer e gli passa l'email da inviare.
  2. Nel secondo momento, i due MailServer comunicano tra di loro e quello mittente invia a quello di destinazione l'email.
  3. Nel terzo momento il destinatario chiede al proprio MailServer se ci sono nuove email, e quest'ultimo gli consenga la posta recentemente pervenuta.

Sono tre fasi diverse che possono avvenire sia in chiaro, sia in maniera crittografata (e quindi impedendo che chiunque possa leggerne il contenuto). Nella prima e nella terza i rispettivi client inviano le credenziali di accesso, ragione per cui è vitale che almeno queste due fasi avvengano in maniera crittografata.

 

Compreso questo, possiamo tornare al punto, ovvero "Come ha fatto un attaccante ad esfiltrare il testo delle email?". Vediamo qualche scenario:

  • La comunicazione tra i MailServer (MTA-to-MTA) non è stata crittografata, quindi un attaccante posizionato in un punto qualsiasi tra il nostro mailserver e quello del nostro interlocutore ha potuto vedere in chiaro le email esfiltrandone il contenuto. Si tratta di un classico Man-In-The-Middle o MITM Attack. E' evidente che buona prassi vuole che i mailserver siano in grado di offrire ed accettare crittografia nella loro interlocuzione.
  • Come sopra, ma causato da un'assenza di crittografia lato client di posta. Quando configuriamo un client, possiamo scegliere se utilizzare protocolli come SSL o TLS (crittografati) piuttosto che inviare tutto in chiaro. Tuttavia questo secondo scenario a mio avviso è meno plausibile perchè l'attaccante, in questo caso, avrebbe avuto accesso anche alle password (a differenza di quando due mailserver parlano tra di loro) e quindi avrebbe compromesso la casella reale ottenendo una campagna d'attacco ancor più plausibile ed efficace.
  • Un virus ad hoc può aver esfiltrato le email dal client di posta. Troppo spesso, difatti, i PC vengono più o meno adeguatamente protetti, ma non i dispositivi mobili. Per mia esperienza questo è il caso più frequente, ovvero uno smartphone con un virus in grado di accedere alle email ed estrarne il contenuto per poi essere utilizzato in queste campagne.

 

Il contrasto allo spam

Lo spam segue un andamento spesso prevedibile, composto fondamentalmente da 3 fasi che si ripetono all'infinito:

  1. Una nuova tipologia di spam, in grado di non essere completamente o parzialmente rilevata, viene propagata in rete
  2. Gli antispam identificano la nuova tipologia di spam
  3. I MailServer aggiornano il proprio motore antispam rendendo la nuova tipologia di spam inoffensiva

Andamento Spam

Queste fasi si ripetono pressochè all'infinito. Quindi è del tutto naturale che, in determinati periodi, si riceva più spam del solito. Il periodo che intercorre tra la nuova tipologia di spam e la scoperta del suo "antidoto" può durare da poche ore a delle settimane.

Vanno fatte, tuttavia, delle considerazioni:

  • Alcune tipologie di spam possono essere molto complesse da rilevare. Basti pensare ad un'email indesiderata che contenga una riga di testo ed un link. Questo tipo di spam è difficile da identificare, salvo non inasprire troppo i controlli (si veda il punto successivo) con il deleterio effetto di "catturare" anche le email lecite.
  • I filtri antispam (dopo una fase di analisi preliminare) si basano su dei punteggi. Concettualmente è prassi lavorare con un'impostazione tale da evitare che email lecite finiscano nella posta indesiderata, anche se questo provoca inevitabilmente la non identificazione di una porzione di posta indesiderata "border line". Si pensi al sistema antispam come ad una bilancia in continua oscillazione. Se lo scopo è quello di evitare di perdere email importanti, allora qualche email di spam ogni tanto può passare. Se lo scopo è quello di non ricevere assolutamente spam, allora dovremo accettare il compromesso di vedere qualche email lecita finire nella cartella "indesiderata". La grandezza delle maglie di questa "rete" è a discrezione dell'amministratore del MailServer. Personalmente ritengo che far finire email lecite nello spam abbia la controindicazione di costringere l'utente a vedersi la cartella delle indesiderate, vanificando del tutto il lavoro dell'antispam. Ragione per cui preferisco un approccio meno perentorio.

Bilanciamento Antispam

  • 5 email non rilevate su 1.000, sono un buon risultato e non c'è da allarmarsi. 5 email di spam non rilevato su 10, invece, devono destare attenzione. I numeri vanno sempre contestualizzati: a volte non diminuisce la capacità del MailServer di rilevare lo spam, ma aumenta semplicemente il numero di email fraudolente inviate verso il nostro dominio, sovente oggetto di maggiori attenzioni.
  • Un'ondata di spam può essere generata da problemi di sicurezza. Account compromessi, server con problemi, telefoni compromessi, etc. possono propagare spam ai destinatari abituali contenuti nella rubrica degli account stessi. Non è, difatti, inusuale che grandi provider possano incorrere in importanti problemi di sicurezza che poi si riflettono sulla rubrica dei propri utenti. 

 

 

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


martedì 5 aprile 2022

Kaspersky si, Kaspersky no... qualche considerazione senza troppi filtri...

Premesso: vendo Kaspersky in modalità MSP, così come vendo altre soluzioni nella stessa identica modalità e con lo stesso identico grado di certificazione. Non sono professionalmente "sposato" con nessuno ed oggi non ho alcun vantaggio nel vendere Kaspersky rispetto al suo più acerrimo concorrente. La discriminante con cui oggi vendo i miei prodotti per me è basata su scelte architetturali: ogni soluzione si abbina molto bene ad uno scenario e ad un'esigenza specifica.

Francamente, tuttavia, sono abbastanza stufo di azioni governative che alterano il libero mercato senza alcun valido motivo. Come già accaduto con Huawei, vittima di un assedio statunitense, ora è toccato a Kaspersky. E con la trasparenza con cui ho sempre affrontato questi argomenti, senza mai seguire le mode ma andando a capire e toccare con mano i dati concreti, ho deciso di andare un po' più a fondo sulla vicenda.

Tralasciamo il responsabile IT del Comune Tizio in provincia Caio, che ha avuto il suo momento di piccola gloria annunciando al mondo che lui, a differenza di fior fior di SOC, ha trovato le backdoor in Kaspersky (senza addurre alcuna prova concreta, notizia purtroppo letta mentre prendevo un caffè e che mi ha fatto letteralmente quasi strozzare dalle risate) e tralasciamo pure l'annuncio del codice sorgente Kaspersky rivelato dagli hacker (che invece era semplicemente un crawler del sito con tutto materiale assolutamente reperibile online), così come tralasciamo il guizzo Italiano che ha portato al ban del prodotto nelle PA (dopo aver barbaramente lasciato transitare in passato il nostro routing nazionale in altri paesi senza battere ciglio), ma cerchiamo di guardare i fatti. Scusate il pragmatismo

I fatti sono:

  • Nel 2018 Kaspersky ha avviato un programma chiamato Global Transparency Initiative con lo scopo di aumentare il livello di trasparenza ed essere proprio resistenti a qualsiasi pressione esterna. Sono stati creati, quindi, dei Transparency Center in Svizzera, Spagna, Brasile, Malesia e Canada dove qualsiasi autorità pubblica, partner kaspersky o cliente può accedervi. https://www.kaspersky.com/transparency-center
  • L'azienda è registrata in Gran Bretagna ed ha i Server in Svizzera... e comunque gli utenti Europei arrivano su server Europei... vediamo... è vero?

Queste sono le connessioni geolocalizzate della nostra console centralizzata Kaspersky (appena estratte dai firewall, fresche fresche):

 Ma pensa te... nemmeno una riga di log che punti in Russia...

  • Kaspersky ha ottenuto la certificazione OCSI e la certificazione SOC2 Type 1 EAL2+, Oltre alla ISO/IEC 27001:2013

https://media.kaspersky.com/en/recertification_IS0_27001.pdf

https://media.kaspersky.com/en/ISO_27001_Certificate_ENG_1-merged.pdf

https://www.kaspersky.com/about/compliance-soc2

Ok, ma che significa? Significa che il prodotto che arriva sulle nostre macchine viene preventivamente vivisezionato da organi di verifica terzi ed indipendenti (aziende "occidentalissime") al fine di garantirne, tra le altre cose, la sicurezza dei processi e che il prodotto non contenga robe strane.

  • Le forze dell'ordine possono chiedere a Kaspersky il rilascio di informazioni sensibili? Si, come per ogni produttore. Ma queste vengono attentamente validate, ci deve essere un motivo concreto e legalmente consentito affinchè questo avvenga, e comunque queste informazioni riguardano casi specifici e non certo l'integrità del prodotto. Sono pubblicati inoltre dei rapporti di trasparenza, questo è uno: https://media.kaspersky.com/en/reports/law-enforcement-and-government-requests-report-h2-2021.pdf  
  • ...e la Russia può chiedere informazioni a Kaspersky o addirittura vantare un suo diritto ad utilizzare Kaspersky in maniera offensiva? Ovvero, la Russia può costringere Kaspersky a far qualcosa? Dalle FAQ ufficiali del produttore si legge di una valutazione legale indipendente che Kaspersky ha commissionato (reperibile qui https://media.kasperskydaily.com/wp-content/uploads/sites/92/2015/02/02060120/REPORT-OF-PROF-DR-KAJ-HOBER.pdf ) in cui emerge che Kaspersky, non essendo un'azienda che offre servizi di comunicazione, ma essendo un'azienda privata, non ha alcun obbligo in tal senso.

 

Qualche ulteriore dubbio è possibile approfondirlo qui alle FAQ ufficiali del produttore: https://support.kaspersky.it/faq/2022hotline

 

E' evidente, qualsiasi software di questo tipo lavora ad un livello di dettaglio così intimo da poter muovere qualsiasi azione sulla macchina che protegge. Qualsiasi software con privilegi elevati potenzialmente può far tutto. Cosa ci mette al sicuro, ad esempio, da un dipendente infedele all'interno della struttura del produttore? I processi certificati, le certificazioni esterne, gli audit indipendenti e la storia del produttore. Intendiamoci, gli incidenti di sicurezza capitano a tutti, ma da qui a considerare un prodotto alla mercè di un governo ce ne passa.

Personalmente, e ripeto che non ho alcun interesse di parte vendendo anche persino il maggior concorrente di Kaspersky, avverto il sentore di una profonda ingiustizia palesatasi davanti ai miei occhi. Non ritengo possibile che un'azienda sul mercato da 25 anni, con 4000 dipendenti e operante in 200 paesi si possa mettere a far scherzi come se fosse il ragazzetto che sviluppa il software XYZ che tutti scaricano alla leggera. Tutto questo mina un principio fondamentale: mina la libertà di poter comprare un server Huawei, mina la libertà di poter comprare un EndPoint Kaspersky. E domani che altra libertà verrà minata? Quella di utilizzare una distribuzione Linux? Quella di acquistare uno switch Tizio? Quella di utilizzare il software di CAD di Sempronio? Quella di poter acquistare lo smartphone Cinese?

A proposito... tutti i software che girano con privilegi elevati sui tuoi sistemi possono vantare gli stessi iter certificativi indipendenti di Kaspersky? 

Se non lo vogliamo comprare, facciamolo perchè il sistema di lucchetti è più complesso delle GPO, facciamolo perchè i log a volte non sono totalmente esaustivi, facciamolo perchè le whitelist sono complicate o facciamolo perchè un altro prodotto ci da funzionalità particolari di cui sentiamo la necessità. Ma non facciamolo perchè abbiamo paura possa essere potenzialmente pericoloso, perchè a questo punto non dovremmo acquistare nessun antivirus, anzi, dovremmo spegnere i computer, spegnere i server e tornare a fare le fatture con la carta carbone. Fin quando qualcuno non ci dirà che la carta carbone è tossica, allora sì, lì saremo in guai seri.


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

mercoledì 23 febbraio 2022

Come vengono gestite le mie credenziali amministrative da parte dei miei fornitori?


Questa è senza ombra di dubbio la domanda più sottovalutata del panorama della sicurezza informatica aziendale.

Ogni Azienda ha svariati fornitori, da chi si occupa dell'infrastruttura IT a chi si occupa della parte gestionale, da chi mette mani sulle stampanti a chi gestisce i macchinari produttivi o, perchè no, anche i marcatempo. A livelli diversi e (si spera) con accessi diversi, la fiducia riposta nel proprio fornitore è pressochè cieca. Le credenziali in possesso dei propri fornitori strategici (principalmente IT e Gestionale) sono a tutti gli effetti le "chiavi del regno" e possono causare, se in mani inopportune, un disastro inestimabile.

Nel corso di questi miei primi 20 anni di IT Security ho avuto modo di constatare che troppo spesso i fornitori di servizi dedicano alle credenziali dei propri clienti la stessa attenzione che dedicherebbero alla propria lista della spesa ignorando quanto i fornitori siano oggetto di attenzione da parte dei gruppi "hacker" e quanto queste informazioni possano potenzialmente anche far chiudere aziende.

Al di la delle normative vigenti in materia di GDPR e Privacy, le principali domande che un fornitore dovrebbe porsi sono:

  • Se la mia postazione viene compromessa, si accede ai dati sensibili dei Clienti?
  • Se la mia infrastruttura viene compromessa, fino a che livello i dati sensibili non vengono trafugati? E oltre quale livello accadrebbe l'inevitabile? (ho creato un'architettura a livelli di accesso?)
  • Sulle macchine che trattano questi dati, che software vado ad installare?
  • Se un mio dipendente va via o si mostra infedele, ho una procedura di gestione efficace?
  • Le credenziali sono differenziate per Cliente e per Servizio? Oppure utilizzo password condivise?
  • Possiedo strumenti in grado di capire se ho problemi di sicurezza all'interno della mia infrastruttura?

 

Sul terzo punto si apre un mondo. Indubbiamente tendiamo a fidarci troppo dei software che installiamo. Proviamo a portare due episodi noti:

  • Settembre 2016: Il software di teleassistenza Ammyy (parente di funzionalità di Teamviewer o Anydesk) viene compromesso. Tutte le postazioni con Ammyy vengono attaccate da un ransomware.
  • Dicembre 2020: Il software di network monitor, utilizzato da moltissimi fornitori di servizi IT, viene compromesso. Tutti i fornitori di servizi IT che utilizzavano il noto software e tutti i relativi clienti vengono compromessi, i dati esfiltrati e i server bloccati. Si parla di centinaia di migliaia, forse milioni di server compromessi, Governi e chi più ne ha più ne metta. https://www.agi.it/blog-italia/cybersecurity/post/2020-12-24/hackeraggio-solar-winds-sicurezza-cibernetica-10803567/

 

Come un cane che si morde la coda, anche un fornitore di servizi IT ha dei suoi fornitori e software che vengono a loro volta utilizzati. Essi non sono esenti da problemi e, anzi, quanto più noti sono più divengono oggetto di attenzione da parte dei gruppi criminali. La sicurezza delle infrastrutture passa, quindi, per il ragionevole sospetto che qualcosa, all'improvviso, possa andare storto. 

Questo sotto è un esempio di compartimentazione per, ad esempio, un'azienda che eroga servizi IT ai propri Clienti accedendo sia alle postazioni di lavoro mediante software di teleassistenza, sia su apparati critici (Server, Firewall, Sistemi di Backup, etc.).

In caso di compromissione della macchina con i software "non privati" installati, non vi sarà comunicazione con le aree che invece contengono le credenziali.

Sull'accesso ai sistemi di backup, poi, si apre un altro capitolo. Essi dovrebbero avere aree isolate, credenziali totalmente differenti, etc. etc... ma questa è un'altra storia.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è 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.