Quando la memoria diventa un problema

Una situazione diversa si verifica quando uno o più processi consumano una quantità eccessiva di memoria nel tempo. Applicazioni mal configurate, servizi che accumulano dati in memoria o programmi con perdite di memoria (memory leak) possono saturare la RAM e costringere il sistema a utilizzare intensivamente lo swap, cioè l’area del disco usata come memoria di emergenza. Quando questo accade, il sistema può diventare sensibilmente più lento, perché le operazioni che normalmente avverrebbero in memoria devono essere trasferite sul disco. Nei computer  desktop il sintomo più evidente è il rallentamento delle applicazioni e dell’interfaccia grafica; sui server, invece, possono aumentare i tempi di risposta dei servizi. Per questo motivo è utile controllare periodicamente l’uso della memoria e verificare se qualche processo stia crescendo in modo anomalo. A differenza della cache del filesystem, che viene gestita automaticamente dal kernel, il consumo di memoria da parte dei processi è un indicatore diretto del comportamento delle applicazioni in esecuzione: non trascuratela!

Analisi in tempo reale

Ci sono diversi strumenti per osservare in tempo reale come viene utilizzata la memoria del sistema, distinguendo tra quella usata dai processi, quella impiegata come cache e l’eventuale uso dello swap. Uno dei comandi più semplici è:
free -h

La colonna available che mostra è molto utile perché rappresenta la quantità di memoria che può essere allocata  immediatamente senza ricorrere allo swap. Per analisi più dettagliate è possibile utilizzare strumenti interattivi come top o htop, che permettono di osservare i processi in esecuzione e ordinarli in base al consumo di memoria. In top è sufficiente premere il tasto M per ordinare l’elenco dei processi in base alla RAM utilizzata. Htop offre inoltre un’interfaccia più leggibile e permette di filtrare facilmente i processi più pesanti. Un altro strumento utile è vmstat, che fornisce informazioni sul comportamento della memoria virtuale e sullo stato dello swap:
vmstat 5

L’intervallo di aggiornamento (in questo caso 5 secondi) permette di osservare nel tempo l’andamento dell’uso della memoria e l’eventuale attivazione dello swap. L’output sarà simile a quello mostrato qui sotto, con aggiornamenti  periodici delle principali statistiche del sistema: stato della memoria, attività dello swap, operazioni di I/O e utilizzo della CPU. Potrete così verificare rapidamente se l’utilizzo della memoria rientra nel comportamento normale del sistema o se indica un problema da approfondire.

Pubblicità di offerta irrevocabile pervenuta ed invito alla manifestazione di interesse ex art. 91 CCII (c.d. offerte concorrenti) da sottoporre ad eventuale successiva procedura competitiva, per la cessione della partecipazione pari al 51% del capitale sociale di Datamatic Sistemi e Servizi S.p.A. (“DSS” o “Partecipazione”), di proprietà di Datamatic S.r.l., in relazione alla quale è pervenuta proposta irrevocabile di acquisto al prezzo di Euro 550.000,00 (cinquecentocinquantamila/00)

Si invitano gli eventuali interessati a manifestare l’interesse all’acquisto della Partecipazione, per il prezzo base di Euro 550.000,00 (cinquecentocinquantamila/00). La manifestazione di interesse avente ad oggetto la Partecipazione dovrà pervenire entro e non oltre le ore 12:00 del 12 ottobre 2026 all’indirizzo pec carlo.pagliughi@odcecmilano.it. Si precisa che all’indirizzo segreteria@studiopagliughi.it potrà essere inviata richiesta di accesso alla Data Room, previa sottoscrizione di un accordo di riservatezza. Il presente annuncio e la ricezione di eventuali manifestazioni di interesse non comportano alcun obbligo od impegno alla alienazione nei confronti di eventuali offerenti, e per essi alcun diritto a qualsiasi titolo (mediazione o consulenza). L’invito a manifestare completo è pubblicato sul Portale delle Vendite Pubbliche e messo a disposizione a semplice richiesta.

L’annuncio completo è scaricabile cliccando qui.

Il punto di partenza è un singolo account dipendente violato. Da solo, potrebbe già offrire e-mail, contatti e documenti. Con l’IA, però, l’attaccante può porre domande in linguaggio naturale e ottenere in pochi secondi una mappa delle informazioni utili: chi ha ruoli decisionali, quali progetti sono in corso, dove si trovano fatture, quali pagamenti attendono l’approvazione e come scrivono i dirigenti.

