Opera One introduce Paste Protect, la funzione nativa che blocca i codici malevoli ClickFix prima che finiscano negli appunti di sistema.
L'articolo Opera presenta Paste Protect proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con Licenza CC BY-NC 4.0

🔗 Leggi il post completo

Paper Clip è un'app open source che modifica titoli, autori e metadati PDF con un’interfaccia GNOME intuitiva.
L'articolo Paper Clip l’app open per gestire metadati dei PDF su Linux proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con Licenza CC BY-NC 4....

🔗 Leggi il post completo

Ogni settimana, il mondo del software libero e open source ci offre una moltitudine di aggiornamenti e nuove versioni di software. Anche se non tutti sono di grande rilevanza, molti di questi possono risultare...

🔗 Leggi il post completo

Un attore APT mai documentato prima, battezzato Armored Likho, sta colpendo agenzie governative e il settore elettrico in Russia, Brasile e Kazakistan con un nuovo infostealer Python chiamato BusySnake. Kaspersky, che ha pubblicato l’analisi tecnica il 3 luglio, descrive un toolkit modulare, offuscato con PyArmor Pro e in parte generato con l’assistenza di strumenti di intelligenza artificiale: un caso di scuola di come lo spionaggio informatico stia adottando l’AI-assisted malware development anche nelle campagne di fascia media.

Chi è Armored Likho

Armored Likho non è un gruppo esordiente: secondo Kaspersky, il suo profilo operativo mescola campagne a sfondo finanziario contro privati con operazioni di cyberspionaggio mirate contro organizzazioni pubbliche e infrastrutture critiche. È proprio questa doppia natura — cybercrime opportunistico e intelligence gathering mirato — a rendere l’attribuzione complessa e la minaccia particolarmente insidiosa: la stessa toolchain può colpire un privato cittadino per rubare credenziali bancarie o un ministero per sottrarre documenti riservati.

I ricercatori segnalano possibili sovrapposizioni con un cluster tracciato da BI.ZONE con il nome Eagle Werewolf, attivo almeno dal maggio 2023 e storicamente focalizzato su enti governativi e della difesa, in particolare organizzazioni coinvolte nello sviluppo e nella produzione di droni (UAV). Nel febbraio 2026 Eagle Werewolf era già stato osservato compromettere un canale Telegram dedicato al mondo dei droni per distribuire il RAT AquilaRAT tramite un dropper Rust travestito da checklist per l’attivazione di dispositivi Starlink. Le sovrapposizioni tecniche tra AquilaRAT e BusySnake — stessi schemi di ricezione dei task dal C2, stessa modalità di persistenza tramite scheduled task, endpoint di comunicazione simili — rafforzano l’ipotesi che si tratti dello stesso ecosistema di sviluppo, se non dello stesso gruppo.

La catena d’attacco

Il vettore d’ingresso resta il più classico: email di spear-phishing con esche legate a comunicazioni governative ufficiali o programmi sociali, che distribuiscono un archivio RAR contenente eseguibili droppati da un repository GitHub. Il dropper crea due file VBScript, uno dei quali cancella le tracce dell’esecuzione iniziale mentre l’altro registra un’attività pianificata (scheduled task) per lanciare lo stealer ogni cinque minuti, mascherata da un innocuo processo di sistema chiamato WindowsHelper — la stessa convenzione di naming usata da AquilaRAT con MicrosoftOfficeUpdate.

Una catena alternativa sfrutta invece file di collegamento Windows (LNK) che abusano di CVE-2025-9491 (nota anche come ZDI-CAN-25373), la vulnerabilità nella gestione degli shortcut corretta da Microsoft nel Patch Tuesday di novembre 2025 ma già sfruttata in passato da una dozzina di gruppi APT dal 2017. In questo scenario, il file LNK innesca un comando PowerShell offuscato che avvia un loader: quest’ultimo mostra un documento esca alla vittima mentre in background prepara l’ambiente per l’esecuzione del vero payload, scaricando un interprete Python 3.12 portatile, lo script get-pip.py per installare le dipendenze e un archivio contenente il payload finale module.pyw.

BusySnake Stealer: un infostealer Python pensato per l’evasione

Il cuore della campagna è BusySnake, un infostealer scritto in Python e mai documentato prima. Il codice è offuscato e cifrato con PyArmor Pro 9.2.0: il malware decripta il proprio bytecode solo nell’istante esatto in cui una funzione viene invocata, per poi ricifrarlo immediatamente dopo l’esecuzione, complicando enormemente l’analisi statica e dinamica. L’estensione .pyw gli permette inoltre di girare in background senza mai aprire una finestra di console visibile.

Dopo l’inizializzazione, che legge da un file di configurazione l’indirizzo del C2, i percorsi delle directory, gli intervalli per gli screenshot e uno user-agent dedicato, BusySnake si mette in ascolto di comandi tramite una funzione poll_task che interroga costantemente il server. Tra le capacità operative documentate da Kaspersky:

• Furto di dati dagli appunti di sistema (clipboard)
• Enumerazione dei file sul disco con logging dei metadati in un database locale
• Ricerca di chiavi esadecimali a 64 caratteri nei file — un pattern tipico dei wallet di criptovalute — e relativa esfiltrazione
• Cattura periodica di screenshot, archiviazione e invio al C2
• Keylogging con invio ed eliminazione periodica del log
• Furto di cookie e password da browser Chromium e Firefox, tramite lettura diretta dei file Cookies/cookies.sqlite e della master key in Login State
• Furto di sessioni e credenziali Telegram dalla cartella tdata, previa terminazione forzata del processo telegram.exe
• Apertura di un tunnel SSH inverso riutilizzando una chiave privata fornita dal C2 (funzionalità ereditata dal tool standalone Go2Tunnel, ora integrata nativamente nello stealer)
• Installazione o riavvio di RustDesk per ottenere il controllo remoto, con cattura dello screenshot delle credenziali inserite dalla vittima al momento del login

Kaspersky ha inoltre individuato una versione più recente dello stealer che introduce un vero e proprio framework di gestione dei task: ogni comando ricevuto dal C2 viene assegnato a un identificativo univoco e transita attraverso quattro stati operativi — SCHEDULED, IN_PROGRESS, SUCCEEDED, FAILED — per un reporting più granulare verso l’infrastruttura d’attacco. Un dettaglio che segnala una maturazione ingegneristica non banale per un tool di questa fascia.

L’ombra dell’AI nel malware development

Un elemento che merita attenzione da parte degli analisti: secondo Kaspersky, i payload di primo stadio (loader e stager) mostrano segni di essere stati generati, almeno in parte, con l’assistenza di strumenti di intelligenza artificiale, a giudicare dalla presenza di commenti ridondanti e blocchi di codice ripetitivi tipici dell’output di modelli linguistici. Non è un caso isolato nel panorama 2026, ma conferma una tendenza: gruppi di livello medio stanno abbassando i tempi di sviluppo del malware affidandosi a copiloti AI, con tutte le implicazioni che questo comporta in termini di volume e velocità di iterazione delle campagne.

Due righe per i difensori

Per i team di detection, il caso Armored Likho offre alcuni punti di leva concreti. Il monitoraggio di scheduled task con nomi che imitano processi Microsoft legittimi (WindowsHelper, ma anche varianti simili) dovrebbe essere prioritario in ambienti governativi e OT/ICS del settore energetico. Vale la pena bloccare o ispezionare il download di interpreti Python portatili e script get-pip.py da endpoint non di sviluppo, un comportamento anomalo per la maggior parte delle postazioni impiegatizie. È inoltre opportuno verificare che la patch per CVE-2025-9491 sia stata applicata su tutta la flotta Windows, dato che il bug LNK continua a essere riciclato da attori eterogenei quasi un decennio dopo la sua prima comparsa. Infine, il traffico verso servizi di tunneling SSH inverso avviato da processi non amministrativi è un segnale da allarme immediato, così come i tentativi di reinstallazione o riavvio non richiesti di RustDesk.

Kaspersky segnala di continuare a monitorare attivamente l’evoluzione della campagna e dell’infrastruttura di rete associata: è ragionevole aspettarsi nuove varianti di BusySnake nei prossimi mesi, considerato il ritmo di sviluppo osservato finora.

Indicatori di compromissione (IoC)

# Hash MD5 (selezione)
5D5C3E483C5E544260CE98FC29FBF192  - PS1 stager
0041FD1B2358CD08DBCBC28EA8FC3D20  - EXE dropper
894332174F536C2E1EFEDA05CBA79F8B  - DLL loader
CF74AC018D158EA2C2CFA1B1D71D95BC  - LNK malevolo
C7622A1EFFA27BBFEE6D6E03D6474343  - BusySnake Stealer (PYW)
80B7700053E115D65365CE7330383320  - BusySnake Stealer (nuova versione, PYW)
6B45DDB39A6E86229348DCBBA3857E7C  - Archivio RAR con BusySnake
006887732CA4A4A46A97989CF4DEEEF6  - Archivio RAR con BusySnake
732C31ACF971A81C7E51B2A3DAE82020  - Archivio RAR con BusySnake
# Domini C2
winupdate[.]live
arvax[.]xyz
varenie[.]live
lvl99[.]store
onetoken[.]ink
winupdate[.]ink
# CVE sfruttata
CVE-2025-9491 (ZDI-CAN-25373) - Windows LNK RCE, patchata Nov 2025
# Scheduled task sospetto
WindowsHelper (persistenza BusySnake)
MicrosoftOfficeUpdate (persistenza AquilaRAT)

Il ransomware ha sempre avuto un umano dietro la tastiera, o quantomeno dietro lo script. Il Threat Research Team di Sysdig sostiene di aver documentato per la prima volta il contrario: un’estorsione digitale condotta interamente, dalla ricognizione iniziale alla distruzione dei dati, da un modello linguistico di grandi dimensioni senza intervento umano diretto. L’hanno battezzata JADEPUFFER, e i log che ha lasciato dietro di sé si leggono come il diario di bordo — auto-narrato, letteralmente — di un operatore che ragiona, sbaglia, si corregge e ripiega su un piano B in 31 secondi.

