Backup e Networking: arrivano le nuove versioni di Clonezilla e Wireshark per Linux e Windows

Clonezilla Live 3.3.1 e Wireshark 4.6.4 arrivano insieme in un momento in cui la manutenzione dell’infrastruttura non è più “routine”, ma una forma di difesa operativa. Da un lato, Clonezilla aggiorna l’ambiente live a Linux 6.18 LTS, spinge sulla compatibilità con storage moderni e riduce attriti reali che in produzione diventano incidenti: migrazioni tra dischi 4kn e 512n/e, ripristini su sistemi misti, clonazioni di volumi cifrati, e un supporto BitLocker meno fragile in scenari di imaging e clone server. Dall’altro, Wireshark 4.6.4 non è una release cosmetica: chiude vulnerabilità e crash in dissector critici, corregge comportamenti che possono mandare in stallo l’analisi o addirittura provocare denial-of-service locale, e aggiorna decodifiche per protocolli che in ambienti enterprise e telco sono ormai pane quotidiano. Il filo comune tra le due release è semplice: ridurre la superficie d’errore. Clonezilla lo fa a monte, quando si replica un sistema e si sposta un carico su un nuovo supporto. Wireshark lo fa a valle, quando si deve capire cosa sta succedendo in rete senza che lo strumento stesso diventi un punto debole. In mezzo c’è la realtà di chi lavora su Linux, in data center o in incident response: imaging, restore e capture sono attività che si fanno spesso sotto pressione, e l’affidabilità non è un optional.

Clonezilla Live 3.3.1: Debian Sid, kernel 6.18.9-1 e focus su compatibilità reale

Clonezilla Live 3.3.1 aggiorna la base a Debian Sid e porta il kernel a 6.18.9-1, agganciandosi a una traiettoria LTS che in contesti professionali vale quanto una garanzia: driver più nuovi, compatibilità hardware più ampia, e meno sorprese con controller recenti, NVMe, NIC e storage “strani” che spesso emergono durante migrazioni o recovery. La parte più significativa della release, però, non è il numero del kernel. È la scelta di affrontare in modo esplicito un problema che molti amministratori incontrano quando cambiano dischi e chassis: la migrazione tra formati fisici di settore, 4kn e 512n/e. La differenza non è teorica. Quando il device cambia geometria logica, una clonazione può andare a buon fine e risultare comunque “storta” in fase di boot, mount o verifica dei settori, soprattutto se in mezzo ci sono GPT, MBR e partizioni NTFS. Per questo Clonezilla introduce strumenti e fix specifici. Il nuovo ocs-pt-512-4k-convert gestisce conversioni delle tabelle di partizione da 512 byte a 4kn. Le funzioni do_ntfs_512to4k_fix e do_ntfs_4kto512_fix intervengono aggiornando il campo Total Sectors nelle partizioni NTFS, un dettaglio che sembra marginale finché non lo è: se non torna, la partizione può risultare incoerente o comportarsi in modo imprevedibile durante il ripristino. Questa attenzione ai mismatch di settore viene estesa anche all’utility ocs-expand-gpt-pt, resa più robusta proprio per gestire scenari dove la conversione 512B↔4kn avviene su dischi con “settori mismatch”. Il messaggio è chiaro: Clonezilla vuole ridurre i casi in cui il clone è tecnicamente completato, ma operativamente inutilizzabile.

BitLocker in Clonezilla: meno frizione, più continuità nel mondo ibrido

Uno dei punti più delicati per chi lavora in ambienti misti Windows-Linux è l’interazione con BitLocker. La release 3.3.1 rafforza il supporto in due direzioni pratiche. Da una parte, le partizioni BitLocker risultano gestibili anche su clone server ocs-onthefly, cioè in scenari di clonazione “al volo” dove la stabilità è fondamentale. Dall’altra, viene migliorata l’esperienza di autenticazione: se la password è sbagliata, Clonezilla ripete il prompt invece di trasformare un errore umano in un ciclo di fallimenti opaco e frustrante. Questo tipo di migliorie non fa rumore, ma cambia la giornata. BitLocker è spesso presente su laptop aziendali e workstation, e quando bisogna migrare o recuperare un sistema, l’errore di inserimento credenziali o un comportamento troppo rigido del tool si traduce in tempi persi e stress. Qui Clonezilla sceglie una strada più “umana” e più adatta a incidenti reali.

LUKS e master key: quando la clonazione incontra la gestione della crittografia

Clonezilla 3.3.1 introduce anche una funzione che permette di cambiare la master key nell’header LUKS. È un dettaglio tecnico, ma importante, perché porta il tool oltre la clonazione “bit a bit” e lo avvicina a una gestione più consapevole della cifratura. In contesti di sicurezza, ruotare chiavi e intervenire sugli header può essere parte di una procedura di hardening o di migrazione controllata, soprattutto quando un’immagine viene replicata su più sistemi e si vogliono evitare identità crittografiche duplicate. È il classico esempio di come un live tool, usato spesso come “coltellino svizzero”, finisca per essere l’ultimo miglio di operazioni che toccano policy e compliance.

Migliorie operative: più informazioni nelle immagini, meno output sporco, TUI più efficiente