È come lasciare un intruso in un archivio pieno di faldoni, ma consegnargli anche un assistente capace di cercare subito “tutti i pagamenti in sospeso”, “le conversazioni con la contabilità” o “i messaggi più recenti del CEO”. L’IA non viola l’account: usa però i permessi già disponibili a quell’account e rende la ricerca molto più veloce e mirata.

La fasi della simulazione

Il primo obiettivo degli aggressori è stato mantenere l’accesso senza farsi notare. Per farlo, sono state create regole automatiche nella casella di posta in grado di nascondere avvisi di login o inoltrare messaggi importanti. Sono funzioni nate per gestire meglio la posta, ma che in mani sbagliate possono impedire alla vittima di accorgersi che qualcosa non va.

Il passo successivo è il cosiddetto phishing interno. L’attaccante usa l’account reale di un dipendente per inviare al CEO un messaggio costruito con informazioni autentiche e con uno stile credibile. Non è la classica mail piena di errori: arriva da un indirizzo aziendale valido, cita attività esistenti e può sembrare perfettamente coerente con il lavoro quotidiano.

Una volta ottenuto l’accesso all’account del dirigente, anche tramite il furto del token di sessione – la chiave temporanea che mantiene aperto un accesso senza chiedere ogni volta la password – la ricerca diventa ancora più delicata. Nel test, una richiesta rivolta all’assistente AI ha fatto emergere fatture, pagamenti e flussi di approvazione, compreso un bonifico in attesa di quasi 250.000 dollari.

A quel punto è bastato preparare un messaggio apparentemente inviato dal CEO alla contabilità, chiedendo di cambiare il conto corrente del beneficiario prima dell’autorizzazione del pagamento. La richiesta conteneva dettagli reali, proveniva dalla casella autentica del dirigente e rispecchiava il suo modo di comunicare: condizioni che rendono più difficile per i tradizionali filtri e-mail individuare la frode.

La lezione non è che l’IA sia di per sé pericolosa, ma che gli account potenziati dall’IA devono essere protetti come risorse ad alto valore. Per le aziende, significa rafforzare l’autenticazione a più fattori, controllare accessi e regole di inoltro insolite, limitare i permessi dell’assistente AI e applicare verifiche fuori banda per modifiche ai dati di pagamento. Se arriva una richiesta di cambiare un IBAN, ad esempio, non dovrebbe bastare una mail: serve una conferma tramite un contatto conosciuto e indipendente.

L’Italia appare tra i Paesi più colpiti: con il 3% delle vittime ransomware segnalate, si colloca al quinto posto dopo Stati Uniti, Germania, Canada e Regno Unito. Nel nostro Paese, le organizzazioni avrebbero subito mediamente 2.755 attacchi settimanali, con un incremento del 14%. Un numero che racconta una pressione costante, non un episodio isolato.

A livello globale, il bersaglio più esposto resta l’istruzione, con 4.848 attacchi settimanali per organizzazione. Scuole e università mettono insieme migliaia di utenti, reti aperte, dispositivi personali e sistemi spesso datati: un insieme che le rende attraenti per i criminali. Seguono settore pubblico, telecomunicazioni, energia e servizi turistici, questi ultimi particolarmente esposti nella stagione degli spostamenti.

L’istruzione resta il settore più bersagliato, ma la pressione cresce su infrastrutture pubbliche, reti di comunicazione, energia e servizi connessi ai viaggi.

Il capitolo più preoccupante riguarda però il ransomware, il malware che cifra file e sistemi chiedendo un riscatto per sbloccarli o per evitare la pubblicazione dei dati rubati. Le vittime rese note dai gruppi criminali sono salite a 964, quasi il doppio rispetto a un anno prima e il 49% in più rispetto al mese precedente. I servizi alle imprese rappresentano quasi un terzo dei casi segnalati, seguiti da manifattura e beni di consumo.

In cima alla classifica dei gruppi più attivi compaiono The Gentlemen e Qilin, entrambi associati al 14% degli attacchi pubblicati, mentre DeadLock emerge con il 10%. Sono nomi che indicano organizzazioni criminali capaci di offrire ransomware “in affitto” ad affiliati: un modello simile a un servizio commerciale, ma usato per colpire aziende e chiedere denaro.

Accanto agli attacchi tradizionali cresce l’esposizione legata alla GenAI, gli strumenti capaci di generare testi, riassunti, immagini o codice. Il pericolo non dipende solo dalla tecnologia, ma soprattutto da ciò che le persone inseriscono nei prompt. Un dipendente che copia in chat un documento riservato per farselo riassumere può condividere dati di clienti, dettagli finanziari o informazioni interne senza volerlo.