Il punto d’ingresso: un server Langflow esposto

JADEPUFFER ha ottenuto l’accesso iniziale sfruttando CVE-2025-3248, una falla di mancata autenticazione nell’endpoint di validazione del codice di Langflow, popolare framework open source per costruire applicazioni e workflow di agenti basati su LLM. Il difetto permette a chiunque raggiunga il servizio di eseguire codice Python arbitrario senza credenziali. Langflow resta un bersaglio ricorrente proprio perché le sue istanze, spesso esposte in fretta e senza controlli di rete, custodiscono tipicamente chiavi API di provider AI e credenziali cloud nell’ambiente circostante — un aperitivo perfetto per chi cerca un punto d’appoggio.

Tutti i payload sono stati consegnati come Python codificato in Base64 attraverso l’endpoint RCE, e da lì l’agente ha iniziato a muoversi da solo.

Fase 1: ricognizione e razzia sull’host compromesso

Subito dopo l’esecuzione, l’LLM ha enumerato l’host (id, uname -a, hostname, interfacce di rete, processi attivi) e ha setacciato in parallelo l’ambiente per categorie di segreti: chiavi API di provider AI (OpenAI, Anthropic, DeepSeek, Gemini e altri), credenziali cloud — con una copertura esplicita dei provider cinesi (Alibaba, Aliyun, Tencent, Huawei) oltre ad AWS, GCP e Azure — wallet di criptovalute e seed phrase, credenziali e file di configurazione di database.

Ha poi scaricato il database Postgres di backend dello stesso Langflow, sondato lo spazio di indirizzi interno alla ricerca di servizi raggiungibili e, trovato un endpoint MinIO (l’archivio oggetti compatibile S3 usato per dati applicativi, backup e modelli ML) protetto solo dalle credenziali di default minioadmin:minioadmin, ha eseguito l’intero playbook di enumerazione: elenco dei bucket — incluso uno dedicato allo stato Terraform — e recupero mirato di file .env e credentials.json. Quando un tentativo iniziale con ?format=json ha restituito XML invece del JSON atteso, l’agente ha adattato all’istante il proprio parser allo schema di risposta S3 e ha rilanciato la richiesta: un dettaglio piccolo ma rivelatore, perché è esattamente il tipo di correzione che un toolkit fisso non farebbe mai da solo.

Prima di spostarsi sul bersaglio vero, ha installato una persistenza banale ma efficace: un cron job che ogni 30 minuti invia un beacon all’infrastruttura d’attacco.

Fase 2: il vero obiettivo — un server Nacos/MySQL di produzione

Gli artefatti catturati mostrano che il bersaglio reale dell’operazione non era Langflow, ma un server di produzione separato che eseguiva MySQL e Alibaba Nacos, la piattaforma di service discovery e configurazione dinamica molto diffusa nelle architetture a microservizi. Nacos porta con sé una storia documentata di bypass di autenticazione (CVE-2021-29441 e varianti correlate) e una chiave di firma JWT di default nota pubblicamente dal 2020, che in molte installazioni non viene mai cambiata, rendendo banale la falsificazione dei token.

Con accesso root al database — le cui credenziali non risultano raccolte nell’ambiente della vittima, e la cui origine resta ignota — l’agente ha inserito direttamente un amministratore backdoor nel database di Nacos. Ed è qui che emerge la sequenza più interessante dell’intera analisi Sysdig: il primo tentativo di login con l’account appena creato fallisce; 12 secondi dopo l’LLM prova contemporaneamente le credenziali di default nacos:nacos e genera un nuovo hash per una password più semplice; 19 secondi più tardi emette un payload correttivo che passa da una chiamata subprocess a un import diretto della libreria bcrypt, cancella la riga corrotta e la ricrea con l’hash generato correttamente. Il login riesce. Dal fallimento alla correzione funzionante: 31 secondi, quindici righe di codice coordinato — cancellare, diagnosticare, ricostruire, reinserire.

Segue una fase di ricognizione per un possibile container escape — scritture di test su file MySQL, tentativi di lettura di docker.sock e /proc/1/cgroup, verifica dei permessi su /proc/1/mountinfo — condotta con precisione chirurgica in circa otto minuti e chiusa da un marcatore di completamento esplicito scritto su disco. Non è il comportamento di uno script fisso: è un agente strutturato che segnala da solo di essere pronto per la fase successiva.

Cifratura, estorsione e distruzione — con un colpo di scena

L’agente ha cifrato 1.342 elementi di configurazione del servizio Nacos usando la funzione AES_ENCRYPT() di MySQL, eliminato le tabelle originali config_info e la relativa cronologia, e creato una tabella di estorsione, README_RANSOM, con la richiesta di riscatto, un indirizzo Bitcoin e un contatto ProtonMail. La nota rivendica AES-256, ma AES_ENCRYPT() di default usa AES-128-ECB salvo riconfigurazione: un dettaglio che forse esagera l’algoritmo ma non cambia l’impatto pratico.

Il colpo di scena è nella chiave: generata come base64(uuid4().bytes + uuid4().bytes), quindi sostanzialmente casuale, stampata una sola volta a schermo e mai salvata né trasmessa altrove. Anche pagando, la vittima non potrebbe recuperare nulla — l’estorsione, in questo caso, è tecnicamente impossibile da onorare. Nella fase finale, l’agente è passato dalla cancellazione di singole righe all’eliminazione di schemi di database interi, commentando nel proprio stesso codice la logica di scelta dei bersagli (“database ad alto ROI da eliminare”) come farebbe un operatore che spiega a sé stesso perché sta agendo così.

Come si fa a dire che è stata davvero un’IA

Sysdig basa la propria valutazione su quattro elementi: codice auto-narrante saturo di commenti in linguaggio naturale che spiegano il “perché” di ogni azione; diagnosi e correzione degli errori a velocità di macchina, con timestamp che mostrano una finestra di 31 secondi tra un fallimento e una correzione multi-step accurata; comprensione dimostrata di testo libero incontrato durante l’operazione, non un semplice pattern-matching; e oltre 600 payload distinti ed efficaci eseguiti in una finestra temporale compressa. Anche l’indirizzo Bitcoin usato nella nota di riscatto è curioso: è l’esempio canonico di formato Pay-to-Script-Hash che compare in tutta la documentazione per sviluppatori Bitcoin — un caso da manuale di possibile “allucinazione” di un modello che ha semplicemente riprodotto un esempio della sua base di addestramento, oppure, alternativamente, un wallet reale scelto deliberatamente dall’operatore. Sysdig non è in grado di distinguere le due ipotesi senza visibilità sul system prompt dell’agente.

Cosa cambia per chi difende

Nessuna delle tecniche usate da JADEPUFFER è nuova: è la loro concatenazione autonoma, end-to-end, contro infrastrutture esposte e trascurate, a segnare un punto di svolta. La soglia di competenza per condurre un’estorsione digitale completa si sta abbassando a quanto costa far girare un agente — e se quell’agente gira su credenziali cloud rubate (LLMjacking), il costo per l’attaccante si avvicina allo zero.

• Applicare la patch per CVE-2025-3248 su ogni istanza Langflow e non esporre mai endpoint di validazione/esecuzione codice a Internet
• Non fare girare server di orchestrazione AI con chiavi API di provider o credenziali cloud nell’ambiente: isolarle in un secret manager lontano da processi raggiungibili dal web
• Cambiare la chiave di firma token di default in Nacos, non esporlo mai a Internet e impedirgli di connettersi al database di backend come root
• Non esporre mai account amministrativi di database su Internet; applicare credenziali forti e restrizioni per IP sorgente sulle porte di gestione
• Applicare controlli di egress così che un host applicativo compromesso non possa contattare liberamente destinazioni esterne o database di staging
• Monitorare cron job che invocano chiamate di rete in uscita e anomalie nello User-Agent, oltre agli IoC indicati sotto

Sysdig prevede che il volume e la varietà di queste campagne aumenteranno man mano che il tooling agentico matura. Il consiglio è trattare server applicativi esposti, config store non irrobustiti e account admin di database raggiungibili da Internet come le prime superfici che verranno colpite — non più da un operatore umano con uno script, ma da un agente che scrive da solo il proprio piano d’attacco, verificandolo passo dopo passo.

Indicatori di compromissione

Nome campagna: JADEPUFFER (agentic threat actor)
Vulnerabilità d'ingresso: CVE-2025-3248 (Langflow, RCE non autenticato)
C2 / accesso iniziale: 45.131.66[.]106
Beacon di persistenza: hxxp://45.131.66[.]106:4444/beacon (cron ogni 30 minuti)
Server di staging/exfil dichiarato: 64.20.53[.]230 (InterServer, AS19318)
Bersaglio secondario: server MySQL + Alibaba Nacos esposto
Vulnerabilità sfruttata sul bersaglio: CVE-2021-29441 (Nacos auth bypass) + chiave JWT di default
Credenziali MinIO sfruttate: minioadmin:minioadmin
Tabella di estorsione: README_RANSOM
Indirizzo Bitcoin: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
Contatto: e78393397[@]proton[.]me
Dati distrutti: 1.342 elementi di configurazione Nacos + tabelle config_info/his_config_info
Chiave di cifratura: generata casualmente, mai salvata né trasmessa (dati non recuperabili)

Google starebbe lavorando a un miglioramento dei widget dedicati alla funzione ‘Collections’ del Play Store, che permette di raggruppare le app per categorie tematiche come giochi, shopping o musica. Al momento i widget disponibili mostrano più categorie contemporaneamente, ma in futuro potrebbe essere possibile scegliere un’unica categoria preferita da visualizzare singolarmente in home.

La funzione Collections diventa ancora più personalizzabile