Clonezilla aggiunge file informativi come fdisk.list e blkdev.json nella directory immagine. Questo è un upgrade sottovalutato: quando qualcosa va storto, la differenza tra una diagnosi rapida e ore di ricostruzione sta spesso nei metadati salvati insieme al backup. Avere la fotografia del layout e dei device in forma leggibile facilita audit, troubleshooting e comparazioni tra prima e dopo. Ci sono poi ritocchi che puntano all’affidabilità del flusso. L’opzione -edio (Direct I/O) viene resa default nel TUI, scelta che mira a migliorare le prestazioni e ridurre overhead in alcune operazioni di lettura/scrittura. La sincronizzazione dell’ora può essere disabilitata con il parametro di boot ocs_time_sync=no, utile in ambienti dove la sync automatica può creare incongruenze o dove si lavora in contesti isolati. Arriva anche lsb-release nel live system, dettaglio che semplifica l’identificazione dell’ambiente quando si raccolgono informazioni per ticket o report. Il menu ocs-live-run-menu imposta TERM su fbterm per rendere corretti i box-drawing: sembra estetica, ma in console e in recovery mode una UI che non si rompe riduce l’errore umano. Ci sono poi fix mirati: bug su multicast da raw device in filesystem sconosciuti, correzioni in identificazione partizioni estese su MBR, ricerca dispositivi via PTUUID, miglioramenti su ripristino MTD/eMMC, e un aggiornamento di Partclone a 0.3.45, che resta il cuore dell’efficienza di Clonezilla quando si clonano partizioni usate invece di fare dump ciechi.

Wireshark 4.6.4: update di sicurezza e crash fix nei dissector

Se Clonezilla lavora sulla resilienza “fisica” dei sistemi, Wireshark 4.6.4 lavora sulla resilienza dell’analisi. La release risolve vulnerabilità e crash in dissector che, in alcuni casi, possono essere attivati tramite traffico o file di cattura crafted. Qui la differenza tra bug e rischio non è accademica: Wireshark è spesso usato durante investigazioni su materiale potenzialmente ostile, e un crash o un exhaustion di memoria può diventare un ostacolo operativo o un vettore di denial-of-service locale. Tra le correzioni principali emergono tre CVE associate a crash o consumo risorse. Il dissector USB HID viene corretto per un problema che poteva portare a exhaustion di memoria, associato a CVE-2026-3201. Il dissector NTS-KE riceve fix per crash con CVE-2026-3202. Il dissector RF4CE Profile viene stabilizzato con CVE-2026-3203. In pratica, un trio di bug che tocca ambiti diversi, ma con lo stesso effetto: rendere lo strumento più robusto quando incontra input non benigni. Wireshark corregge anche un problema di avvio legato a Npcap quando l’accesso è ristretto agli amministratori, una condizione comune in ambienti gestiti. Se l’analizzatore non parte in un contesto dove serve proprio perché la policy è più rigida, il danno è immediato: il troubleshooting si ferma. Questa fix va letta come attenzione al mondo enterprise reale, non a un laboratorio “pulito”.

Decodifiche e protocolli: Art-Net, BGP, IEEE 802.11, NAS-5GS e molto altro

Sul fronte funzionale, Wireshark 4.6.4 aggiorna una lunga serie di protocolli. Il valore qui non è la lista, ma l’idea che la decodifica resti allineata a standard e implementazioni nuove, perché l’analisi di rete vive o muore sulla qualità dei dissector. Aggiornamenti citati coinvolgono Art-Net, BGP, IEEE 802.11, IPv6, ISAKMP/IKEv2, MBIM, MySQL, NAS-5GS, SOCKS, TDS e altri ambiti specialistici come Zigbee e Diameter. Ci sono fix che sembrano “di nicchia” finché non ti ci schianti durante un incidente: decodifica corretta del payload IKEv2 EMERGENCY_CALL_NUMBERS, gestione di valori JA4 ALPN con spazi inattesi, miglioramenti a Expert Info per evitare degradazione performance, correzioni su parsing HTTP POST in SOCKS con “Decode As”, e crash/segfault in tool come TShark ed editcap in scenari BLF. Anche il supporto ai formati di cattura viene rafforzato, con miglioramenti per BLF, pcapng e TTL. In un mondo dove le capture arrivano da apparati e pipeline differenti, la compatibilità dei formati non è un dettaglio: è ciò che rende possibile correlare eventi, incrociare telemetrie e riprodurre problemi.

Perché queste due release contano insieme: imaging e analisi sono la stessa catena

È facile trattare Clonezilla e Wireshark come strumenti separati: uno per i dischi, l’altro per la rete. In pratica, nelle operazioni reali, sono due segmenti della stessa catena. Quando un sistema viene compromesso o quando un’infrastruttura deve essere migrata, la prima esigenza è catturare lo stato e renderlo riproducibile: qui entra Clonezilla. Subito dopo serve capire flussi, anomalie, protocolli, regressioni, errori: qui entra Wireshark. Se uno dei due strumenti si rompe o introduce frizioni, l’intero workflow perde velocità, e la velocità è spesso l’unica cosa che separa un incidente contenuto da un danno che si espande. Clonezilla Live 3.3.1 lavora sulla parte più “fisica” del problema: settori, tabelle partizione, NTFS, LUKS, BitLocker, e un kernel LTS che riduce la roulette dei driver. Wireshark 4.6.4 lavora sul fronte più “logico”: dissector affidabili, CVE chiuse, parsing più corretto e formati di cattura più solidi. Due release che, messe insieme, dicono la stessa cosa: l’open source continua a essere infrastruttura, e l’infrastruttura è sempre più una questione di sicurezza e continuità operativa.