Secondo i dati diffusi, un prompt su 36 proveniente da reti aziendali presentava un rischio elevato di perdita di dati sensibili; l’88% delle organizzazioni che usa regolarmente questi strumenti ha registrato almeno un’attività ad alto rischio. È come affidare un dossier a un assistente molto efficiente, ma esterno al perimetro aziendale, senza controllare quali informazioni gli si stanno consegnando.

Nei prompt aziendali finiscono spesso informazioni sensibili: dati personali e finanziari, dettagli tecnici, documenti legali e contenuti legati al personale.

L’e-mail, infine, continua a essere una porta d’ingresso decisiva. Una mail ogni 128 è stata classificata come phishing, cioè una truffa pensata per rubare password, denaro o dati; un ulteriore 20% rientrava tra spam e messaggi potenzialmente rischiosi. Il messaggio per aziende e utenti è chiaro: non esiste più un solo punto da difendere. Servono aggiornamenti, backup, filtri e-mail, formazione, controlli sugli accessi e regole chiare sull’uso dell’IA.

L’idea alla base dell’app è semplice: una persona installa Snowflake Volunteer e, se lo desidera, concede una parte limitata della propria connessione a utenti che non riescono a raggiungere direttamente la rete Tor. Tor è un sistema pensato per rendere più difficile collegare l’attività online all’identità o alla posizione di chi naviga. In contesti dove la rete è censurata, però, accedere a Tor può essere il primo ostacolo.

Qui entra in gioco Snowflake

L’app trasforma temporaneamente il telefono in un proxy, cioè in un intermediario tra due connessioni. Per rendere più complesso il blocco, Snowflake utilizza WebRTC, una tecnologia comune nelle videochiamate e nelle comunicazioni dirette tra browser e app. Agli occhi di chi controlla il traffico di rete, quindi, la connessione può assomigliare a una normale chiamata online. I collegamenti sono inoltre brevi e distribuiti tra molti volontari: non esiste una piccola lista di server fissi che un censore possa bloccare con facilità.

Un dettaglio fondamentale

Se un’autorità blocca un singolo nodo Tor, l’accesso può interrompersi. Se invece i punti di passaggio cambiano continuamente e sono ospitati da utenti comuni in molti Paesi, fermarli tutti diventa più difficile senza colpire anche servizi legittimi, come le piattaforme di videoconferenza o le chiamate via web.

Il progetto, sviluppato dall’organizzazione Bloco insieme al team anticensura di Tor, prova anche a ridurre l’impatto per chi partecipa. L’app può essere configurata per funzionare soltanto quando il telefono è collegato al Wi‑Fi e alla corrente, con un limite al numero di utenti assistiti contemporaneamente. In questo modo si cerca di evitare consumo eccessivo della batteria e dell’offerta dati mobile.

I dati riportati dal progetto mostrano una crescita della rete: da circa 1.300 proxy unici al giorno in primavera a 1.700 nel mese successivo, con picchi oltre quota 2.100. Nel primo semestre, Snowflake avrebbe registrato una media di circa 146.000 indirizzi IP volontari al giorno. Sono numeri che raccontano un’infrastruttura diffusa, basata su tante piccole disponibilità anziché su pochi grandi server.

L’app è open source, cioè il suo codice può essere esaminato pubblicamente da sviluppatori e ricercatori, ed è disponibile su F-Droid e Google Play. Prima di installarla, però, è bene fare una valutazione pratica: meglio usare una connessione senza limiti di traffico, verificare le condizioni del proprio operatore e considerare che l’app, anche con limiti attivi, utilizza rete e risorse del dispositivo.

sudo apt clean

che elimina completamente i pacchetti presenti nella cache. Un approccio più conservativo consiste invece  nell’utilizzare:

sudo apt autoclean

che rimuove solo i pacchetti ormai obsoleti, cioè quelli che non sono più disponibili nei repository configurati. Strumenti analoghi esistono anche in altre distribuzioni: dnf clean all nei sistemi Fedora o pacman -Sc nei sistemi Arch permettono di ottenere risultati simili. La pulizia periodica della cache non influisce sul software installato ma può recuperare spazio in modo immediato.

Dipendenze inutilizzate e pacchetti orfani