Introdotta circa due anni fa, la funzione Collections del Play Store raggruppa le applicazioni in categorie tematiche come giochi, shopping, musica e viaggi, permettendo di raggiungere più velocemente le app desiderate. Successivamente Google ha aggiunto anche dei widget dedicati per la home, ma finora ne esistono solo due tipi: uno compatto con le categorie mostrate a icone, e uno più grande che elenca più categorie in un’unica schermata. Entrambi, però, mostrano sempre più categorie insieme, e a seconda delle dimensioni del widget alcune di esse possono restare tagliate fuori.

Widget individuali per ogni categoria, in arrivo?

Secondo quanto riportato dalla testata Android Authority, che ha analizzato la versione 52.1.26-31 dell’app Play Store, Google starebbe sviluppando dei widget dedicati a singole categorie. Se la funzione verrà completata, gli utenti potranno posizionare in home solo la categoria che utilizzano davvero, senza dover convivere con un widget che mostra anche sezioni di scarso interesse.

Le categorie individuate finora nel codice dell’app sono otto:

• Food
• Game
• Listen
• Read
• Shop
• Social
• Travel
• Watch

Chi utilizza soprattutto app di gioco potrebbe quindi scegliere di mostrare solo il widget ‘Game’, mentre chi guarda molti contenuti video potrebbe optare per il widget ‘Watch’, personalizzando la home a seconda delle proprie abitudini.

Funzione ancora in sviluppo

Va precisato che la funzionalità è ancora in fase di sviluppo e al momento non è possibile aggiungerla realmente alla schermata home. Non sono inoltre ancora chiari i dettagli su ridimensionamento e design finale dei nuovi widget, che potrebbero cambiare prima del rilascio definitivo. Collections resta comunque una delle funzioni del Play Store più soggette a piccoli, continui miglioramenti, e questi nuovi widget individuali, se confermati, renderebbero la home ancora più su misura per ogni utente Android.

Redmi starebbe lavorando a un nuovo smartphone dotato di un display extra-large da circa 7 pollici, secondo indiscrezioni diffuse dal noto leaker Digital Chat Station. Il produttore cinese, controllato da Xiaomi, avrebbe in cantiere due nuovi modelli, di cui uno orientato a display generoso e prestazioni elevate.

Due modelli in sviluppo: 6,59 e 7 pollici

Secondo le informazioni trapelate, i due dispositivi in lavorazione sarebbero:

• un modello Pro di fascia medio-alta con display da 6,59 pollici
• un modello ad alte prestazioni con display extra-large da circa 7 pollici

Il leaker non ha indicato direttamente il nome del produttore, ma dato che gran parte delle sue precedenti anticipazioni si sono poi rivelate riferite a prodotti Redmi, anche in questo caso l’ipotesi più accreditata punta al marchio cinese.

Un’indiscrezione che conferma voci precedenti

Non è la prima volta che si parla di uno smartphone Redmi da 7 pollici. Già a febbraio lo stesso leaker aveva anticipato che ‘due aziende’ stavano testando dispositivi con display da 7 pollici, mentre ad aprile erano emerse informazioni su un modello Redmi con schermo da 7 pollici abbinato a una batteria da 10.000 mAh. Sempre ad aprile, altre voci avevano parlato di risoluzione 2K e refresh rate elevato, caratteristiche che coinciderebbero con precedenti indiscrezioni su un ipotetico Redmi K100 con display 2K da 7 pollici.

Gli smartphone si fanno sempre più grandi?

Redmi non sarebbe l’unico produttore a puntare su display extra-large: sempre secondo Digital Chat Station, anche Honor starebbe sviluppando un modello con schermo da 7 pollici e refresh rate a 185Hz, oltre a un altro dispositivo da 6,89 pollici abbinato a un processore a 2nm. Attualmente i flagship più diffusi, come Xiaomi 17 Ultra, Huawei Mate 80 Pro Max e iPhone 17 Pro Max, restano ancorati attorno ai 6,9 pollici di diagonale. Se le indiscrezioni si confermeranno, tra il 2026 e il 2027 potremmo assistere a una vera e propria corsa ai display extra-large da parte dei principali produttori Android.

Per ora si tratta comunque solo di voci di corridoio: nome del prodotto e specifiche definitive restano ancora tutti da confermare.

Il nuovo Redmi 17 5G, prossimo smartphone di fascia media del marchio cinese, ha superato le certificazioni SIRIM in Malesia e NCC a Taiwan, un passaggio che di solito anticipa il lancio globale. Le certificazioni hanno anche svelato alcune specifiche chiave del dispositivo, a partire dalla capacità della batteria.

Le specifiche emerse dalle certificazioni

Il modello certificato porta il numero ‘26062RN92G’ e sarà disponibile in diverse configurazioni di memoria: 4GB+64GB, 4GB+128GB, 4GB+256GB e 8GB+256GB. Sul fronte della connettività, Redmi 17 5G supporterà la rete 5G, il Wi-Fi dual-band, il Bluetooth, l’NFC e il GPS, coprendo quindi tutte le funzioni di connessione più richieste nell’uso quotidiano. La scocca dovrebbe inoltre offrire una certificazione IP64 contro polvere e schizzi d’acqua.

Batteria da 7.500 mAh e ricarica rapida a 45W

Il dato più interessante riguarda la batteria: Redmi 17 5G monterebbe un’unità da 7.500 mAh, un valore decisamente sopra la media per la fascia media, abbinata alla ricarica rapida da 45W. Una scelta che sembra puntare con decisione sull’autonomia, uno degli aspetti più richiesti dagli utenti di smartphone economici.

Un lancio anticipato rispetto al passato?

Il predecessore, Redmi 15 5G, era stato lanciato lo scorso agosto, ma per Redmi 17 5G si ipotizza un debutto anticipato. In Cina, la serie Redmi Note 17 dovrebbe infatti arrivare già a luglio, e questo potrebbe accelerare anche i tempi per la versione globale del nuovo modello. Le certificazioni indicano peraltro che il dispositivo sarà commercializzato anche a livello internazionale, alimentando l’attesa attorno alle strategie di distribuzione regionale di Xiaomi.

Con una batteria generosa e configurazioni di memoria diversificate, Redmi 17 5G punta a farsi notare nella fascia media ed entry-level, un segmento sempre più competitivo per il marchio cinese.

I prezzi europei dei nuovi smartphone pieghevoli Samsung, attesi in presentazione questo mese, sarebbero trapelati in rete. Secondo le indiscrezioni, la gamma Galaxy Z Fold 8 e Galaxy Z Flip 8 subirà un deciso rincaro rispetto alla generazione precedente, e lo stesso varrebbe anche per gli smartwatch Galaxy Watch.

Galaxy Z Fold 8 Ultra: fino a 280 euro di aumento

Il modello di punta, Galaxy Z Fold 8 Ultra, avrebbe i seguenti prezzi in Europa:

• 256GB: 2.199 euro (circa 407.000 yen)
• 512GB: 2.399 euro (circa 444.000 yen)
• 1TB: 2.799 euro (circa 518.000 yen)

Rispetto alla generazione precedente, si parla di un aumento di 100 euro per il taglio da 256GB, 180 euro per quello da 512GB e ben 280 euro per la versione da 1TB.

Arriva anche un nuovo Galaxy Z Fold 8 ‘Wide’

Accanto alla variante Ultra, debutterebbe anche un modello inedito chiamato semplicemente Galaxy Z Fold 8, con un formato più largo rispetto al passato. I prezzi previsti sono:

• 256GB: 1.999 euro (circa 370.000 yen)
• 512GB: 2.199 euro (circa 407.000 yen)
• 1TB: 2.599 euro (circa 481.000 yen)

Per quanto riguarda Galaxy Z Flip 8, i prezzi indicati sono 1.299 euro per il taglio da 256GB e 1.499 euro per quello da 512GB, anche in questo caso con un incremento di 100 e 180 euro rispetto ai modelli precedenti.

Rincari in vista anche per i Galaxy Watch

Le indiscrezioni non riguardano solo gli smartphone pieghevoli: anche la linea di smartwatch Galaxy Watch sarebbe interessata da un aumento dei prezzi. Il Galaxy Watch 9 partirebbe da 409 euro per la versione da 41mm, 459 euro per quella da 44mm e 489 euro per il modello LTE, mentre il Galaxy Watch Ultra 2 costerebbe 749 euro, con un rincaro di 50 euro rispetto al modello precedente.

Trattandosi di indiscrezioni, i prezzi definitivi potrebbero ancora subire variazioni fino alla presentazione ufficiale, attesa nelle prossime settimane.

Il nuovo flagship Sony Xperia 1 VIII sta facendo parlare di sé per un problema software che si ripete da segnalazioni in Giappone e all’estero: l’app fotocamera si blocca quando si utilizza lo zoom al massimo livello o la modalità teleobiettivo, con la fotocamera che in alcuni casi si chiude completamente senza salvare lo scatto.

Le segnalazioni degli utenti giapponesi

Su X (ex Twitter), diversi utenti giapponesi hanno descritto sintomi molto simili tra loro:

• l’app si blocca quando si prova a mettere a fuoco al massimo livello di zoom
• l’applicazione si congela nell’istante in cui si scatta con zoom massimo
• talvolta l’otturatore causa un crash dell’app, con la foto che non viene salvata
• il problema persiste anche dopo un ripristino completo del dispositivo

Il dato più preoccupante è che la maggior parte di queste segnalazioni arriva da utenti che avevano già installato il primo aggiornamento software distribuito da Sony subito dopo il lancio, pensato proprio per migliorare le prestazioni della fotocamera. Questo suggerisce che il bug del blocco in teleobiettivo sia un problema più profondo, non risolto dalla prima patch correttiva.

Il problema segnalato anche da media e utenti internazionali