Un’altra fonte di residui sono le dipendenze installate automaticamente. Quando si installa un’applicazione tramite il gestore di pacchetti, questa porta con sé anche le librerie e i componenti necessari al suo funzionamento. Questo meccanismo semplifica la gestione del software, ma può lasciare nel sistema elementi che non servono più dopo la rimozione del programma principale. Nel tempo possono così accumularsi pacchetti installati come dipendenze ma non più richiesti da alcun software presente nel sistema. Questi componenti vengono spesso chiamati pacchetti orfani o dipendenze inutilizzate. In Debian, Ubuntu e Fedora, le dipendenze non più necessarie possono essere rimosse direttamente dal gestore di pacchetti con il comando autoremove. Il sistema analizza l’elenco dei pacchetti installati automaticamente e rimuove quelli che non risultano più richiesti da alcun software presente. Su Arch Linux i pacchetti orfani possono invece essere individuati con pacman -Qtd. Ridurre il numero di componenti installati non ha effetti solo sullo spazio disco: un sistema con meno pacchetti è anche più semplice da aggiornare.

Kernel vecchi e componenti storici

Molte distribuzioni mantengono anche più versioni del kernel installate, così, se un aggiornamento introduce  problemi di compatibilità con hardware o driver, è possibile avviare il sistema con una versione precedente  funzionante. Ogni kernel installato include però diversi file: la sua immagine, i moduli caricabili e l’initramfs  utilizzato durante l’avvio, che finiscono con l’accumularsi. Nei sistemi Debian e Ubuntu la rimozione dei kernel obsoleti è spesso gestita automaticamente proprio dal comando apt autoremove, che mantiene quella corrente e una precedente per sicurezza. Altrimenti, potete verificare manualmente quali versioni sono installate:

dpkg –list | grep linux-image

Prima di rimuovere manualmente un kernel, però, verificate quale versione è attualmente in uso:

uname -r

Ricordatevi, comunque, di tenere almeno una versione precedente del kernel per poter ripristinare in caso di problemi dopo un aggiornamento.

Due attacchi con lo stesso nome

Sotto la stessa sigla convivono due famiglie che hanno poco in comune. La prima agisce ai livelli 3 e 4: SYN flood, flood UDP e soprattutto attacchi di amplificazione, che sfruttano servizi mal configurati e raggiungibili da Internet (resolver DNS aperti, NTP, istanze memcached esposte) per moltiplicare di decine o centinaia di volte il traffico generato dalla botnet. Qui l’anomalia è evidente e si affronta con criteri di rete: il pacchetto va scartato prima di arrivare al server.

La seconda famiglia agisce al livello applicativo e non ha nulla di anomalo da esibire. Sono richieste HTTP formalmente corrette, con handshake TLS completato, header plausibili e spesso indirizzi residenziali presi in prestito da una botnet domestica. Il volume può fermarsi a poche migliaia di richieste al secondo, un’inezia in termini di banda, purché siano indirizzate agli endpoint giusti: la ricerca interna, il carrello, xmlrpc.php, una query string sempre diversa che rende inservibile qualunque cache. Una richiesta da quattrocento byte può costare al bersaglio una query non indicizzata su una tabella da due milioni di righe.

Valutare un cloud hosting sullo spazio disco e sulla versione di PHP è la parte facile, e le due righe che contano stanno altrove (a quale livello della rete opera il filtro e come viene contabilizzato il traffico in eccedenza). Vhosting, per restare agli operatori italiani, ha costruito la propria infrastruttura su datacenter ridondati in Italia con mitigazione gestita a monte del nodo; altri demandano il compito a un servizio di terze parti da attivare a parte. Sono due modelli diversi e la differenza si apprezza un giorno solo.

Il conto al posto del downtime

L’elasticità funziona, nel senso che fa quello che promette: aggiunge worker, istanze, container. Il punto è che non elimina l’attacco, ne cambia la valuta. Un flood applicativo contro un’architettura che scala non produce più un errore 503, produce una fattura. Il fenomeno ha un nome proprio, EDoS, Economic Denial of Sustainability, e per chi attacca ha il vantaggio di non essere immediatamente visibile: il sito risponde, i grafici del monitoraggio restano verdi, il danno emerge a fine mese.

L’elasticità, per giunta, ha un fondo. Si scalano i frontend con relativa facilità, non altrettanto il livello dati: il pool di connessioni resta un numero finito e, quando i worker appena aggiunti si accodano tutti sullo stesso database, il collo di bottiglia si sposta senza allargarsi. Scalare sotto attacco significa quasi sempre pagare di più per cedere un po’ più tardi.

Dove si ferma davvero