Non si tratta di un caso isolato al mercato giapponese: anche testate internazionali e community estere hanno riscontrato lo stesso comportamento anomalo. Il sito Trusted Reviews, nella sua recensione di Xperia 1 VIII, ha indicato esplicitamente il bug della fotocamera come uno dei difetti del telefono, descrivendo un blocco dell’anteprima quando si passa tra le diverse focali (0.7x, 1x, 2x). Discussioni simili sono emerse anche sulla community Sony Xperia di Reddit, dove alcuni utenti riportano forti rallentamenti o congelamenti dopo aver ridotto a icona l’app fotocamera in modalità teleobiettivo e averla poi riaperta.

Una nuova patch potrebbe già aver risolto il problema

Nonostante le eccellenti caratteristiche hardware di Xperia 1 VIII, a partire dal nuovo sensore teleobiettivo da 50MP, questa instabilità software rischia di rovinare l’esperienza d’uso. Una buona notizia arriva però dalle community internazionali, dove alcuni utenti segnalano che l’ultimo aggiornamento software distribuito (versione 73.0.A.2.38) avrebbe già migliorato in modo significativo i ritardi e i blocchi in modalità teleobiettivo. Resta ora da vedere se e quando questa correzione arriverà anche sul modello giapponese, per il quale si attende un intervento mirato nelle prossime settimane.

Claude Desktop arriva ufficialmente su Linux in beta con repository APT dedicato per Ubuntu e Debian, aggiornamenti automatici e interfaccia desktop completa.
L'articolo Claude Desktop arriva ufficialmente su Linux con una versione desktop dedicata proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggrega...

🔗 Leggi il post completo

Xiaomi ha aggiornato la propria lista End of Life (EOL), il documento ufficiale che segnala quali smartphone e tablet hanno raggiunto il termine del ciclo di supporto software. Nell’ultimo aggiornamento sono stati inseriti diversi modelli dei marchi Xiaomi, POCO e Redmi, che da ora in avanti non riceveranno più aggiornamenti di Android, di HyperOS, patch di sicurezza o correzioni di bug.

I modelli coinvolti nell’aggiornamento EOL

Tra i dispositivi appena entrati in EOL figurano diversi nomi noti, alcuni dei quali venduti anche in Europa. Ecco l’elenco completo dei modelli interessati:

• Xiaomi 12 (versione Global e varianti regionali)
• Xiaomi 12 Pro (versione Global e varianti regionali)
• Xiaomi 12S Ultra (versione Cina)
• Xiaomi Pad 6 (versione Cina)
• Xiaomi Pad 6 Pro (versione Cina)
• POCO X5 5G (versione Turchia)
• POCO X5 Pro 5G (versione Indonesia)
• Redmi Note 12T Pro (versione Cina)
• Redmi K60E (versione Cina)
• Redmi 10 5G (versione EEA)

Da segnalare che, nel caso di Xiaomi 12 e Xiaomi 12 Pro, il provvedimento riguarda non solo le versioni Global ma anche diverse varianti locali distribuite in altri mercati.

Cosa cambia per chi possiede questi dispositivi

L’inserimento nella lista EOL non significa che i telefoni smetteranno di funzionare da un giorno all’altro: continueranno a essere utilizzabili normalmente. Tuttavia, Xiaomi non fornirà più aggiornamenti del sistema operativo, né tantomeno patch di sicurezza, correzioni di bug o nuove funzionalità. Per la maggior parte dei modelli elencati, il periodo di supporto promesso al lancio era comunque già stato rispettato, quindi si tratta di una scadenza attesa più che di una sorpresa.

Meglio valutare un cambio di smartphone

Chi utilizza ancora quotidianamente uno di questi dispositivi per operazioni sensibili, come home banking, pagamenti digitali o gestione di dati personali, dovrebbe iniziare a considerare il passaggio a un modello più recente. Senza aggiornamenti di sicurezza, infatti, eventuali vulnerabilità scoperte in futuro non verranno più corrette, aumentando gradualmente i rischi legati all’uso del telefono.

Il nuovo chip di punta di Qualcomm, lo Snapdragon 8 Elite Gen 6, farebbe il suo debutto a bordo della prossima serie Xiaomi 18. Secondo le ultime indiscrezioni, Xiaomi sarebbe pronta ad anticipare la concorrenza presentando i nuovi smartphone in contemporanea con lo Snapdragon Summit di Qualcomm, in programma dal 22 al 24 settembre.

Xiaomi 18 in tre varianti, Pro Max con doppia fotocamera da 200MP

Secondo i leak, la gamma Xiaomi 18 sarà composta da tre modelli: Xiaomi 18, Xiaomi 18 Pro e Xiaomi 18 Pro Max. Quest’ultimo dovrebbe puntare tutto sulla fotografia, con due sensori principali da 200 megapixel e un sensore LOFIC da 1/1,28 pollici per la fotocamera principale. Il modello Pro, invece, punterebbe su un display secondario posteriore e su una funzione di privacy dedicata allo schermo, mentre la versione standard crescerebbe leggermente nelle dimensioni, con un display da circa 6,4 pollici e una batteria da 7.200 mAh.

Snapdragon 8 Elite Gen 6: processo a 2nm e nuove GPU

Il vero protagonista della nuova generazione resta però il chip. Sia lo Snapdragon 8 Elite Gen 6 sia la variante Pro dovrebbero essere realizzati con processo produttivo a 2nm, anche se non è ancora chiaro se la produzione sarà affidata a TSMC o Samsung. La CPU adotterà i nuovi core Oryon con configurazione 2+3+3, mentre sul fronte grafico la versione standard monterà una GPU Adreno 845 (12MB di memoria grafica e 6MB di cache L3), contro l’Adreno 850 (18MB e 8MB di cache) riservata alla variante Pro.

Un chip Pro costoso: non tutti i modelli lo avranno

Il costo elevato del chip Pro, stimato attorno ai 300 dollari, spiegherebbe perché non tutta la gamma Xiaomi 18 lo monterà: solo il Pro Max dovrebbe infatti beneficiare della versione più potente, mentre Xiaomi 18 e 18 Pro si accontenteranno dello Snapdragon 8 Elite Gen 6 standard.

Lancio scaglionato tra settembre e ottobre

Sul fronte del lancio, Xiaomi 18 Pro e 18 Pro Max dovrebbero arrivare già a settembre, rivendicando il titolo di primi smartphone al mondo con il nuovo Snapdragon 8 Elite Gen 6, mentre il modello standard slitterebbe a ottobre. Non è la prima volta che Xiaomi gioca d’anticipo: anche la serie Xiaomi 17 era stata la prima ad adottare lo Snapdragon 8 Elite Gen 5, confermando la stretta collaborazione tra il produttore cinese e Qualcomm.

E' disponibile per il download Brave 1.92, versione che introduce i Container nativi per gestire più account in tab isolati.
L'articolo Brave 1.92 porta i Container nativi su Linux proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con Licenza CC BY-NC 4.0

🔗 Leggi il post completo

Sidemark è un annotatore PDF open source per Linux con note Markdown sincronizzate, supporto PowerPoint, annotazioni avanzate e modalità presentazione.
L'articolo Sidemark l’app Linux che unisce annotazioni PDF e note Markdown proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Ea...

🔗 Leggi il post completo

Redmi starebbe già testando un nuovo smartphone di fascia alta equipaggiato con lo Snapdragon 8 Elite Gen 6, il prossimo chip top di gamma di Qualcomm prodotto con processo a 2 nanometri. A rivelarlo è il noto leaker cinese Digital Chat Station, secondo cui il dispositivo si troverebbe già in fase di valutazione ingegneristica interna, con debutto sul mercato previsto per la prima metà del 2027.

Tra i primi ad adottare il nuovo processo produttivo a 2nm

Secondo le indiscrezioni, il marchio del gruppo Xiaomi starebbe sviluppando un modello ancora senza nome ufficiale, attualmente impegnato in test di integrazione hardware, gestione termica, efficienza della batteria e ottimizzazione software. Se le informazioni verranno confermate, si tratterebbe di uno dei telefoni Redmi più potenti mai realizzati dal brand.

Cosa sappiamo finora

• Il dispositivo monterà lo Snapdragon 8 Elite Gen 6
• Il chip sarà realizzato con processo produttivo a 2 nanometri
• È attualmente in corso una fase di test ingegneristici interni
• Il lancio commerciale è previsto per la prima metà del 2027

Non sono ancora trapelati dettagli su display, comparto fotografico, capacità della batteria o velocità di ricarica: al momento l’attenzione è tutta concentrata sul nuovo processore.

Presentazione ufficiale allo Snapdragon Summit 2026

Qualcomm dovrebbe annunciare ufficialmente lo Snapdragon 8 Elite Gen 6 in occasione dello Snapdragon Summit, in programma dal 22 al 24 settembre 2026. Il passaggio al nodo produttivo a 2nm promette miglioramenti significativi in termini di consumi energetici, stabilità delle prestazioni sotto carico prolungato e capacità di elaborazione per l’intelligenza artificiale rispetto alla generazione precedente.

Redmi ha una lunga tradizione nel portare i chip più recenti e performanti di Qualcomm su dispositivi con un rapporto qualità-prezzo aggressivo. Un’adozione anticipata dello Snapdragon 8 Elite Gen 6 rafforzerebbe ulteriormente questa strategia, permettendo al brand di offrire prestazioni di punta a un prezzo più accessibile rispetto ai diretti concorrenti.

Va comunque ricordato che si tratta per ora di indiscrezioni: nome del prodotto, tempistiche di lancio e specifiche finali potrebbero cambiare da qui alla presentazione ufficiale. Nei prossimi mesi sono attesi ulteriori dettagli, sia sul fronte Qualcomm che su quello Xiaomi/Redmi.

I Google Pixel sono apprezzati per un’interfaccia pulita ed essenziale, ma proprio questa semplicità lascia scoperte alcune funzioni che su altri Android, e su iPhone, sono ormai date per scontate. Un sondaggio condotto dal sito 9to5Google tra i propri lettori ha messo in fila le richieste più ricorrenti da parte della community Pixel, offrendo un quadro chiaro di cosa Google dovrebbe migliorare nelle prossime versioni del suo sistema.