Il traffico ostile va scartato dove eliminarlo costa poco, cioè il più a monte possibile. Una rete anycast disperde il volume su decine di punti di presenza invece di convogliarlo su un singolo collegamento; i centri di scrubbing separano il traffico legittimo da quello di attacco prima che raggiunga l’origine; sul fronte applicativo servono limiti di frequenza per indirizzo e per sistema autonomo, e sfide computazionali che rendono l’attacco costoso anche per chi lo conduce.

Vale la pena conoscere anche la procedura che scatta quando questa catena non c’è. Di fronte a un volumetrico che minaccia il collegamento condiviso, l’operatore di rete a monte annuncia via BGP che il traffico diretto a quell’indirizzo va scartato: è il blackholing, e funziona benissimo. Non protegge il cliente, protegge la rete dagli effetti collaterali del cliente, portando a termine l’attacco con mezzi propri.

Cosa resta al proprio livello

Sul server ci sono comunque interventi sensati, a patto di sapere che filtrare a valle consuma comunque la banda in ingresso. I moduli di rate limiting di Nginx (limit_req, limit_conn) contengono i picchi per client; una cache di pagina intera che risponde senza toccare né PHP né database sposta il tetto di parecchio, perché una pagina servita dalla cache costa tre ordini di grandezza meno di una generata a ogni richiesta; normalizzare o ignorare le query string sconosciute evita che la cache venga aggirata con un parametro casuale; disattivare endpoint legacy come xmlrpc.php toglie di mezzo un bersaglio classico.

Da misurare prima, non durante

Nota pratica: il lavoro utile si fa a freddo. Serve sapere quante richieste al secondo regge il sito con la cache attiva e quante senza, quali endpoint non sono cacheabili per costruzione, e a chi va inoltrata la richiesta di mitigazione — con i contatti del provider annotati da qualche parte che non sia il sito stesso, che durante un attacco è esattamente la cosa che non risponde.

Per capire il meccanismo, basta immaginare l’ingresso di un grande negozio occupato all’improvviso da migliaia di persone che non intendono acquistare nulla, ma solo impedire agli altri di entrare. Il negozio non viene necessariamente derubato: semplicemente non riesce più a far passare i clienti veri. In rete avviene la stessa cosa, con programmi e dispositivi che inviano enormi quantità di traffico verso un sito, un’app o un’API.

Nel caso di Bluesky, la piattaforma ha parlato di traffico indesiderato diretto ai suoi server e di un disservizio durato approssimativamente un giorno. Gli utenti hanno segnalato feed che non si aggiornano, notifiche assenti, difficoltà a caricare discussioni e problemi nella ricerca. L’azienda non ha diffuso dettagli sul volume del traffico, sulle fonti dell’attacco o sulle difese adottate, limitandosi a comunicare un potenziamento delle misure di sicurezza e il monitoraggio della situazione.

A rivendicare l’azione sarebbe stato il gruppo “The Islamic Cyber Resistance in Iraq-313 Team”, descritto da ricercatori e media come legato all’Iran. Bluesky non ha però attribuito pubblicamente l’attacco a un soggetto specifico. La cautela è importante: una rivendicazione su canali come Telegram può essere un indizio utile per gli analisti, ma non costituisce da sola una prova definitiva della responsabilità.

L’episodio non sarebbe isolato. Bluesky aveva già affrontato un altro attacco DDoS su larga scala nei mesi precedenti; la ripetizione degli incidenti evidenzia una realtà scomoda per tutte le piattaforme online: anche se i dati sono protetti, basta bloccare l’accesso al servizio per causare disagi a utenti, aziende, creator e organizzazioni che lo usano per comunicare.

A prima vista sembra un dettaglio tecnico, ma ha un impatto diretto su creator, aziende e utenti. Finora, per un video tradizionale, il pubblico tendeva ad associare una visualizzazione a un interesse almeno minimo. Con il nuovo metodo, il contatore sotto al player rappresenterà soprattutto il numero di avvii: un passaggio rapido nel feed, una riproduzione automatica o un clic involontario potranno far crescere la cifra visibile.

Cosa cambia?

YouTube non ha mai indicato ufficialmente una soglia precisa per il vecchio sistema, anche se nel settore si è diffusa nel tempo l’idea che una visualizzazione valida richiedesse circa 30 secondi. Quello che cambia ora è il principio: il numero pubblico misurerà l’esposizione iniziale, non necessariamente l’attenzione. È la differenza tra entrare in un negozio e fermarsi davvero a guardare i prodotti. La piattaforma non eliminerà però le metriche più utili a capire il coinvolgimento. Nel pannello Analytics, accessibile ai creator, continueranno a essere disponibili le engaged views, cioè le visualizzazioni di chi ha scelto di continuare a guardare. Per chi lavora con i contenuti video, questo dato rimarrà più vicino alla domanda che conta davvero: il pubblico ha trovato il video interessante abbastanza da restare?