Il trasferimento dati resta il tallone d’Achille

La lamentela più diffusa riguarda il passaggio dei dati verso un nuovo dispositivo. Negli ultimi anni Android ha compiuto passi avanti importanti sul backup e la migrazione, e Android 17 ha ulteriormente potenziato il trasferimento da iPhone. Il confronto con l’ecosistema Apple, però, resta impietoso: passando da un iPhone a un altro si conservano posizione delle icone, login delle app e dati salvati quasi senza sforzo, mentre su Pixel il risultato dipende molto dal supporto offerto dai singoli sviluppatori, con alcune app che richiedono una riconfigurazione completa. Anche la disposizione della schermata home non viene sempre replicata quando si arriva da un altro Android, un dettaglio che gli utenti vorrebbero vedere risolto.

Home e schermata di blocco: si chiede più libertà

Anche il Pixel Launcher raccoglie diverse critiche. Tra le richieste più frequenti figurano:

• La possibilità di spostare più app contemporaneamente in una cartella
• Il supporto alle icon pack di terze parti
• Lo spostamento di intere pagine della home in un colpo solo

Molti utenti sottolineano come, pur privilegiando la semplicità, il launcher dei Pixel offra oggi meno margini di personalizzazione rispetto a interfacce come quella di Samsung. Discorso simile per la schermata di blocco, dove si chiedono il salvataggio di più layout, widget più completi e maggiore libertà nella scelta delle scorciatoie: al momento sono disponibili solo due scorciatoie nella parte inferiore, oltre al doppio clic del tasto laterale per aprire fotocamera o Wallet, un’offerta ancora limitata se paragonata a iPhone e Galaxy.

La funzione “Regole” dovrebbe fare un salto di qualità

Introdotta con Android 10, la funzione Regole permette oggi di cambiare la modalità di suoneria in base a condizioni semplici, come la connessione a una rete Wi-Fi specifica o l’arrivo in un determinato luogo. Gli utenti vorrebbero un sistema di automazione molto più avanzato, capace di gestire condizioni multiple e combinate, sul modello di Modes di Samsung o delle Shortcuts di Apple.

Altre richieste: doppio tocco, ricarica e gestione termica

Tra le altre funzioni citate dal sondaggio compaiono il blocco dello schermo con doppio tocco, un controllo più preciso del limite di ricarica della batteria e nuove personalizzazioni per orologio e font di sistema. Sul fronte hardware, resta forte la richiesta di migliorare la gestione del calore sui Pixel con chip Tensor, un problema segnalato da tempo soprattutto nei climi più caldi.

Google continua a investire molto sull’intelligenza artificiale con Android 17, ma il sondaggio dimostra che una fetta consistente della community Pixel chiede soprattutto miglioramenti concreti nell’uso quotidiano, più che nuove funzioni basate sull’AI.

Nuove indiscrezioni fanno luce sul comparto fotografico del prossimo OPPO Find X10 Ultra, il futuro top di gamma del produttore cinese atteso ufficialmente nel 2027. Sebbene manchi ancora più di un anno alla presentazione, alcune informazioni sulle fotocamere iniziano già a circolare, e riguardano soprattutto un netto salto in avanti sul fronte del teleobiettivo.

Sensore periscopico da 200 megapixel in fase di test

Secondo le fonti, OPPO starebbe valutando un teleobiettivo periscopico da 200 megapixel basato su un ampio sensore da 1/1,3 pollici. Pur non essendo indicato esplicitamente il modello di destinazione, tutto lascia pensare che questa componente sia sviluppata proprio per il Find X10 Ultra. Le indiscrezioni parlano anche di una seconda variante in valutazione, con sensore ancora più grande da 1/1,12 pollici, sempre da 200 megapixel: la configurazione definitiva non sarebbe stata ancora fissata. Tra le opzioni al vaglio ci sarebbe anche il nuovo sensore Samsung “HPC” di ultima generazione.

Confermato il doppio teleobiettivo periscopico

Le stesse fonti indicano che il secondo teleobiettivo periscopico dovrebbe rimanere affidato a un sensore Samsung GNB da 50 megapixel e 1/1,95 pollici, una configurazione già segnalata in precedenza dalla medesima fonte. Questo suggerisce che OPPO intenda confermare, anche sul Find X10 Ultra, la struttura a doppio teleobiettivo periscopico che ha già contraddistinto la serie.

Un ulteriore salto di qualità rispetto al Find X9 Ultra

Per fare un confronto, l’attuale Find X9 Ultra monta un teleobiettivo principale da 200 megapixel con sensore da 1/1,28 pollici, affiancato da un secondo teleobiettivo da 50 megapixel con zoom ottico 10x e sensore da 1/2,75 pollici. Se le indiscrezioni sul Find X10 Ultra si confermeranno, il sensore del teleobiettivo principale crescerà ulteriormente, con benefici attesi sulla qualità delle foto a lunga distanza e sulle prestazioni in condizioni di scarsa illuminazione.

• Teleobiettivo principale da 200 MP, sensore da 1/1,3″ o 1/1,12″ (in valutazione)
• Secondo teleobiettivo periscopico da 50 MP, sensore Samsung GNB 1/1,95″
• Possibile impiego del nuovo sensore Samsung HPC
• Presentazione attesa nel primo trimestre del 2027

Lancio previsto nel primo trimestre 2027

Il debutto di OPPO Find X10 Ultra è attualmente collocato nel primo trimestre del 2027. Trattandosi ancora di una fase di sviluppo, le specifiche riportate potrebbero cambiare prima della presentazione definitiva. Nel frattempo, queste indiscrezioni confermano l’intenzione di OPPO di puntare ancora una volta con decisione sul comparto tele, un terreno su cui il produttore si gioca gran parte del confronto con gli altri top di gamma Android.

SelfPrivacy semplifica la creazione e la gestione di servizi self-hosted come e-mail, Nextcloud, Forgejo, Bitwarden, DeltaChat e Jitsi Meet
L'articolo SelfPrivacy rende il self-hosting semplice e accessibile proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con Lic...

🔗 Leggi il post completo

Fedora sospende il processo Community Initiatives dopo il dibattito sull'AI Developer Desktop e valuta un nuovo modello più aperto per i progetti futuri.
L'articolo Fedora sospende le Community Initiatives dopo il dibattito sull’AI Developer Desktop proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o...

🔗 Leggi il post completo

Deblinux è una distribuzione GNU/Linux italiana basata su Debian Stable, progettata per offrire un’esperienza utente immediata, semplice e altamente affidabile. Nata dall’impegno di Andrea Linux, appassionato sviluppatore e promotore del software libero, questa distribuzione si distingue per...

🔗 Leggi il post completo

GeoPulse organizza i dati GPS in una cronologia intelligente con analisi, mappe, integrazione Immich e controllo completo della privacy.
L'articolo GeoPulse il software open che organizza la cronologia GPS con mappe, statistiche e integrazione Immich proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggre...

🔗 Leggi il post completo

Nel primo semestre del 2026 il kernel Linux ha guidato le classifiche delle CVE (Common Vulnerabilities and Exposures, ossia Vulnerabilità ed Esposizioni Comuni, un sistema standardizzato per identificare e catalogare le vulnerabilità di sicurezza)....

🔗 Leggi il post completo

Il rumore di fondo di internet

Basta esporre un server Linux con SSH o un pannello di login web e, nel giro di poche ore, i log di autenticazione iniziano a riempirsi di tentativi falliti: scanner automatici che provano credenziali comuni su SSH, bot che martellano i form di login di WordPress, richieste che cercano endpoint vulnerabili. Non è un attacco mirato: è rumore costante e automatizzato a cui ogni IP pubblico è esposto, ventiquattr’ore su ventiquattro.

Fail2ban resta la risposta più pragmatica a questo problema da oltre quindici anni. Osserva i file di log (o il journal di systemd), riconosce pattern di autenticazione fallita e, superata una soglia configurabile, banna l’IP a livello di firewall. È leggero, flessibile e presente nei repository di ogni distribuzione. In questo articolo vediamo come installarlo, configurarlo correttamente — evitando l’errore più comune, cioè modificare il file sbagliato — e alcune tecniche di tuning che fanno la differenza tra una protezione reale e un servizio che gira senza incidere davvero.

Come funziona, in tre concetti

Fail2ban si basa su tre elementi che vale la pena avere chiari prima di toccare la configurazione:

• Filter: un insieme di pattern regex che riconoscono le righe di log corrispondenti a un fallimento di autenticazione.
• Jail: combina un filtro con un percorso di log, le soglie di attivazione e l’azione da eseguire.
• Action: cosa succede al superamento della soglia — tipicamente un ban a livello di firewall, ma può includere anche una notifica email.

Fail2ban include già filtri e jail pronti per decine di servizi: SSH, Apache, Nginx, Postfix, Dovecot e altri. Nella maggior parte dei casi basta abilitare le jail che servono e regolare pochi parametri numerici.

Installazione

# Debian / Ubuntu
sudo apt update
sudo apt install fail2ban

# Fedora / RHEL 9+ / Rocky / AlmaLinux
sudo dnf install fail2ban

# Arch Linux
sudo pacman -S fail2ban

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

sudo journalctl -u fail2ban -n 50

Il modo corretto di configurare Fail2ban

Il primo errore, molto comune tra chi lo usa per la prima volta, è modificare direttamente /etc/fail2ban/jail.conf. Quel file viene sovrascritto ad ogni aggiornamento del pacchetto, e tutte le modifiche vanno perse silenziosamente al primo upgrade.

L’approccio corretto è creare un file separato nella directory jail.d:

sudo nano /etc/fail2ban/jail.d/custom.conf

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

La sezione [DEFAULT]: i parametri che contano

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

• bantime: durata del ban. Il default di molte distribuzioni è 10 minuti, decisamente troppo poco. Un’ora è un minimo ragionevole; per attaccanti persistenti si può salire a 24 ore o anche una settimana.
• findtime: la finestra temporale in cui vengono contati i fallimenti. Con i valori di esempio, 5 fallimenti in 10 minuti fanno scattare il ban.
• maxretry: numero di fallimenti prima del ban. 5 è ragionevole per SSH; si può scendere a 3 per una protezione più aggressiva.
• ignoreip: IP che non verranno mai bannati. Aggiungete sempre il vostro IP qui prima di abilitare qualsiasi jail — restare bloccati fuori dal proprio server è un problema fastidioso da risolvere da remoto.

Se il server ha anche un indirizzo IPv6 pubblico, includetelo in ignoreip: Fail2ban supporta IPv6, ma alcuni filtri più datati riconoscono solo pattern IPv4, quindi vale la pena verificare che le jail intercettino entrambi i protocolli.

ignoreip = 127.0.0.1/8 ::1 VOSTRO.IP.PUBBLICO

Jail SSH, Apache e Nginx

La jail SSH è quella più importante per la maggior parte dei server, anche se in alcune distribuzioni va abilitata esplicitamente:

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 1h

port = 2222

Per i server web, Apache e Nginx attirano un tipo di abuso diverso: scanner di endpoint 404, bruteforcer di login, bot che generano richieste inutili.

# Apache
[apache-auth]
enabled  = true
logpath  = %(apache_error_log)s
maxretry = 5

[apache-badbots]
enabled  = true
logpath  = %(apache_access_log)s
maxretry = 2

# Nginx
[nginx-http-auth]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 3

[nginx-limit-req]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 10

Dopo ogni modifica, ricaricate la configurazione:

sudo fail2ban-client reload

Verificare lo stato delle jail e i ban attivi

sudo fail2ban-client status

Status
|- Number of jail:      3
`- Jail list:   nginx-http-auth, sshd, apache-badbots

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     143
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 5
   |- Total banned:     38
   `- Banned IP list:   203.0.113.7 198.51.100.22 ...

Ban e unban manuali sono comandi da tenere a portata di mano:

sudo fail2ban-client set sshd banip 203.0.113.99
sudo fail2ban-client set sshd unbanip 203.0.113.99

La jail recidive: bloccare chi torna

Una delle funzionalità meno usate ma più efficaci è la jail recidive, che osserva il log di Fail2ban stesso e banna in modo più severo gli IP che, dopo un ban scaduto, ricominciano subito.

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
action   = %(action_mwl)s
bantime  = 1w
findtime = 1d
maxretry = 5

Testare i filtri prima di fidarsi

Prima di abilitare una jail, conviene verificare che il filtro corrisponda davvero alle righe di log presenti sul sistema:

sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

# /etc/fail2ban/filter.d/miaapp-auth.conf
[Definition]
failregex = ^ .* "POST /login" 401
ignoreregex =

nftables e firewalld: adattare il backend

Su Debian 12+ e Ubuntu 22.04+, nftables è il backend firewall predefinito. L’azione di default di Fail2ban usa ancora iptables, che sui sistemi moderni funziona tramite il layer di compatibilità iptables-nft. Su installazioni nftables “pure”, senza quel layer, va impostata esplicitamente l’azione corretta:

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

[DEFAULT]
banaction = firewallcmd-rich-rules
banaction_allports = firewallcmd-allports

Ban persistenti e notifiche email

Per default i ban vivono in memoria e un riavvio del server li cancella tutti. Per renderli persistenti:

[DEFAULT]
dbfile     = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d

Per ricevere una notifica email ad ogni ban (richiede un setup di invio funzionante, ad esempio postfix o msmtp):

# Solo ban:
action = %(action_)s
# Ban + notifica email:
action = %(action_mw)s
# Ban + email con le righe di log rilevanti:
action = %(action_mwl)s

[DEFAULT]
destemail = voi@vostrodominio.it
sender    = fail2ban@vostroserver.it

Una configurazione di partenza completa

[DEFAULT]
bantime    = 2h
findtime   = 10m
maxretry   = 5
ignoreip   = 127.0.0.1/8 ::1
dbfile     = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 6h

[nginx-http-auth]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 4

[nginx-limit-req]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 10

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

sudo fail2ban-client reload
sudo fail2ban-client status

Cosa Fail2ban non risolve

Fail2ban è reattivo, non preventivo: banna dopo che l’attacco è già in corso. Non copre attacchi brute-force distribuiti su migliaia di IP diversi (con uno o due tentativi ciascuno), exploit zero-day che non generano righe di log, o attacchi a livello applicativo che non falliscono l’autenticazione in modo riconoscibile.

Per una protezione a più livelli, Fail2ban va affiancato ad autenticazione SSH tramite chiave (disabilitando del tutto l’autenticazione a password), un firewall configurato correttamente e revisioni periodiche dei log. Vale anche la pena controllare i limiti di sistema (file descriptor) se il volume di ban è elevato, per evitare che sia Fail2ban stesso a saturare le risorse.

Riferimento rapido

sudo fail2ban-client status                          # elenco jail
sudo fail2ban-client status sshd                      # stato di una jail
sudo fail2ban-client set sshd banip 1.2.3.4           # ban manuale
sudo fail2ban-client set sshd unbanip 1.2.3.4         # unban
sudo fail2ban-client reload                           # ricarica config
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf  # test filtro
sudo tail -f /var/log/fail2ban.log                    # ban in tempo reale

Conclusione

Fail2ban è uno di quegli strumenti che si guadagnano un posto fisso su ogni server Linux esposto a internet: l’installazione richiede pochi minuti e, anche con un tuning minimo, elimina una quantità enorme di rumore da scanner SSH e probe web. La differenza pratica maggiore la fanno tre accorgimenti: impostare un bantime sensato (i 10 minuti di default sono quasi inutili), aggiungere sempre il proprio IP a ignoreip prima di abilitare le jail, e attivare la jail recidive. Da soli, questi tre passaggi migliorano drasticamente l’efficacia di Fail2ban rispetto a un’installazione lasciata ai valori di default.

Fonte originale: LinuxBlog.io – Fail2ban on Linux: Protect Your Server from Brute-Force Attacks

Il punto cieco della governance AI: gli agenti che Entra non vede

Negli ultimi mesi ogni organizzazione con un tenant Microsoft 365 è passata da “come possiamo sfruttare l’AI” a “come possiamo controllarla”. Microsoft ha risposto irrobustendo l’integrazione degli agenti con Entra Agent ID e Copilot Studio, e anche fornitori terzi come Anthropic si stanno muovendo nella stessa direzione con connettori applicativi per M365. Il problema è che molti agenti AI sono già entrati nel tenant prima che questi meccanismi esistessero, e alcuni percorsi permettono tuttora a un’AI “non autorizzata” di operare senza lasciare traccia evidente.

Il rischio più concreto non sono gli agenti registrati e visibili in Entra, ma quelli che operano nascosti dietro identità utente legittime e dispositivi considerati attendibili. Prima di investire in controlli specifici per l’AI, vale la pena sistemare l’igiene dell’identità e la visibilità sugli endpoint. Vediamo tre scenari concreti in cui un agente AI può sfuggire al controllo, come rilevarli e come prevenirli.

Scenario 1 — Il consenso utente come porta d’accesso più semplice

Microsoft ha investito molto nell’irrobustire il flusso di consenso, imponendo il consenso amministrativo per i permessi più pericolosi. Di default esiste una deny list che copre principalmente gli scope di lettura-scrittura più sensibili, ma gli utenti possono ancora acconsentire autonomamente a scope in sola lettura come User.Read, openid, profile ed email.

Lo scope consentibile dall’utente più pericoloso per un agente AI è offline_access: consegna all’agente un refresh token, ovvero accesso persistente in background, anche quando l’utente non è più connesso.

Il punto a favore dei difensori è che questo percorso registra comunque un service principal individuabile e un record di consenso: c’è quindi una traccia da controllare.

Come rilevarlo

• Rivedi periodicamente l’application consent history del tenant
• Analizza gli end-user consent log per individuare consensi anomali o non richiesti dall’IT

Come prevenirlo

La mitigazione è semplice quanto efficace: disabilita completamente il consenso utente e instrada ogni richiesta di permesso attraverso l’admin consent workflow. In Entra questo si configura da Enterprise Applications > Consent and permissions > User consent settings, impostando “Do not allow user consent”.

Scenario 2 — Token senza alcuna impronta in Entra

Il secondo percorso è ancora più insidioso: un flusso guidato dall’utente che produce direttamente un token, senza passare da un vero consenso applicativo. In pratica, l’utente fornisce all’agente username e password (o un flusso equivalente), e l’agente si maschera dietro un’applicazione Microsoft first-party già fidata. In questo caso non viene creato alcun service principal né alcun record di consenso: Entra registra semplicemente un normale login utente.

Esistono diverse varianti di questo pattern, ognuna con la propria contromisura:

• OAuth 2.0 Resource Owner Password Credentials (ROPC): un flusso legacy a singolo fattore. La difesa è imporre MFA sempre, su tutto, senza eccezioni.
• Device Code Flow: si blocca con una semplice policy di Conditional Access dedicata.
• Family of Client IDs (FOCI): un token emesso per un’applicazione della “famiglia” è riutilizzabile su tutte le altre applicazioni della stessa famiglia, e non esiste un interruttore per disabilitare questo comportamento. Il Conditional Access per singola app viene quindi aggirato banalmente: la mitigazione si sposta sul rilevamento, revocando i token in caso di sospetto abuso e affidandosi alla Continuous Access Evaluation, pur sapendo che la sua copertura non è universale.

Scenario 3 — Dispositivi attendibili: dove i controlli identity smettono di aiutare