Modifiche anche lato sicurezza

La modifica riguarda anche la sicurezza informatica, perché cambiano i segnali che usiamo per valutare affidabilità e diffusione di un contenuto. Un video con milioni di visualizzazioni potrebbe sembrare automaticamente autorevole, ma non è una prova della qualità delle informazioni né del numero di persone che ne hanno compreso il messaggio. Questo vale soprattutto per contenuti sensazionalistici, truffe, fake news e video manipolati che puntano a catturare l’attenzione nei primi secondi. Per le aziende, il rischio è confondere la popolarità con l’efficacia. Un contenuto può essere aperto molte volte ma abbandonato quasi subito; allo stesso modo, un video con meno aperture ma con un’alta permanenza può avere un pubblico più interessato e più prezioso. Sponsor e inserzionisti dovranno quindi guardare oltre il contatore pubblico, valutando durata media di visione, interazioni e qualità dell’audience.

I guadagni restano invariati

YouTube specifica che la novità non cambierà i guadagni né i criteri del Partner Program: la monetizzazione resta collegata alle metriche di coinvolgimento e alle ore di visione qualificate, non al solo numero di avvii. È una distinzione importante, perché impedisce che una crescita puramente “tecnica” delle visualizzazioni si trasformi automaticamente in maggiori entrate.

Il messaggio per chi guarda è semplice: il numero sotto a un video sarà sempre meno un indicatore di fiducia. Prima di credere o condividere un contenuto, soprattutto se promette rivelazioni clamorose, è utile verificarne fonte, autore, data e conferme indipendenti. Le visualizzazioni possono indicare che qualcosa ha attirato l’occhio; non dimostrano che sia vero, sicuro o affidabile.

Analisi dell’attacco

In concreto, un attaccante può far transitare parte delle proprie attività dalla rete domestica compromessa. All’esterno, quindi, il traffico sembra arrivare dall’indirizzo Internet di una famiglia o di un piccolo ufficio, non da quello reale dell’autore. È come se qualcuno usasse il vostro citofono e il vostro indirizzo per spedire messaggi di cui non sapete nulla. Questo modello è particolarmente interessante per i criminali perché gli indirizzi Internet residenziali tendono a sembrare meno sospetti di quelli provenienti da data center o infrastrutture note per attività malevole. Non significa che il proprietario del router sia responsabile di ciò che transita dalla connessione, ma dimostra quanto un dispositivo dimenticato possa diventare una pedina utile in una catena di attacco.

Come funziona la botnet

Dysphoria sfrutterebbe dispositivi basati su Linux, prendendo di mira soprattutto sistemi non aggiornati o protetti da credenziali deboli. Le vie d’ingresso più comuni restano quelle di sempre: servizi di gestione remota lasciati aperti, password predefinite e vulnerabilità mai corrette. Il router, infatti, non è solo la scatola che porta il Wi‑Fi in casa: è il primo punto di confine tra rete privata e Internet. La botnet può sfruttare anche UPnP, una funzione che consente ai dispositivi della rete di aprire automaticamente porte sul router per facilitare videogiochi, videocamere e altre applicazioni. È comoda, ma se viene manipolata da un malware può rendere più semplice creare un accesso indesiderato dall’esterno. In altre parole, una comodità pensata per semplificare la vita digitale può trasformarsi in una porta secondaria non sorvegliata. C’è poi un dettaglio tecnico che complica la risposta: l’infrastruttura di comando della botnet userebbe registri associati a blockchain, come Ethereum Name Service e Solana Name Service. Questi sistemi possono rendere meno immediata la rimozione dei riferimenti ai server usati dai criminali, perché non seguono il tradizionale modello dei domini gestiti da un unico fornitore.

Come difendersi

Per gli utenti, la difesa parte da poche regole concrete. Il firmware del router va aggiornato quando il produttore pubblica correzioni; le credenziali predefinite devono essere sostituite con password lunghe e uniche; l’accesso remoto e Telnet vanno disattivati se non strettamente necessari. È utile controllare periodicamente anche le porte aperte e le regole di inoltro, oltre a valutare se UPnP serva davvero.

*Illustrazione progettata da Freepick