Lo scenario più complesso è quello di una postazione dedicata all’AI: il classico Mac Mini nuovo di zecca comparso in una nota spese. Il dipendente lo unisce al tenant tramite hybrid join o come dispositivo conforme, e una volta effettuato il join ottiene un Primary Refresh Token (PRT) legato al TPM. L’agente gira come quell’utente e richiede silenziosamente token al Web Account Manager (WAM) broker, ottenendo una connessione persistente e sempre attiva.

Questo è il caso più difficile da chiudere: l’agente supera ogni verifica di Conditional Access perché, di fatto, è l’utente, su un dispositivo fidato. Il Token Protection lega i token al dispositivo, ma non riesce a distinguere “l’utente” da “un processo agente che gira come l’utente” sulla stessa macchina.

Prevenzione e rilevamento

La prevenzione parte dal non permettere agli utenti di unire autonomamente i propri dispositivi al tenant, supportata da policy di Conditional Access rigorose sulla compliance. Il rilevamento deve invece spostarsi sull’endpoint:

• Advanced hunting in Microsoft Defender for Endpoint su DeviceProcessEvents (flag per browser headless, processi figli inattesi)
• Analisi di DeviceNetworkEvents (un processo locale che contatta una API AI esterna)
• Blocco delle app non autorizzate tramite Defender for Cloud Apps

Le fondamenta contano più dei controlli AI-specifici

Il messaggio centrale è che l’igiene dell’identità, per quanto “vecchia” come disciplina, chiude già la maggior parte di questi scenari:

• Impostare il consenso utente su Do not allow user consent
• Abilitare l’admin consent workflow
• Imporre MFA ovunque, sempre, tramite Conditional Access
• Bloccare il device-code flow con una policy dedicata
• Limitare la possibilità per gli utenti di unire dispositivi a Entra
• Imporre la compliance dei dispositivi via Conditional Access

La configurazione di base, però, non copre tutto: ciò che non può essere mitigato deve essere rilevato, il che significa spostare parte dell’attenzione dal piano identità a quello del dispositivo. E il Purview Data Security Posture Management (DSPM) for AI? È uno strumento genuinamente utile, ma va inquadrato correttamente: offre visibilità, non enforcement. DLP e Insider Risk vanno comunque configurati manualmente, il monitoraggio delle AI di terze parti si appoggia agli stessi endpoint ed estensioni browser già citati, le funzionalità più ricche richiedono licenze premium, e la protezione basata su etichette è cieca sui dati non etichettati. Va trattato come una rete di sicurezza aggiuntiva, non come la prima linea di difesa.

Conclusione

Se la strategia di sicurezza di un’organizzazione si basa sull’identificare gli agenti registrati in Entra, ha già perso di vista la categoria di rischio più insidiosa: quella degli agenti che operano mascherati da utenti normali. La lezione pratica per chi amministra un tenant Microsoft 365 è partire dalle basi già note — consenso, MFA, Conditional Access, compliance dei dispositivi — prima di rincorrere soluzioni AI-specifiche, e progettare i controlli assumendo che alcuni agenti stiano già operando sotto mentite spoglie di un utente reale.

Fonte: Petri IT Knowledgebase – The Agents Entra Can’t See: Detecting and Preventing Rogue AI

GNOME 51 Alpha porta miglioramenti a Files, Impostazioni, Wayland, GDM e Software, con tante novità per prestazioni, sicurezza e desktop.
L'articolo GNOME 51 Alpha: tutte le novità della prossima versione del desktop Linux proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene r...

🔗 Leggi il post completo

Immich è una piattaforma open source per la gestione self‑hosted, ovvero su di un proprio server, di foto e video, progettata per offrire controllo totale sui contenuti multimediali senza dipendere da servizi cloud proprietari....

🔗 Leggi il post completo

Calibre è un’applicazione per la gestione completa degli e‑book, progettata per organizzare, convertire e sincronizzare libri digitali all’interno della propria distribuzione GNU/Linux o su altri sistemi operativi. La crescente diffusione dei libri digitali, leggibili...

🔗 Leggi il post completo

Ultramarine Linux è una distribuzione GNU/Linux basata su Fedora, sviluppata con l’obiettivo di offrire un’esperienza pronta all’uso, accessibile e funzionale per utenti di ogni livello, dai principianti agli esperti. Nata nel 2021 come progetto...

🔗 Leggi il post completo

Taurent è un client remoto open source per qBittorrent con app desktop e mobile, gestione multi-server e interfaccia moderna
L'articolo Taurent il client remoto open source per gestire qBittorrent da desktop e smartphone proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rila...

🔗 Leggi il post completo

GitHub ha aggiornato il Copilot Command Line Interface (CLI) introducendo una nuova funzionalità di selezione automatica del modello AI: a partire dal 1° luglio 2026, Copilot CLI può scegliere autonomamente il modello più adatto per ogni richiesta grazie a un sistema interno chiamato HyDRA (Hybrid Dynamic Routing Architecture). Vediamo nel dettaglio come funziona e cosa cambia per sviluppatori e amministratori di sistema.

Come funziona la selezione automatica del modello

Il cuore della novità è il routing intelligente. Quando si usa la modalità Auto in Copilot CLI, HyDRA analizza ogni richiesta lungo più dimensioni prima di scegliere il modello:

• Profondità di ragionamento richiesta: un semplice completamento di codice non ha bisogno dello stesso modello di una diagnosi complessa di bug.
• Complessità di generazione del codice: snippet elementari vs. architetture multi-file.
• Difficoltà di debugging: analisi di stack trace o errori runtime con molte variabili contestuali.
• Necessità di orchestrazione di tool: quanti tool call sono necessari e quanto complessa è la loro concatenazione.

Oltre all’analisi del task, HyDRA considera in tempo reale la disponibilità e la salute dei modelli (latenza, tasso di errore, saturazione) per garantire un’esperienza affidabile anche sotto carico elevato.

Token efficiency e cache hit rate

Uno degli obiettivi principali di HyDRA è ridurre lo spreco di token. Il sistema rispetta i confini naturali della cache: anziché spezzare il contesto in modo arbitrario, le richieste vengono strutturate per massimizzare il tasso di cache hit del prompt, riducendo la latenza complessiva e i costi.

Nei test interni di GitHub, questo approccio ha prodotto guadagni significativi di token efficiency senza regressione qualitativa: non tutti i task richiedono un modello ad alta densità di ragionamento, e selezionare il modello “giusto” per compiti semplici libera capacità per quelli complessi.

Impatto economico: sconto del 10% sugli AI credit

Per i piani a pagamento, l’uso della modalità Auto porta un beneficio economico diretto:

• Sconto del 10% sul costo in AI credit rispetto all’uso diretto dello stesso modello.
• Per i piani annuali legacy (Copilot Pro e Pro+) ancora su billing a premium request: lo sconto si applica al model multiplier. Ad esempio, un modello con moltiplicatore 1x consuma 0,9 premium request invece di 1.

Questo significa che scegliere Auto non è solo conveniente in termini di qualità, ma anche economicamente vantaggioso rispetto alla selezione manuale.

Deferred tool loading: meno overhead per ogni prompt

La stessa release introduce il caricamento differito dei tool (deferred tool loading). Tradizionalmente, ogni prompt includeva gli schema completi di tutti i tool disponibili, anche se la maggior parte non veniva utilizzata. Con il nuovo approccio, le definizioni dei tool vengono recuperate on demand, riducendo il numero di token inviati per ogni richiesta e accelerando l’elaborazione.

Controllo dell’utente e policy di amministrazione

La modalità automatica non significa perdita di controllo:

• Override manuale: in qualsiasi momento è possibile usare il comando /model per selezionare esplicitamente un modello specifico o un provider diverso.
• Policy aziendali: gli amministratori possono imporre l’uso della selezione automatica tramite policy organizzative, garantendo uniformità e rispetto dei requisiti di costo o sicurezza.
• Accesso multi-modello: Auto sfrutta modelli da più famiglie (OpenAI, Anthropic, Mistral, ecc.) a seconda del tipo di abbonamento e delle policy configurate.

Come iniziare

Non è richiesta alcuna configurazione: basta aggiornare Copilot CLI all’ultima versione e selezionare la modalità Auto. GitHub prevede che i modelli disponibili in Auto cambieranno nel tempo, man mano che nuovi modelli saranno integrati nella piattaforma.

# Aggiorna Copilot CLI (se installato via npm)
npm update -g @github/copilot-cli

# Oppure verifica la versione corrente
gh copilot --version

# Nel CLI, seleziona la modalità Auto con il comando /model
# e poi inizia a lavorare normalmente
gh copilot suggest "come creo un Dockerfile multi-stage per .NET 8?"

Considerazioni per team e organizzazioni

Per i team che usano Copilot CLI in contesti enterprise, la funzionalità porta vantaggi concreti:

• Prevedibilità dei costi: la combinazione di routing intelligente e sconto del 10% rende più prevedibile il consumo di AI credit per team numerosi.
• Centralizzazione delle policy: gli admin possono gestire il comportamento del routing da un unico punto di controllo, senza che ogni sviluppatore debba configurare nulla localmente.
• Conformità: le policy di model selection possono essere usate per rispettare requisiti di compliance (es. usare solo modelli ospitati in certi data center o appartenenti a certi vendor).

Conclusione

La selezione automatica del modello in Copilot CLI rappresenta un passo avanti significativo verso un’esperienza AI developer veramente adattiva. HyDRA non si limita a scegliere il modello “migliore” in astratto, ma lo sceglie in base al contesto reale della richiesta, ottimizzando contemporaneamente qualità, latenza e costo. Per chi usa Copilot CLI come parte del workflow quotidiano, la modalità Auto è ora la scelta di default più sensata.

Fonte: GitHub Changelog – Copilot CLI auto model selection routes based on task

Si parla di:
Toggle

C’è un dettaglio che rende il caso di Stelios Kouloglou diverso da tutti gli altri scandali Pegasus degli ultimi anni: l’eurodeputato greco non era una vittima qualsiasi, ma il membro di una commissione d’inchiesta del Parlamento Europeo istituita proprio per indagare sugli abusi dello spyware commerciale. Secondo un report pubblicato il 3 luglio 2026 dal Citizen Lab dell’Università di Toronto, il telefono di Kouloglou è stato infettato con Pegasus nell’ottobre 2022 e almeno altre due volte nel marzo 2023, proprio nei momenti cruciali della stesura del rapporto finale della commissione PEGA. È la prima volta che un membro della commissione viene pubblicamente identificato come bersaglio dello stesso strumento che era chiamato a indagare.

La commissione PEGA e il suo bersaglio interno

La commissione d’inchiesta PEGA (Pegasus and Surveillance Spyware) è stata istituita dal Parlamento Europeo nel marzo 2022, dopo che un consorzio internazionale di giornalisti aveva rivelato l’uso diffuso dello spyware Pegasus di NSO Group contro giornalisti, avvocati, attivisti e politici in diversi Stati membri, tra cui Ungheria, Polonia, Spagna e Grecia. Kouloglou, giornalista ed ex parlamentare di SYRIZA, sedeva nella commissione mentre questa raccoglieva testimonianze e redigeva le prime bozze del suo rapporto, concentrate in particolare sugli abusi documentati a Cipro, Grecia, Ungheria, Polonia e Spagna.

Il fatto che proprio lui sia finito nel mirino, mentre la commissione lavorava a conclusioni che avrebbero potuto imbarazzare governi europei, ha immediatamente sollevato interrogativi sulla natura dell’attacco. Un eurodeputato in carica ha definito l’episodio “un attacco diretto allo stato di diritto”, chiedendo alla Commissione Europea di imporre limiti stringenti all’uso dello spyware nei 27 Stati membri. La Commissione, contattata dai giornalisti, non ha risposto.

Timeline degli attacchi: due finestre, due momenti chiave

Il Citizen Lab ha ricostruito con precisione forense due finestre di compromissione, entrambe coincidenti con fasi decisive del lavoro della commissione:

• 21 ottobre 2022 — Prima infezione confermata, nel pieno delle discussioni via email e messaggistica di ottobre-novembre 2022, in vista della consegna della prima bozza del rapporto sugli abusi in Cipro, Grecia, Ungheria, Polonia e Spagna. Il momento coincide inoltre con un ricovero ospedaliero di Kouloglou per un intervento chirurgico programmato, circostanza che potrebbe aver permesso agli operatori dello spyware di intercettare anche conversazioni ambientali relative alla sua salute o scambi con i visitatori.
• 6-7 marzo 2023 — Due ulteriori infezioni, mentre Kouloglou viaggiava da Atene a Bruxelles per le audizioni della commissione, mesi prima dell’adozione finale del rapporto scritto.

Kouloglou ha raccontato ai giornalisti di TechCrunch la rabbia provata nello scoprire la compromissione: “Ti rendi conto che tutti i tuoi dati personali sono stati presi — non solo gli scambi professionali o i messaggi con i ministri, ma anche le cose molto private, i momenti felici e quelli tristi”. L’eurodeputato ha annunciato l’intenzione di citare in giudizio NSO Group.

PWNYOURHOME: l’exploit zero-click che passa da HomeKit

Dal punto di vista tecnico, l’infezione del 2022 sfrutta una catena di exploit già documentata dal Citizen Lab in precedenti ricerche e nota con il nome in codice PWNYOURHOME, attiva contro iOS 15 e iOS 16 a partire da ottobre 2022. Si tratta di un exploit zero-click in due fasi che colpisce due processi distinti del sistema operativo iPhone: il primo stadio prende di mira il framework HomeKit — il sistema Apple per la gestione della smart home — mentre il secondo stadio sfrutta iMessage per ottenere l’esecuzione di codice e l’installazione dello spyware.

La vulnerabilità sfruttata riguarda un problema di deserializzazione in NSKeyedUnarchiver, una classe già abusata in precedenti catene di exploit zero-click contro iMessage. Poiché non richiede alcuna interazione da parte della vittima, il bersaglio non riceve notifiche, non deve cliccare link né aprire allegati: lo spyware si installa silenziosamente, consentendo l’accesso a messaggi, cronologia delle chiamate, dati di geolocalizzazione, foto e — nel caso dei modelli più recenti — anche all’attivazione da remoto di microfono e fotocamera.

Apple ha corretto le falle sfruttate da PWNYOURHOME con il rilascio di iOS 16.3.1, introducendo tra l’altro un nuovo controllo che rifiuta di decodificare determinati messaggi HomeKit a meno che non provengano da una fonte plausibile. Il problema, come spesso accade con gli attacchi Pegasus, è che l’aggiornamento correttivo non era ancora installato sul dispositivo di Kouloglou al momento dell’attacco dell’ottobre 2022 — una finestra di esposizione che gli operatori dello spyware hanno sfruttato attivamente.

Un cliente governativo con licenza multi-paese

Il Citizen Lab non ha attribuito pubblicamente l’attacco a un governo specifico, ma un dettaglio tecnico rende il quadro più inquietante: l’indirizzo email utilizzato come vettore d’infezione da chi ha colpito Kouloglou è lo stesso già osservato in una precedente campagna che aveva infettato i telefoni di giornalisti in diversi paesi europei. Il riutilizzo dello stesso indirizzo — e quindi, presumibilmente, della stessa infrastruttura di comando e controllo — suggerisce che il cliente governativo di NSO Group disponesse di un’autorizzazione per operare lo spyware Pegasus contro bersagli in più Stati membri dell’Unione Europea, non in uno soltanto.

Questo elemento è cruciale per il dibattito politico che ne è seguito: se la licenza NSO copre operazioni cross-border all’interno dello spazio europeo, i meccanismi di controllo nazionale sull’export e sull’uso dello spyware — già ritenuti insufficienti dallo stesso rapporto PEGA — risultano ancora più permeabili di quanto documentato finora.

NSO Group tra sanzioni USA e tentativi di riabilitazione

NSO Group resta in gran parte bandita dall’uso governativo negli Stati Uniti, a seguito di un ordine esecutivo dell’amministrazione Biden che vieta l’impiego federale di spyware commerciale capace di violare i diritti umani. Nel 2025 l’azienda israeliana ha confermato che un gruppo di investitori statunitensi non identificato ha versato decine di milioni di dollari nella società, in quella che gli osservatori hanno letto come un tentativo di riabilitare il marchio NSO in vista di un possibile ingresso nel mercato americano — un percorso già criticato per la scarsa trasparenza degli impegni dichiarati dall’azienda.

Il caso Kouloglou arriva quindi in un momento delicato: mentre NSO cerca legittimazione commerciale, un membro della stessa commissione UE nata per indagarla diventa l’ennesima prova pubblica che gli abusi non si sono fermati.

Implicazioni e due righe per i difensori

Per chi opera in ruoli ad alto rischio — parlamentari, giornalisti, avvocati per i diritti umani, ricercatori di sicurezza, dissidenti — il caso conferma alcune priorità difensive ormai consolidate ma spesso disattese:

• Aggiornamenti tempestivi: gli exploit zero-click di Pegasus sfruttano quasi sempre vulnerabilità già note ma non ancora patchate sul dispositivo bersaglio. Applicare gli aggiornamenti iOS entro 24-48 ore dalla pubblicazione riduce drasticamente la finestra di esposizione.
• Lockdown Mode: la modalità di isolamento introdotta da Apple su iOS disabilita molte delle superfici di attacco usate dagli exploit zero-click (inclusi determinati messaggi HomeKit e allegati iMessage complessi), ed è fortemente consigliata per soggetti ad alto rischio.
• Verifica forense periodica: strumenti open source come Mobile Verification Toolkit (MVT), sviluppato da Amnesty International, permettono di analizzare backup iOS/Android alla ricerca di indicatori di compromissione noti legati a Pegasus e spyware simili.
• Riavvii regolari del dispositivo: molte varianti di Pegasus non sopravvivono a un riavvio senza reinfezione, complicando la persistenza per gli attaccanti — una contromisura semplice ma efficace in assenza di altre difese.
• Segnalazione a Citizen Lab o Access Now: chi sospetta di essere bersaglio di spyware commerciale può richiedere supporto tecnico gratuito attraverso l’Access Now Digital Security Helpline.

Il caso Kouloglou dimostra ancora una volta che lo spyware di livello statale non conosce eccezioni istituzionali: nemmeno chi indaga sugli abusi è al riparo dal diventarne bersaglio. Per il Parlamento Europeo, la domanda che resta aperta è se le raccomandazioni della stessa commissione PEGA — largamente rimaste lettera morta — troveranno finalmente attuazione concreta.

Indicatori tecnici e riferimenti

Spyware: NSO Group Pegasus
Catena di exploit: PWNYOURHOME (zero-click, iOS 15/16)
Vettori sfruttati: HomeKit (stage 1) + iMessage/NSKeyedUnarchiver (stage 2)
Patch correttiva: iOS 16.3.1

Date di compromissione confermate (dispositivo Kouloglou):
- 21 ottobre 2022
- 6 marzo 2023
- 7 marzo 2023

Strumenti di verifica consigliati:
- Mobile Verification Toolkit (MVT) - github.com/mvt-project/mvt
- Access Now Digital Security Helpline

Fonte primaria: Citizen Lab, University of Toronto
"Member of Committee Investigating Spyware Hacked With Pegasus" (3 luglio 2026)

Mariner è un file manager per GNOME con doppio pannello, ricerca full-text, Quick Look, command palette e tante funzioni richieste dagli utenti.
L'articolo Mariner il file manager per GNOME che amplia le funzionalità di Nautilus proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy v...

🔗 Leggi il post completo

Arch Install Manager semplifica la gestione del software su Arch Linux con un'interfaccia grafica per installazione, aggiornamenti, backup e manutenzione.
L'articolo Arch Install Manager il gestore software che rende Arch Linux più semplice da usare proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggre...

🔗 Leggi il post completo