OPPO starebbe lavorando a un nuovo smartphone pieghevole a libro che punta a ridefinire gli standard della categoria, almeno sul fronte dell’autonomia. Secondo un leaker solitamente affidabile, il dispositivo monterebbe una batteria da 6500 mAh e il nuovo processore Snapdragon 8 Gen 6 di Qualcomm.

Snapdragon 8 Gen 6 e batteria da 6500 mAh

A fornire le prime informazioni concrete è stato il leaker Digital Chat Station, secondo cui il nuovo pieghevole OPPO adotterà il futuro chip di punta Qualcomm Snapdragon 8 Gen 6 (nome in codice SM8950). Ad accompagnarlo ci sarebbe una batteria al silicio-carbonio da circa 6500 mAh, una capacità enorme per un pieghevole a libro, capace di superare non solo gli attuali modelli OPPO ma, potenzialmente, anche i futuri Galaxy Z Fold di Samsung.

Possibile acceleratore AI dedicato

Il leak accenna anche alla possibile presenza di un acceleratore hardware dedicato all’intelligenza artificiale, un processore neurale pensato per eseguire modelli linguistici di grandi dimensioni (LLM) direttamente sul dispositivo, in modo rapido ed efficiente dal punto di vista energetico. La corsa all’AI on-device coinvolge ormai tutti i principali produttori Android, e OPPO sembra intenzionata a fare della potenza di calcolo AI un elemento distintivo anche sui pieghevoli.

• Processore Snapdragon 8 Gen 6 (SM8950)
• Batteria al silicio-carbonio da circa 6500 mAh
• Possibile acceleratore AI dedicato
• Lancio previsto nel primo trimestre 2027

Debutto atteso nel primo trimestre 2027

Secondo le stesse fonti, il nuovo modello dovrebbe arrivare sul mercato nel primo trimestre del 2027. Resta da capire se andrà a sostituire l’attuale serie Find N, con cui OPPO aveva inizialmente puntato su un formato più orizzontale salvo poi orientarsi verso un design verticale più convenzionale, oppure se si affiancherà come nuova linea di prodotto.

Il 2027 si preannuncia un anno particolarmente competitivo per i pieghevoli di fascia alta: oltre a Samsung, che dovrebbe presentare più modelli, circolano voci anche su un possibile iPhone pieghevole di Apple. La sfida tra i produttori Android per l’autonomia e le prestazioni dei pieghevoli è quindi destinata a intensificarsi ulteriormente.

Xiaomi ha svelato nuovi dettagli ufficiali sul Redmi Note 17, atteso in Cina il 14 luglio. Il modello entry-level della gamma punta tutto sull’intrattenimento, con il display OLED più grande mai visto sulla serie Redmi Note, da 7 pollici, e una batteria monstre da 8000 mAh.

Il display OLED più grande della serie

A confermare le specifiche è stato Lu Weibing, general manager del brand Xiaomi. La novità principale è lo schermo OLED da 7 pollici, il più grande mai montato su un Redmi Note, con refresh rate a 120 Hz per una fluidità adeguata sia alla navigazione sia al gaming, e una luminosità di picco fino a 1200 nit per una buona visibilità anche all’aperto. Il pannello integra inoltre la tecnologia proprietaria “Qingshan Eye Protection”, pensata per ridurre l’affaticamento visivo nelle sessioni prolungate.

Batteria da 8000 mAh per gaming e streaming senza pensieri

Il secondo punto di forza è la batteria da 8000 mAh, una capacità ancora rara nella fascia media, dove i modelli da 7000 mAh iniziano appena a diffondersi. Con questa dotazione, Xiaomi punta a garantire sessioni prolungate di gioco e visione di contenuti in streaming senza il timore di rimanere a corto di autonomia.

• Display OLED da 7 pollici, il più grande della serie Redmi Note
• Refresh rate a 120 Hz e luminosità di picco 1200 nit
• Batteria da 8000 mAh
• Nuova colorazione “Meteor Purple”

Nuova colorazione Meteor Purple

Xiaomi ha anche mostrato il design del nuovo Redmi Note 17, che debutterà tra le altre tonalità nella colorazione inedita “Meteor Purple”. Il posizionamento del modello resta quello di un dispositivo entry-level pensato per un pubblico giovane, attento a schermo grande e autonomia più che a prestazioni pure.

Con display generoso e batteria fuori scala, il Redmi Note 17 si candida a diventare uno dei riferimenti della fascia bassa per chi consuma molti contenuti multimediali dallo smartphone. Maggiori dettagli, incluso il prezzo, sono attesi con la presentazione ufficiale del 14 luglio.

Xiaomi ha annunciato una novità che potrebbe cambiare le aspettative degli utenti sulla durata delle batterie: il Redmi Note 17 Pro, in arrivo il 14 luglio in Cina, sarà coperto da una garanzia sulla batteria fino a 5 anni. Una mossa insolita per la fascia media, pensata per rassicurare chi tiene lo smartphone a lungo e teme il naturale degrado della batteria nel tempo.

Sostituzione gratuita in caso di calo di capacità

Secondo quanto dichiarato dal fondatore e CEO di Xiaomi, Lei Jun, i primi acquirenti del Redmi Note 17 Pro potranno contare su una garanzia speciale: se entro 4 anni dall’acquisto la capacità massima della batteria scende sotto l’80%, Xiaomi sostituirà la batteria gratuitamente con una nuova.

Al quinto anno arriva l’upgrade di capacità

La parte più originale della garanzia riguarda il quinto anno di utilizzo: se il degrado si verifica dopo i primi 4 anni, invece di una semplice sostituzione l’utente riceverà una batteria con capacità superiore a quella originale. Xiaomi non ha ancora specificato i dettagli tecnici di questo upgrade, ma si tratta di un impegno raro nel panorama degli smartphone di fascia media.

Una batteria da 9000 mAh già di per sé generosa

Il Redmi Note 17 Pro monta una batteria da 9000 mAh basata sulla tecnologia proprietaria Xiaomi “Jinsha River”, abbinata alla ricarica rapida da 67W e alla ricarica inversa cablata da 22,5W, che permette di usare lo smartphone come power bank per altri dispositivi.

• Garanzia batteria fino a 5 anni per i primi acquirenti
• Sostituzione gratuita se la capacità scende sotto l’80% entro 4 anni
• Dal quinto anno, upgrade gratuito a una batteria di capacità superiore
• Batteria da 9000 mAh con ricarica rapida a 67W

Per ora solo in Cina

Al momento l’iniziativa è confermata solo per il mercato cinese e per il primo lotto di vendita del Redmi Note 17 Pro. Resta da vedere se Xiaomi deciderà di estendere questa politica di garanzia anche ad altri mercati, Italia compresa, dove la fascia media resta uno dei segmenti più competitivi per il produttore cinese.

Google starebbe preparando un cambio di nome per una delle funzioni AI più interessanti dei Pixel: Magic Cue potrebbe presto diventare parte del marchio Gemini, con un nuovo nome in codice individuato nelle beta più recenti: “Proactive Assistance”.

Da Magic Cue a Proactive Assistance

L’indizio arriva dall’analisi dell’APK della beta 229 dell’app Phone by Google. All’interno del pacchetto sono state trovate stringhe che rinominano la funzione finora nota come Magic Cue in “Proactive Assistance”, con una descrizione che elenca tra le funzioni la visualizzazione di informazioni utili durante le chiamate e suggerimenti generati da Gemini a partire dal contenuto di email e messaggi.

• Mostra informazioni utili durante le chiamate
• Gemini analizza email e messaggi per proporre contenuti pertinenti
• I suggerimenti vengono mostrati al momento più opportuno

Il nome era già emerso nell’app Gemini

Non è la prima volta che il nome “Proactive Assistance” viene individuato: era già comparso nell’app Gemini lo scorso aprile, e ora lo stesso riferimento è tornato a galla nella beta più recente dell’app telefono di Google. Secondo la documentazione interna, la funzione sfrutterà anche i contenuti visualizzati sullo schermo e le notifiche, oltre ai dati di app come Gmail e Google Calendar autorizzate dall’utente, elaborando tutto in un’area protetta e cifrata del dispositivo per motivi di privacy.

Un altro tassello nella strategia Gemini di Google

Magic Cue era stato introdotto per la prima volta con i Pixel 10 come funzione capace di anticipare le esigenze dell’utente senza bisogno di comandi espliciti. Il possibile passaggio al marchio Gemini non sembra comportare cambiamenti sostanziali nel funzionamento, ma conferma la strategia di Google di accorpare sempre più servizi AI sotto un unico brand riconoscibile.

Possibile debutto con i Pixel 11

Google non ha ancora confermato ufficialmente il cambio di nome, che al momento resta un’informazione emersa dall’analisi del codice e non un annuncio pubblico. Vista la tempistica, però, un rebranding completo di Magic Cue in “Proactive Assistance” con il marchio Gemini in evidenza potrebbe arrivare proprio in concomitanza con il lancio della serie Pixel 11.

Vivaldi 8.1 migliora stabilità, gestione delle schede e interfaccia con numerose correzioni, offrendo una navigazione ancora più fluida

🔗 Leggi il post completo

Due gravi vulnerabilità Linux corrette nel kernel: Januscape consente la fuga da macchine virtuali KVM, GhostLock permette l'escalation dei privilegi locali

🔗 Leggi il post completo

Il problema: agenti AI che parlano con troppi sistemi, senza controllo

Il Model Context Protocol (MCP) si sta affermando rapidamente come lo standard con cui gli agenti AI aziendali si collegano a strumenti, database e sistemi interni. È comodo: un agente può interrogare un CRM, aprire un ticket, leggere un repository Git o lanciare una pipeline, tutto attraverso lo stesso protocollo. Il problema è che questa comodità sta creando, nella maggior parte delle aziende, un far west di endpoint MCP sparsi, ciascuno con la propria autenticazione, i propri permessi e nessuna visibilità centralizzata.

Gartner stima che il 60% dei proof-of-concept di GenAI venga abbandonato dopo il completamento, principalmente per mancanza di governance, controlli di rischio inadeguati e dati non pronti per l’AI. Citrix ha deciso di attaccare esattamente questo problema estendendo NetScaler, la sua piattaforma di application delivery e sicurezza, con una nuova funzionalità chiamata MCP Gateway.

Cos’è NetScaler MCP Gateway

MCP Gateway trasforma NetScaler in un punto di ingresso unico e governato per tutto il traffico MCP dell’organizzazione. Invece di lasciare che ogni team gestisca in autonomia i propri server MCP, con metodi di autenticazione diversi e nessun log centralizzato, il gateway instrada dinamicamente le richieste verso i server MCP approvati, applicando policy coerenti in un unico punto della rete.

Le funzionalità principali includono:

• Autenticazione centralizzata e granulare: token per utente e token globali, flussi OAuth e ibridi, rate limiting a livello di singolo tool e liste di allow/block per i server, così da impedire agli agenti di raggiungere endpoint non approvati o di generare carichi di richieste incontrollati.
• Affidabilità per i workflow multi-step: la persistenza di sessione e un monitoraggio “protocol-aware” mantengono l’agente collegato al backend corretto e verificano che i server MCP restino sani durante flussi di lavoro lunghi e articolati.
• Model routing e visibilità sui consumi per il traffico LLM: instradamento basato su content switching e tracciamento dell’uso a livello di token, per team, utente o applicazione.

Il tutto sfrutta l’architettura “single-pass” proprietaria di NetScaler, che esegue in un solo passaggio traffic management, autenticazione, routing, ispezione di sicurezza, rate limiting e observability. È una scelta progettuale rilevante: il traffico AI è molto volumetrico sia in termini di dimensioni dei payload che di numero di pacchetti, e concatenare più proxy separati aggiunge hop e latenza esattamente nel punto in cui le performance contano di più.

Governance anche sul lato LLM

Parallelamente al gateway MCP, Citrix ha esteso anche NetScaler AI Gateway, il componente che gestisce il traffico verso i provider LLM. Le richieste in arrivo da agenti e applicazioni possono ora essere instradate verso modelli diversi in base a policy, con tracciamento di token in ingresso e in uscita per team, utente o applicazione. L’obiettivo dichiarato è evitare il vendor lock-in su un singolo provider e responsabilizzare i team sui costi generati dall’uso dell’AI.

Un caso d’uso interessante, in anteprima privata, riguarda l’integrazione con Claude Code: NetScaler AI Gateway agisce da gateway LLM davanti a Claude Code, fornendo un punto di controllo centralizzato per l’accesso ai modelli Anthropic da parte di migliaia di sviluppatori, senza dover applicare l’identità due volte (una lato IdP aziendale, una lato provider AI).

Perché questo interessa a chi gestisce infrastrutture, non solo ai team AI

Per un sistemista o un architetto che ha già affrontato la messa in sicurezza di API gateway e reverse proxy classici, il parallelo con MCP Gateway è immediato: cambia il protocollo, ma la logica di centralizzazione di autenticazione, rate limiting e observability resta la stessa buona pratica che si applica da anni a qualunque superficie di API esposta internamente.

Ci sono almeno tre ragioni pratiche per iniziare a pensarci ora, anche se in azienda gli agenti AI sono ancora in fase pilota:

• Proliferazione silenziosa degli endpoint. Ogni team che sperimenta con agenti AI tende a esporre un proprio server MCP, spesso senza coinvolgere il team di sicurezza. Senza un punto di controllo centrale, il numero di endpoint cresce più velocemente della capacità di monitorarli.
• Settori regolamentati. In ambiti come finanza, sanità e pubblica amministrazione, un agente che accede a sistemi con dati sensibili senza audit trail centralizzato è un problema di compliance, non solo di sicurezza tecnica.
• Il costo nascosto del traffico LLM. Senza tracciamento dei token per team o applicazione, è comune scoprire solo a fine mese quale progetto ha generato la spesa maggiore verso un provider AI.

Come osserva Steve Shah, general manager di NetScaler in Citrix: “non è una questione di se, ma di quando le polizze di cyber-insurance inizieranno a richiedere l’uso di gateway MCP per proteggersi da agenti pericolosi”. È una previsione plausibile: lo stesso percorso è già avvenuto con i Web Application Firewall e, più di recente, con gli API Gateway.

Cosa fare oggi, anche senza NetScaler

Che l’organizzazione adotti NetScaler o un’altra soluzione, i principi di governance restano validi in modo tecnologicamente agnostico:

• Censire tutti i server MCP attivi in azienda, anche quelli nati come esperimento di un singolo team.
• Imporre un solo punto di ingresso autenticato per il traffico MCP verso sistemi che trattano dati sensibili, invece di esporre i server direttamente.
• Applicare rate limiting per tool, non solo per endpoint: un agente compromesso o mal configurato può generare un numero di chiamate ripetute a un singolo strumento capace di saturare un backend anche legittimo.
• Loggare in modo centralizzato ogni richiesta MCP, per poter ricostruire “chi ha fatto cosa” in caso di incidente, esattamente come si farebbe con un audit log su un database di produzione.

Conclusione

MCP sta diventando, nelle parole di Shah, “la nuova API call” per gli agenti AI aziendali. Ma proprio come le API REST hanno richiesto un decennio per maturare pattern di sicurezza consolidati (OAuth, rate limiting, API gateway centralizzati), anche MCP dovrà attraversare lo stesso percorso, probabilmente in tempi molto più compressi vista la velocità con cui l’adozione dell’AI agentica sta avvenendo nelle aziende. Chi gestisce infrastrutture farebbe bene ad anticipare questa esigenza, piuttosto che rincorrerla dopo il primo incidente.

Fonte: Help Net Security e 4sysops

Perché il bonding delle interfacce di rete è ancora rilevante

Una singola scheda di rete è un punto singolo di fallimento. Su un server di produzione, un cavo che si stacca, una porta dello switch che si guasta o un driver che va in crash possono bastare per portare giù un servizio. Il network bonding su Linux (noto anche come NIC teaming o link aggregation) risolve il problema aggregando due o più interfacce fisiche in un’unica interfaccia logica gestita dal kernel: bond0. A seconda della modalità scelta, si ottiene ridondanza, throughput aggregato maggiore, oppure entrambi.

Non è una tecnologia nuova, il driver bonding è nel kernel Linux da anni, ma resta uno degli strumenti più sottoutilizzati nella cassetta degli attrezzi di chi amministra server fisici, hypervisor o anche semplici home lab. Vediamo come funziona davvero, quali modalità scegliere e come configurarlo con gli strumenti che si trovano oggi sulle distribuzioni più diffuse.

Bonding non è bridging

Prima di entrare nella configurazione, vale la pena chiarire un equivoco comune: il bonding non è la stessa cosa del bridging. Un bridge collega segmenti di rete distinti, permettendo al traffico di attraversare due reti separate. Il bonding, invece, aggrega più interfacce fisiche facendole apparire al sistema operativo e alle applicazioni come un unico dispositivo di rete. Sono strumenti diversi, per scopi diversi, e vanno configurati in modo diverso.

Un altro equivoco frequente riguarda la banda: il bonding non raddoppia automaticamente il throughput di una singola connessione TCP. La maggior parte delle modalità distribuisce connessioni multiple su interfacce diverse, non spezzetta un singolo trasferimento su tutti i link contemporaneamente. Il guadagno di banda aggregata si ottiene quando più flussi sono attivi in parallelo, non con un singolo trasferimento di file.

Va inoltre notato che le interfacce WiFi generalmente non sono compatibili con il bonding: la maggior parte dei driver wireless non supporta la modalità promiscua e la manipolazione dell’indirizzo MAC richieste dal driver bonding. Il bonding va quindi limitato a interfacce Ethernet cablate.

Le modalità di bonding: quale scegliere

Il driver bonding del kernel Linux supporta sette modalità. Per la maggior parte degli scenari operativi ne bastano tre o quattro:

• Mode 0 (balance-rr): round-robin, trasmette i pacchetti in sequenza su tutte le interfacce. Offre load balancing e fault tolerance, ma richiede un gruppo di aggregazione statico configurato correttamente sullo switch. Senza questo, si ottengono pacchetti fuori ordine e prestazioni scadenti.
• Mode 1 (active-backup): una sola interfaccia attiva alla volta; se quella attiva si guasta, subentra la backup. Non richiede alcuna configurazione sullo switch. È la modalità più sicura e compatibile, ideale quando l’obiettivo è puramente la ridondanza.
• Mode 2 (balance-xor): selezione dell’interfaccia basata su un hash degli indirizzi MAC sorgente e destinazione. Load balancing per connessione e fault tolerance, richiede supporto dello switch.
• Mode 3 (broadcast): trasmette ogni pacchetto su tutte le interfacce contemporaneamente. Usata raramente, solo in scenari di fault tolerance molto specifici.
• Mode 4 (802.3ad / LACP): link aggregation dinamica secondo lo standard IEEE 802.3ad. Richiede uno switch gestito con LACP abilitato. È la modalità più usata in ambito enterprise: se lo switch la supporta, è la scelta corretta per la produzione.
• Mode 5 (balance-tlb): load balancing adattivo del traffico in uscita in base al carico corrente su ciascuna interfaccia; il traffico in ingresso arriva sull’interfaccia attiva corrente. Non richiede configurazione dello switch.
• Mode 6 (balance-alb): come mode 5, ma bilancia anche il traffico in ingresso tramite negoziazione ARP. Non richiede switch gestito e offre buoni guadagni di throughput, anche se alcuni switch e ambienti virtualizzati gestiscono il bilanciamento basato su ARP in modo incoerente: va testato prima di affidarcisi in produzione.

Per un homelab o un setup semplice senza switch gestito, Mode 1 (failover puro) o Mode 6 (bilanciamento senza configurazione switch) sono le scelte pratiche. Per server di produzione con switch gestito, Mode 4 (LACP) è la strada corretta.

Prerequisiti

Servono almeno due interfacce di rete fisiche (o virtuali, in una VM), accesso root o sudo, il modulo kernel bonding e uno strumento di gestione della rete (NetworkManager, systemd-networkd o Netplan, a seconda della distribuzione).

Verificare che il modulo bonding sia disponibile:

modinfo bonding

sudo modprobe bonding

ip link show

Metodo 1: NetworkManager (desktop e la maggior parte dei server moderni)

Su Ubuntu, Fedora, Debian con NetworkManager, o qualunque distribuzione desktop, questo è l’approccio più semplice, grazie al supporto per il bonding consolidato da anni tramite nmcli.

Creare l’interfaccia bond:

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

sudo nmcli con add type ethernet slave-type bond con-name bond0-slave1 ifname enp3s0 master bond0
sudo nmcli con add type ethernet slave-type bond con-name bond0-slave2 ifname enp4s0 master bond0

sudo nmcli con modify bond0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1 ipv4.method manual

sudo nmcli con modify bond0 ipv4.method auto

sudo nmcli con up bond0

sudo nmcli con up bond0-slave1
sudo nmcli con up bond0-slave2

cat /proc/net/bonding/bond0

Metodo 2: systemd-networkd (server e installazioni minimali)

Su server senza NetworkManager, systemd-networkd gestisce il bonding in modo pulito. Creare il file netdev del bond:

sudo nano /etc/systemd/network/10-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms
UpDelaySec=200ms
DownDelaySec=200ms

sudo nano /etc/systemd/network/20-bond0.network

[Match]
Name=bond0

[Network]
DHCP=yes

sudo nano /etc/systemd/network/30-bond0-slave1.network

[Match]
Name=enp3s0

[Network]
Bond=bond0

sudo systemctl restart systemd-networkd
cat /proc/net/bonding/bond0

Metodo 3: Netplan (Ubuntu Server)

Ubuntu Server 18.04 e successivi usano Netplan come layer di configurazione di rete predefinito. Editare il file (di solito /etc/netplan/01-netcfg.yaml):

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
    enp4s0:
      dhcp4: no
  bonds:
    bond0:
      interfaces:
        - enp3s0
        - enp4s0
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
      parameters:
        mode: active-backup
        mii-monitor-interval: 100
        primary: enp3s0

sudo netplan apply

sudo netplan try

parameters:
  mode: 802.3ad
  lacp-rate: fast
  mii-monitor-interval: 100
  transmit-hash-policy: layer2+3

Metodo 4: LACP (Mode 4) con switch gestito

Con uno switch gestito che supporta LACP, Mode 4 vale la configurazione aggiuntiva: si ottiene link aggregation reale con negoziazione dinamica. Sul lato switch, le porte interessate vanno configurate come LAG (Link Aggregation Group) con LACP abilitato: su Cisco il comando è channel-group X mode active; sulla maggior parte degli switch gestiti consumer c’è una sezione LAG o Trunk nell’interfaccia web.

Sul lato Linux, l’unica differenza rispetto al Metodo 1 sono le opzioni del bond:

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=fast"

Attenzione: se si abilita LACP sul lato Linux ma lo switch non è configurato di conseguenza, il bond torna a usare un solo link attivo. Non va in errore, ma non si ottiene alcuna aggregazione: va sempre configurato prima lo switch.

Testare il failover

Con il bonding in active-backup configurato, si può simulare un guasto e osservare il recupero. In un terminale, avviare un ping continuo verso il gateway:

ping 192.168.1.1

sudo ip link set enp3s0 down

cat /proc/net/bonding/bond0

sudo nmcli con modify bond0 bond.options "mode=active-backup,miimon=100,primary=enp3s0"

Comandi utili per il monitoraggio

# Stato del bond in tempo reale
watch -n 1 cat /proc/net/bonding/bond0

# Traffico sull'interfaccia bond
sudo iftop -i bond0

# Stato IP e link
ip addr show bond0
ip link show bond0

# Conteggio dei fallimenti di link (utile per individuare cavi difettosi)
grep "Link Failure Count" /proc/net/bonding/bond0

Problemi comuni e soluzioni

Il bond non ha IP dopo il riavvio

Probabilmente le interfacce slave vengono attivate prima che il bond sia inizializzato. Con systemd-networkd, i numeri più bassi vengono processati per primi: assicurarsi che il file netdev (10-bond0.netdev) abbia un numero inferiore rispetto ai file network degli slave. Verificare anche che il modulo si carichi al boot:

echo "bonding" | sudo tee /etc/modules-load.d/bonding.conf

Solo uno slave risulta attivo anche in round-robin o LACP

Lo switch non è configurato per il LAG. Configurarlo correttamente, oppure passare a Mode 1 o Mode 6, che non richiedono configurazione dello switch.

I drop di ping durante il failover durano più del previsto

Abbassare il valore di miimon (l’intervallo di polling predefinito è 100ms):

bond.options "mode=active-backup,miimon=50,updelay=100,downdelay=100"

Conclusione

Il network bonding è una di quelle funzionalità che sembrano complicate finché non si mettono effettivamente in pratica. Il modulo kernel è già presente nella maggior parte delle distribuzioni, la configurazione è lineare, e il risultato è concreto: failover a downtime quasi zero, throughput aggregato maggiore, o entrambi, a seconda della modalità scelta.

Per chi non ha certezze su quale modalità scegliere, Mode 1 è il punto di partenza più sicuro: non richiede configurazione dello switch, funziona ovunque e il failover è quasi istantaneo. Si può poi passare a Mode 4 con LACP quando si dispone di uno switch gestito e si desidera una vera link aggregation. In entrambi i casi, /proc/net/bonding/bond0 resta lo strumento diagnostico di riferimento: va controllato dopo il setup, dopo ogni modifica, e ogni volta che qualcosa sembra non funzionare come dovrebbe.

Fonte: LinuxBlog.io

Nuovi dettagli emergono sul Tensor G7, il chip proprietario che Google dovrebbe montare sui Pixel 12 in arrivo il prossimo anno. Secondo un leaker che segue da vicino lo sviluppo dei processori Tensor, il colosso di Mountain View starebbe testando il supporto alla memoria LPDDR6, uno standard di nuova generazione che potrebbe segnare un salto in avanti significativo per le prestazioni legate all’intelligenza artificiale sui futuri Pixel.

Il Tensor G7 in fase di test con la RAM LPDDR6

Stando alle informazioni condivise dal leaker “@Reptalicant”, Google starebbe valutando per il Tensor G7 due configurazioni di memoria: la consolidata LPDDR5X e la più recente LPDDR6, ancora agli inizi della sua diffusione commerciale. Rispetto allo standard attuale, la LPDDR6 promette una banda passante nettamente superiore, un aspetto cruciale per un chip che Google posiziona da anni come specializzato nei carichi di lavoro legati all’intelligenza artificiale e alla fotografia computazionale.

Cosa cambierebbe per le funzioni IA dei Pixel

Le indiscrezioni parlano anche dell’adozione di un bus di memoria a 96 bit, una soluzione che velocizzerebbe il trasferimento dei dati tra CPU e RAM riducendo le latenze. Sulla carta, un miglioramento del genere si tradurrebbe in una risposta più rapida per le funzioni su cui Google ha costruito l’identità dei Pixel: editing fotografico basato su intelligenza artificiale, traduzione simultanea e riconoscimento vocale in tempo reale. A questo si aggiungono voci, circolate in precedenza, secondo cui il Tensor G7 sarebbe prodotto con il processo a 2 nanometri di TSMC, un ulteriore elemento che lascia intravedere un’evoluzione sostanziale rispetto ai chip Tensor attuali.

Meglio non farsi troppe illusioni

Va detto che la serie Tensor è accompagnata quasi ogni anno da annunci di “svolte epocali” sulle prestazioni, che poi nei fatti si sono tradotte in miglioramenti più contenuti. Anche il Tensor G5 attuale, pur avendo fatto passi avanti concreti, resta secondo molte analisi lontano dal vertice della categoria occupato dai chip di punta della concorrenza. Per questo, anche le voci sul Tensor G7 andrebbero considerate con la giusta cautela fino all’annuncio ufficiale.

Non è detto che la LPDDR6 arrivi davvero sui Pixel 12

Un punto da tenere presente è che il supporto tecnico alla LPDDR6 da parte del Tensor G7 non garantisce che questa memoria venga effettivamente adottata sui Pixel 12. Il prezzo dei chip di memoria è in forte crescita a livello globale, e l’adozione di uno standard così recente potrebbe far lievitare in modo significativo il costo di produzione dei dispositivi. Non è quindi da escludere che, per motivi di bilanciamento tra costi e prestazioni, Google decida di mantenere la LPDDR5X anche sulla prossima generazione, riservando la LPDDR6 a un secondo momento.

Resta il fatto che il Tensor G7 si candida a essere il chip che potrebbe finalmente avvicinare le prestazioni IA dei Pixel a quelle promesse negli ultimi anni. Nei prossimi mesi sono attese ulteriori indiscrezioni su processo produttivo, configurazione di CPU e GPU e altri dettagli tecnici del nuovo processore Google.

In Giappone è partita una nuova campagna promozionale che porta il prezzo del POCO M8 5G sotto la soglia psicologica dei 20.000 yen, circa 125 euro al cambio attuale. L’operatore Y!mobile ha lanciato il servizio “Y!mobile Free Style”, dedicato alla vendita di smartphone SIM-free, e tra i modelli protagonisti dello sconto spicca proprio il device entry-level del sub-brand di Xiaomi.

POCO M8 5G, prezzo quasi dimezzato con l’attivazione di un piano

Il prezzo di listino del POCO M8 5G in Giappone è di 38.208 yen (circa 240 euro), ma chi attiva una nuova linea o effettua la portabilità verso Y!mobile scegliendo un piano tariffario tra quelli inclusi nell’offerta può acquistarlo a 19.800 yen, poco più di 125 euro. A questo si aggiunge un bonus di 3.000 yen (circa 19 euro) in punti PayPay, il sistema di pagamento digitale più diffuso in Giappone, che riduce ulteriormente il costo effettivo del dispositivo.

La promozione, attiva dal 9 luglio senza una data di scadenza comunicata, permette anche l’acquisto del solo smartphone senza sottoscrivere un nuovo contratto telefonico, restando comunque valida ai fini dello sconto e del bonus in punti.

Sconti anche su altri modelli Xiaomi e su OPPO Find X9

Il POCO M8 5G non è l’unico smartphone coinvolto nell’iniziativa. Tra i modelli scontati figurano anche altri dispositivi della gamma POCO e uno dei top di gamma OPPO più recenti:

• POCO X8 Pro: prezzo di listino 70.224 yen (circa 445 euro), bonus di 3.000 yen in punti PayPay
• POCO X8 Pro Max: prezzo di listino 91.824 yen (circa 580 euro), bonus di 3.000 yen in punti PayPay
• OPPO Find X9: prezzo di listino 149.808 yen (circa 950 euro), bonus fino a 20.000 yen (circa 125 euro) in punti PayPay

Per tutti questi modelli lo sconto sul prezzo del dispositivo è legato all’attivazione di un nuovo contratto o a una portabilità da altro operatore, mentre il bonus in punti resta valido anche per chi acquista solo l’hardware.

Un segnale della strategia aggressiva di POCO sulla fascia economica

Al di là del contesto locale giapponese, l’operazione conferma quanto POCO continui a puntare sulla fascia di prezzo più accessibile per allargare la propria base di utenti, offrendo connettività 5G anche su modelli entry-level a un costo molto contenuto. Una strategia che il marchio sta portando avanti su più mercati e che rende il POCO M8 5G un nome da tenere d’occhio anche per chi, in Italia, cerca uno smartphone economico ma aggiornato dal punto di vista della connettività.

Non è ancora nota una data di lancio ufficiale del POCO M8 5G sul mercato italiano, ma iniziative come questa promozione giapponese danno un’indicazione chiara del posizionamento di prezzo che Xiaomi intende mantenere per la sua serie budget.

Un sondaggio condotto da Android Authority tra quasi 1.800 utenti Pixel rivela un dato curioso: il 76% di chi possiede uno smartphone della gamma Google si sente “invidiato” da amici e parenti per la qualità della fotocamera. Un risultato che conferma come, al di là delle discussioni su prestazioni e autonomia, la fotografia resti il vero punto di forza percepito dei Pixel.

Tre utenti su quattro si sentono “invidiati”

Nel sondaggio, il 75,7% degli utenti Pixel ha dichiarato di essersi sentito invidiato da familiari o amici per la fotocamera del proprio smartphone, mentre solo il 5,7% ha risposto di non aver mai vissuto un’esperienza simile. Un divario netto, che diventa ancora più significativo se confrontato con gli utenti di altri brand: tra chi non possiede un Pixel, solo il 14,7% ha riportato lo stesso tipo di “invidia fotografica” da parte di chi gli sta intorno.

Non è solo questione di qualità: conta la velocità

Secondo l’analisi di Android Authority, il segreto dei Pixel non starebbe soltanto nella qualità pura degli scatti. Negli ultimi anni molti rivali hanno raggiunto o superato Google su sensori e zoom, ma i Pixel manterrebbero un vantaggio concreto nella reattività dell’otturatore. Un redattore della testata, utilizzatore di un Pixel 10 Pro, racconta di percepire meno ritardo allo scatto rispetto ad alcuni modelli Galaxy concorrenti, un dettaglio che fa la differenza quando si tratta di catturare un momento fugace prima che sfugga.

“Il fotografo di famiglia” siamo sempre noi

Tra i commenti raccolti nel sondaggio emergono aneddoti che raccontano bene il fenomeno. C’è chi scrive di essere sistematicamente incaricato di scattare le foto di gruppo a feste ed eventi, e chi possiede un Pixel da un decennio e stima che, in 3-4 occasioni su 10, gli venga chiesto di prestare il telefono per immortalare un momento speciale. Un ruolo non richiesto, ma che molti utenti sembrano indossare quasi con orgoglio.

Non manca chi non è convinto

Il quadro, va detto, non è unanime. Tra le risposte compare anche chi si dichiara deluso: un utente passato da un iPhone 13 Pro a un Pixel 10 Pro XL ammette che le foto e i video del vecchio melafonino gli sembravano superiori alle aspettative create dal nuovo dispositivo Google. Un promemoria che la percezione della qualità fotografica resta comunque soggettiva.

Il sondaggio, va precisato, riguarda i lettori di Android Authority e non rappresenta necessariamente l’utenza generale. Ciò nonostante, il divario tra utenti Pixel e resto del mercato resta un indicatore interessante della reputazione fotografica costruita da Google negli anni, basata più sull’affidabilità e l’immediatezza dello scatto che sulla rincorsa alla scheda tecnica.

Apps2Samsung permette di installare facilmente app non ufficiali su Smart TV Samsung da Windows, macOS e Linux, ampliando le funzionalità del televisore

🔗 Leggi il post completo

Umbra Linux è una distribuzione costruita con Linux From Scratch, pensata per offrire trasparenza, leggerezza e un ambiente completo per imparare e lavorare.

🔗 Leggi il post completo

Proton è lo strumento open source sviluppato da Valve per Steam Play, introdotto nel 2018 con l’obiettivo di permettere l’esecuzione di giochi e applicazioni Windows all’interno dei sistemi GNU/Linux senza ricorrere a macchine virtuali o configurazioni in...

🔗 Leggi il post completo

Una vulnerabilità dormiente da 16 anni nel Kernel Linux permette a un attaccante di evadere da una macchina virtuale ed eseguire codice arbitrario sull'host che la ospita. Si chiama Januscape ed è, per stessa ammissione del ricercatore che l'ha scoperta, il primo exploit guest-to-host noto che funziona indistintamente su processori Intel e AMD.

🔗 Leggi il post completo

Bitwig Studio, la DAW multipiattaforma per Windows, macOS e Linux con strumenti avanzati per registrazione, produzione musicale e sound design

🔗 Leggi il post completo

Non un attacco informatico nel senso classico del termine, ma l’incastro giudiziario di un tassello dell’infrastruttura umana che rende possibile lo spionaggio digitale su scala industriale. L’Investigation Bureau del Ministero della Giustizia di Taiwan ha incriminato due imprenditori accusati di aver affittato a un’azienda cinese migliaia di account dell’app di messaggistica LINE, usati poi da operatori legati all’esercito informatico di Pechino per impersonare giornalisti e colpire funzionari, accademici e attivisti taiwanesi. Il caso conferma, con prove giudiziarie, quanto già documentato mesi prima da ICIJ e Citizen Lab.

Gli imputati e lo schema

Dopo una perquisizione negli uffici della società taiwanese Abigail, l’Ufficio investigativo di Taipei ha emesso ordini di sospensione condizionata del procedimento (deferred prosecution) nei confronti di Li Hualun e Chen Mengsen, per violazione della legge sulla protezione dei dati personali e altri reati. Secondo gli inquirenti, i due avrebbero raccolto numeri di account LINE registrati con SIM taiwanesi per poi rivenderli a Xiamen Empress Information Technology Co. Ltd., azienda cinese che le autorità di Taipei collegano direttamente alla cyber-forza di Pechino, per circa 161 dollari ad account. Gli imputati, si legge nella nota del bureau, avrebbero “agito sotto la direzione dell’unità cyber del Partito Comunista Cinese”.

Il modus operandi: giornalisti finti, malware vero

Gli account LINE acquisiti venivano usati per impersonare reporter internazionali, inclusi giornalisti affiliati all’International Consortium of Investigative Journalists (ICIJ), con l’obiettivo di costruire un rapporto di fiducia con i bersagli. Il pretesto, tanto semplice quanto efficace, sfruttava un’abitudine reale del settore: poiché i giornalisti investigativi usano di frequente strumenti di comunicazione cifrata per proteggere le fonti, gli operatori inviavano alle vittime software di “comunicazione cifrata” in realtà infetto, convincendole a scaricarlo e installarlo. Il risultato era la compromissione del dispositivo e l’esfiltrazione dei dati.

Le vittime designate non erano solo giornalisti: la campagna, secondo l’inchiesta taiwanese, ha colpito funzionari pubblici, accademici e membri di organizzazioni non governative, un pattern coerente con le più ampie operazioni di sorveglianza transnazionale che Pechino conduce contro la diaspora e la società civile.

Il collegamento con l’inchiesta “China Targets” di ICIJ e Citizen Lab

L’operazione della magistratura taiwanese arriva a valle di un’indagine giornalistica: ICIJ, insieme ai ricercatori del Citizen Lab dell’Università di Toronto, aveva già individuato email sospette che impersonavano reporter ICIJ e presunti whistleblower cinesi, inviate a giornalisti del consorzio come parte di una strategia offensiva sofisticata per sottrarre informazioni riservate a soggetti di interesse per il governo cinese. Tra i bersagli identificati da quell’inchiesta, pubblicata nell’aprile 2026 come seguito del progetto “China Targets” del 2025, figuravano attivisti uiguri, tibetani, taiwanesi e della diaspora di Hong Kong, oltre a giornalisti dello stesso ICIJ e di altre testate.

Citizen Lab aveva notato diversi errori nelle email malevole, un dettaglio che suggerisce un’operazione ad alto volume, verosimilmente automatizzata tramite intelligenza artificiale per identificare i bersagli e generare i messaggi con supervisione umana limitata. Il report dell’Investigation Bureau taiwanese conferma questo scenario, descrivendo esplicitamente la tattica del “pretesto della comunicazione cifrata” usata per veicolare il malware.

Un filone parallelo della stessa campagna, documentato sempre da ICIJ, ha visto giornalisti ricevere messaggi LinkedIn e “lettere di invito alla collaborazione” da società di consulenza che offrivano compensi per articoli su temi di commercio e difesa: intelligence occidentali hanno collegato queste società di facciata ai servizi di intelligence militare cinesi, interessati a reclutare o compromettere persone con accesso a informazioni sensibili.

Una condanna leggera per un’infrastruttura pesante

Sul piano giudiziario l’esito appare modesto: agli imputati sono state comminate sanzioni pecuniarie di 120.000 e 50.000 dollari taiwanesi (circa 3.700 e 1.600 dollari USA) a favore dell’erario, nell’ambito di una sospensione condizionata della pena. Ma il valore del caso non sta nell’entità della sanzione, bensì nella conferma giudiziaria di un modello operativo: gli apparati di intelligence cinesi non hanno bisogno di sviluppare exploit sofisticati quando possono affittare, a poche centinaia di dollari, l’identità digitale necessaria a bypassare la fiducia della vittima. È lo stesso principio dell’access broker nel cybercrime finanziario, applicato allo spionaggio politico transnazionale.

Implicazioni per chi lavora con fonti sensibili

• Verificare sempre l’identità di un presunto giornalista attraverso un canale indipendente prima di installare qualsiasi software da lui suggerito, anche se dichiarato “per comunicazioni sicure”
• Diffidare di offerte di collaborazione editoriale o retribuzione per articoli arrivate via LinkedIn o messaggistica istantanea da contatti non verificabili
• Preferire strumenti di comunicazione cifrata open source e verificati (Signal, PGP) scaricati esclusivamente dagli store ufficiali, mai da link ricevuti in chat
• Le organizzazioni che lavorano con fonti, attivisti o dissidenti dovrebbero adottare policy di verifica dell’identità a più fattori per ogni nuovo contatto giornalistico
• Segnalare a ICIJ, Citizen Lab o CERT nazionali eventuali tentativi di contatto sospetti che ricalcano questo schema

Indicatori e riferimenti operativi

Procedimento: Taipei City Investigation Office (Ministry of Justice Investigation Bureau, Taiwan)
Imputati: Li Hualun, Chen Mengsen (deferred prosecution)
Società taiwanese coinvolta: Abigail
Società cinese destinataria: Xiamen Empress Information Technology Co. Ltd.
Prezzo per account LINE: ~161 USD
Vettore sociale: impersonificazione di giornalisti (incl. rete ICIJ) via LINE
Payload: software di "comunicazione cifrata" trojanizzato
Target: funzionari pubblici, accademici, ONG, giornalisti, diaspora uigura/tibetana/HK
Indagini correlate: ICIJ + Citizen Lab (University of Toronto), progetto "China Targets" (2025-2026)

Le agenzie di intelligence raramente raccontano cosa fanno con le proprie capacità offensive. Per questo la relazione annuale 2025-2026 pubblicata dal Communications Security Establishment (CSE), l’agenzia di signals intelligence canadese, è una lettura rara: Ottawa ammette esplicitamente di aver condotto operazioni cyber attive contro trafficanti di precursori del fentanyl, un gruppo estremista e — punto che interessa più da vicino chi si occupa di ransomware — una gang di ransomware-as-a-service che aveva colpito sanità, trasporti e aziende canadesi.

Cosa ha rivelato il rapporto CSE

Il CSE è l’omologo canadese della NSA americana e del GCHQ britannico, parte dell’alleanza Five Eyes, con il mandato di raccogliere intelligence estera, difendere le reti del governo federale e — quando autorizzato — condurre “operazioni cyber attive” contro minacce alla sicurezza nazionale. Nel rapporto pubblicato la scorsa settimana, l’agenzia rivela di aver condotto tre operazioni offensive di questo tipo nell’anno fiscale coperto dal documento, oltre a una operazione difensiva.

La prima ha preso di mira broker internazionali di sostanze chimiche usate per produrre fentanil sintetico: il CSE ha raccolto intelligence sulla rete di distribuzione e ha poi condotto un’operazione che, secondo il rapporto, ne ha “compromesso e ridotto la capacità operativa”. La seconda ha riguardato un gruppo estremista attivo anche nel reclutamento in territorio canadese: l’agenzia ha analizzato struttura, portata e vulnerabilità del gruppo per un’operazione che ha “minato la credibilità del gruppo e limitato la sua capacità di radicalizzare e reclutare nuovi membri”. Formulazioni volutamente vaghe — tipiche di questo genere di disclosure — che comunque confermano l’uso di capacità cyber offensive contro obiettivi non statali con finalità di disruption, non solo di raccolta informativa.

L’operazione contro la gang ransomware

La terza operazione è quella di maggiore interesse per il pubblico di questo blog. Il CSE descrive un gruppo che gestiva un’infrastruttura ransomware-as-a-service, affittando l’accesso ad affiliati per condurre attacchi di extortion distruttivi. L’unità di signals intelligence dell’agenzia ha ricostruito le modalità con cui il gruppo colpiva i settori sanitario, dei trasporti e delle imprese in territorio canadese, per un totale — secondo fonti collegate al caso — di oltre 25 incidenti attribuiti al gruppo contro organizzazioni canadesi. L’operazione cyber attiva che ne è seguita ha reso “inoperabile” l’infrastruttura della gang e ha cancellato gran parte dei dati presenti sui suoi server.

Il rapporto precisa inoltre che, in parallelo, il CSE ha condotto “disruption tecniche” concorrenti contro altre 10 tra le gang ransomware più significative che prendono di mira il Canada, rendendo inutilizzabili parti della loro infrastruttura. Non vengono forniti dettagli su localizzazione geografica degli attori, nomi dei gruppi coinvolti o tecniche specifiche impiegate — una riservatezza operativa comprensibile, dato che rivelare metodi e strumenti comprometterebbe operazioni future contro bersagli simili.

Il contesto: Five Eyes e hunt forward

Questa disclosure si inserisce in una tendenza più ampia tra le agenzie di intelligence occidentali: rendere pubbliche, sia pure in forma sommaria, operazioni offensive contro il cybercrime organizzato. Lo US Cyber Command, con base a Fort Meade, conduce da anni le cosiddette “hunt forward operations”, inviando team cyber presso nazioni alleate per proteggerne le reti e disgregare operazioni offensive di attori avversari; il numero di queste missioni è passato da poche unità nel 2018 a oltre due dozzine nel solo 2025. Anche il rapporto CSE segnala una quarta operazione, di natura difensiva, condotta contro una campagna di phishing diretta contro istituzioni del governo federale canadese, con l’obiettivo dichiarato di degradarne l’infrastruttura e la capacità di colpire cittadini canadesi.

Il quadro che emerge conferma una dinamica osservata anche in altre giurisdizioni: le gang ransomware-as-a-service non sono più contrastate solo con arresti, sanzioni e sequestri di infrastruttura via law enforcement (il modello Europol/FBI applicato ad esempio a LockBit o Hive), ma sempre più spesso con operazioni cyber offensive condotte direttamente dalle agenzie di intelligence, che intervengono prima o parallelamente all’azione giudiziaria per limitare il danno operativo in tempo reale.

Perché conta per i difensori

Per i team di threat intelligence, disclosure di questo tipo — per quanto scarne di dettagli tecnici — sono comunque un segnale operativo utile: confermano che alcune infrastrutture ransomware-as-a-service possono sparire improvvisamente non per un errore operativo del gruppo o per un takedown di polizia annunciato, ma per un’azione statale silenziosa. Questo significa che un affiliato che perde improvvisamente l’accesso al pannello del proprio operatore RaaS, o una gang che smette di rispondere alle vittime in negoziazione, potrebbe non essere vittima di un dissidio interno ma di una disruption di intelligence non rivendicata pubblicamente dal gruppo colpito. Per le organizzazioni canadesi dei settori sanità, trasporti e impresa colpite in passato dal gruppo in questione, vale la pena mantenere alta l’attenzione: un’infrastruttura “resa inoperabile” non equivale a un’attribuzione penale, e nulla impedisce agli operatori di riorganizzarsi sotto un nuovo brand, come già visto ripetutamente nell’ecosistema ransomware.

• Tre operazioni cyber offensive rivendicate dal CSE nell’anno fiscale 2025-2026: broker di precursori del fentanyl, gruppo estremista, gang ransomware-as-a-service
• Infrastruttura della gang ransomware resa inoperabile, dati sui server cancellati
• Disruption tecniche parallele contro altre 10 gang ransomware attive contro il Canada
• Un’operazione difensiva contro una campagna di phishing verso il governo federale canadese
• Nessun dettaglio pubblico su nomi dei gruppi, geolocalizzazione o TTP impiegate

Il problema: gateway AI esposti diventano armi in mano agli attaccanti

Un report dei ricercatori di Zenity, ripreso da Petri IT Knowledgebase, descrive uno scenario che molti reparti IT non hanno ancora messo in conto: non serve violare la rete aziendale se l’infrastruttura AI è già esposta pubblicamente e priva di protezioni adeguate. Gli attaccanti puntano direttamente gateway di inferenza, endpoint AI e piattaforme di agenti raggiungibili da Internet, configurando i propri agenti per usarli come “model provider” — sfruttando cioè la capacità di calcolo e le credenziali dell’azienda vittima per condurre operazioni offensive, ricognizione e furto di risorse, senza aver mai compromesso un singolo endpoint interno.

Come funziona l’attacco

Secondo Zenity, gli attaccanti indirizzano tool di penetration testing autonomi come Strix e HexStrike AI, oltre a workflow basati su OpenAI Codex, verso infrastrutture esposte pubblicamente. In diversi casi osservati, gli agenti venivano istruiti per operare in modo aggressivo e occultare la propria identità durante la ricognizione e i test contro bersagli esterni. I ricercatori hanno inoltre trovato ambienti di sviluppo, cronologie Git, script di ricognizione e altri dettagli operativi esposti involontariamente proprio attraverso questi stessi workflow AI mal configurati.

Un bersaglio ricorrente in questi attacchi è LiteLLM, il gateway open source usato per unificare l’accesso a decine di provider LLM (OpenAI, Anthropic, Azure OpenAI e altri) e adottato da framework molto diffusi come CrewAI, DSPy e Microsoft GraphRAG, con circa 97 milioni di installazioni mensili da PyPI. Proprio questa diffusione lo rende un bersaglio ad alto ritorno per chi cerca infrastrutture da dirottare.

Le vulnerabilità sfruttate

Da marzo 2026 LiteLLM ha accumulato sei CVE distinte e un incidente di supply chain, con la catena più grave che raggiunge un CVSS di 10.0 e consente RCE non autenticata su qualunque proxy esposto. Le più rilevanti:

• CVE-2026-42271 — command injection (CVSS 8.7): gli endpoint POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list, pensati per testare un server MCP prima di salvarlo, accettano una configurazione completa nel body della richiesta. Con una configurazione di tipo stdio, il proxy tenta la connessione eseguendo il comando fornito come sottoprocesso direttamente sull’host.
• CVE-2026-47101 / CVE-2026-47102 — escalation di privilegi (CVSS 9.9): un utente a basso privilegio può ottenere diritti di amministratore ed eseguire codice arbitrario sul server LiteLLM.
• CVE-2026-40217 — sandbox escape: gli endpoint di guardrail riservati agli admin accettano codice Python fornito dall’utente e lo compilano con exec(); omettendo la chiave __builtins__ dal dizionario globals ci si aspetterebbe un ambiente ristretto, ma Python inietta automaticamente l’intero modulo builtins quando quella chiave manca, aprendo di fatto l’accesso alla shell.
• SSRF su /chat/completions — un api_base controllato dall’attaccante permette di dirottare le richieste verso un dominio arbitrario, esponendo potenzialmente la chiave API nell’header Authorization.
• Supply chain attack — nel marzo 2026 le versioni compromesse litellm==1.82.7 e litellm==1.82.8 sono rimaste pubblicate su PyPI per circa 40 minuti prima di essere messe in quarantena.

Il fattore comune che rende possibile lo sfruttamento su larga scala è banale: LITELLM_MASTER_KEY non ha un valore di default e, seguendo la guida rapida ufficiale, è facile finire in produzione con un gateway completamente privo di autenticazione posizionato davanti alle chiavi API più costose dell’organizzazione.

Come mettere in sicurezza la propria infrastruttura AI

Le raccomandazioni di Zenity e della documentazione ufficiale di LiteLLM si possono tradurre in una checklist operativa per chi gestisce questo tipo di infrastruttura:

• Non esporre mai il gateway direttamente su Internet. Endpoint di inferenza e piattaforme agent vanno trattati come qualunque altro sistema internet-facing: dietro reverse proxy con autenticazione forte, VPN o segmentazione di rete dedicata.
• Impostare sempre LITELLM_MASTER_KEY prima di qualunque deployment, anche di test, e non affidarsi mai alla configurazione di default della quickstart in ambienti raggiungibili dall’esterno.
• Aggiornare tempestivamente. Gli attaccanti hanno iniziato a sfruttare le vulnerabilità di LiteLLM a ridosso della pubblicazione delle patch: la versione consigliata è la 1.83.14 o successiva, insieme all’aggiornamento di Starlette alla 1.0.1+.
• Gestire i segreti fuori dall’ambiente locale. Le variabili d’ambiente sono comode in sviluppo ma restano un anti-pattern in produzione perché facilmente leggibili e spesso finiscono nei log delle pipeline CI/CD: meglio un vault dedicato (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager).
• Isolare il filesystem dei container. In Kubernetes, readOnlyRootFilesystem: true è pienamente supportato da LiteLLM e riduce la superficie di attacco in caso di RCE.
• Applicare policy granulari con OPA (Open Policy Agent) per definire in modo esterno e verificabile chi può accedere a quali risorse del gateway.
• Monitorare l’utilizzo. Picchi anomali nel consumo dei modelli, pattern di richieste insoliti o attività fuori orario sono spesso il primo segnale di un uso non autorizzato delle risorse AI aziendali.
• Ruotare tutte le credenziali — chiavi dei provider LLM, password del database, master key, chiavi SSH e credenziali cloud — non appena si sospetta una compromissione, dato che un proxy AI compromesso ha tipicamente accesso a tutto questo.

Conclusione

Il messaggio di fondo del report è semplice: l’infrastruttura AI aziendale merita la stessa attenzione di sicurezza riservata a qualunque altro sistema esposto su Internet, né più né meno. I gateway come LiteLLM stanno diventando componenti critici tanto quanto un database o un server web, ma la velocità con cui sono stati adottati ha spesso lasciato indietro le pratiche di hardening di base — a partire da una master key non configurata. Per chi gestisce questi sistemi, la checklist sopra rappresenta il minimo indispensabile prima di collegare un gateway AI a Internet.

Fonti: Petri IT Knowledgebase – Attackers Exploit Exposed Enterprise AI Infrastructure to Power Autonomous Agents; Obsidian Security – Breaking LiteLLM; The Hacker News – LiteLLM Flaw CVE-2026-42271 Exploited in the Wild.

Il problema: PHP-FPM e l’overhead della gestione dei processi

Chi gestisce server PHP ad alto traffico (WordPress incluso, come questo stesso blog) conosce bene il dilemma: come configurare il process manager di PHP-FPM per ottenere throughput elevato, latenza bassa e un uso stabile di CPU e memoria? La configurazione di default nella maggior parte delle installazioni è pm = dynamic, con il consiglio ricorrente di passare a ondemand quando la memoria disponibile scarseggia. Ma su server che ricevono traffico costante, entrambe le opzioni introducono un overhead di gestione dei processi che una configurazione static ben dimensionata elimina quasi del tutto.

I tre modelli di process manager

PHP-FPM offre tre strategie per gestire i processi figli (worker), definite dalla direttiva pm in php-fpm.conf:

• pm = dynamic — il numero di processi figli varia dinamicamente in base a pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers.
• pm = ondemand — i processi vengono creati solo quando arriva una richiesta, invece di essere avviati insieme al servizio come accade con dynamic.
• pm = static — il numero di processi figli è fisso, determinato unicamente da pm.max_children.

La lista completa delle direttive è documentata nel file php-fpm.conf di riferimento su php.net.

Un’analogia utile: il governor della CPU

Il trade-off tra questi modelli ricorda da vicino quello dei governor CPUFreq su Linux: ondemand scala la frequenza in base al carico corrente, salendo subito al massimo e riducendo gradualmente nei periodi di inattività; conservative fa lo stesso ma in modo più graduale; performance mantiene sempre la CPU alla frequenza massima. Impostare PHP-FPM su static equivale concettualmente a impostare il governor su performance: si rinuncia al risparmio di risorse in idle in cambio di una risposta immediata, senza il tempo di “spin-up” necessario a creare nuovi worker.

Quando e come usare pm static

La bontà di pm static dipende interamente dalla memoria disponibile sul server. Se la RAM è limitata, ondemand o dynamic restano scelte più sicure. Se invece la memoria c’è, conviene eliminare l’overhead del process manager impostando pm.max_children al massimo che il server può sostenere senza saturare memoria o CPU.

La regola pratica: non indovinare il valore di pm.max_children, ma misurarlo. Prima si calcola la dimensione media (RSS) di un worker PHP-FPM sotto carico reale:

ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'

Una configurazione tipica su un server con 32 GB di RAM potrebbe essere:

pm = static
pm.max_children = 100
pm.max_requests = 1000

Per verificare lo stato dei processi in tempo reale è sufficiente:

top -bn1 | grep php-fpm

Quando invece conviene ondemand o dynamic

Con pm = dynamic capita spesso di incontrare un warning simile a questo:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

dynamic e soprattutto ondemand restano invece la scelta giusta in scenari multi-tenant, ad esempio server con decine o centinaia di pool PHP-FPM distinti (hosting condiviso, molteplici account cPanel). In questi casi, dove la maggior parte dei siti riceve poco o nessun traffico, ondemand spegne i worker inattivi risparmiando enormi quantità di memoria complessiva — motivo per cui cPanel lo ha reso il default al posto di dynamic.

Conclusione

Su un server che serve traffico consistente, dynamic e ondemand aggiungono un overhead di gestione dei processi che una configurazione static correttamente dimensionata elimina. La chiave non è scegliere una configurazione “alla cieca”, ma misurare il consumo reale di memoria dei worker, calcolare pm.max_children di conseguenza, lasciare margine per il resto dello stack e poi validare sotto carico reale (ad esempio con benchmark ab) osservando CPU, memoria e tempi di risposta. Con pm static, poiché i worker restano residenti in memoria, i picchi di traffico si traducono in variazioni di carico molto più contenute, con tempi di risposta più stabili nel tempo.

Fonte originale: LinuxBlog.io – PHP-FPM tuning: Using ‘pm static’ for max performance

La storica predominanza di Windows nel mercato dei sistemi operativi desktop ha subito un calo significativo secondo gli ultimi dati di StatCounter, azienda specializzata nell’analisi statistica del traffico web. A giugno 2026, il sistema...

🔗 Leggi il post completo

Jay semplifica la gestione dei pacchetti su Arch Linux con supporto AUR, Flatpak, backup, snapshot e numerosi strumenti avanzati

🔗 Leggi il post completo

Implementazione nativa di KDE Connect per COSMIC Desktop in Rust con supporto plugin, sincronizzazione e condivisione file

🔗 Leggi il post completo

Simple HTTP Server è un server file statico Rust con directory listing, upload, autenticazione, compressione e supporto HTTPS PKCS#12
L'articolo Simple HTTP Server ossia un server file statico semplice e funzionale 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...

🔗 Leggi il post completo

RustDesk 1.4.9 introduce audit avanzato con tracciamento utente e autenticazione a due fattori, migliora la stabilità e corregge bug per Linux.
L'articolo RustDesk 1.4.9: Tracciamento Utente e Audit Avanzato per Connessioni Remote proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy ...

🔗 Leggi il post completo

Linux Mint porta Cinnamon 6.8 a un nuovo livello con il supporto completo a Wayland, migliori prestazioni grafiche e numerose ottimizzazioni
L'articolo Linux Mint: Cinnamon 6.8 offrirà il supporto completo a Wayland 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 rilasciat...

🔗 Leggi il post completo

Deepin 25.2 migliora Wayland, ricerca intelligente dei file, supporto multi-monitor, sicurezza e prestazioni con numerose correzioni e aggiornamenti.
L'articolo Deepin 25.2 migliora Wayland, ricerca dei file e supporto multi-monitor proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy...

🔗 Leggi il post completo

Notepadng è un editor di testo per Linux ispirato a Notepad++, con Scintilla, temi originali e pacchetti per Ubuntu, Flatpak e Snap
L'articolo Notepadng il fork di Notepadqq che porta l’esperienza di Notepad++ 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 ...

🔗 Leggi il post completo

Nettle è un'applicazione per sfondi animati su GNOME con supporto multi-monitor, drag-and-drop e integrazione con le patch della shell
L'articolo Nettle: Sfondi Animati per GNOME con Interfaccia Intuitiva 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 Licen...

🔗 Leggi il post completo

A ridosso della pausa estiva, i sostenitori del controllo delle chat al Parlamento Europeo tentano un colpo di mano procedurale per riattivare la scansione a tappeto e senza sospetto dei messaggi privati.
L'articolo Il Parlamento Europeo vota a favore di Chat Control con procedura d’urgenza proviene da Marco's Box.

🔗 Leggi il post completo

Il team di Linux Mint ha pubblicato il consueto aggiornamento mensile dedicato allo stato dello sviluppo della distribuzione, anticipando le principali novità che debutteranno con la prossima versione prevista per il periodo natalizio del 2026.
L'articolo Linux Mint: Wayland è ormai pronto, grandi miglioramenti in arrivo entro fine anno proviene da Marco's Box.

🔗 Leggi il post completo

Typesetter è un editor Rust/GTK per Typst con anteprima live, click-to-jump, supporto font variabili e gestione pacchetti integrata
L'articolo Typesetter: Editor Minimalista per Documenti con Typst 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 B...

🔗 Leggi il post completo

Una race condition di sei istruzioni che porta a root

Il 4 luglio 2026 è stata resa pubblica una nuova vulnerabilità di privilege escalation nel kernel Linux, battezzata Bad Epoll e catalogata come CVE-2026-46242. Il difetto permette a un utente locale non privilegiato di ottenere i permessi di root su qualsiasi sistema Linux con kernel 6.4 o successivo, incluse le distribuzioni server più diffuse e i dispositivi Android, dove epoll è un componente del kernel che non può essere disattivato senza rompere il funzionamento del sistema operativo e del browser.

Per chi gestisce infrastrutture Linux in produzione, questo è il tipo di bug che merita attenzione immediata: non richiede alcuna interazione dell’utente privilegiato, non richiede configurazioni particolari, e la finestra di race condition — appena sei istruzioni macchina — non è un ostacolo, perché l’exploit pubblicato la sfrutta con un’affidabilità di circa il 99%.

Cos’è epoll e dove si trova il bug

epoll è il meccanismo con cui il kernel Linux notifica in modo efficiente ai processi eventi di I/O su un gran numero di file descriptor, ed è alla base di praticamente ogni event loop moderno: da Nginx a Node.js, da systemd a Chrome. Proprio perché è così centrale, non è un modulo che si possa scaricare o disabilitare come contromisura temporanea.

Il ricercatore Jaeyoung Chung, dottorando al CompSec Lab della Seoul National University, ha individuato un use-after-free (UAF) nella funzione ep_remove(), quella che ripulisce un file descriptor epoll quando viene chiuso. In condizioni normali, ep_remove() azzera file->f_ep sotto file->f_lock, ma continua a utilizzare l’oggetto file all’interno della sezione critica durante le chiamate a hlist_del_rcu() e spin_unlock(). Se in quella finestra ristrettissima una chiamata concorrente a __fput() osserva un valore transitorio NULL, salta eventpoll_release_file() e procede direttamente a f_op->release, liberando una struttura eventpoll ancora in uso.

Il risultato è memoria del kernel corrotta. Poiché struct file è allocata con SLAB_TYPESAFE_BY_RCU, lo slot liberato può essere immediatamente riciclato da alloc_empty_file(), aprendo la strada a un cross-cache attack: l’attaccante fa in modo che il kernel richiami kmem_cache_free() sulla cache sbagliata, ottenendo il controllo su un oggetto di tipo diverso da quello originariamente allocato in quello slot.

La catena dell’exploit

L’exploit pubblicato da Chung costruisce quattro file descriptor epoll collegati tra loro, organizzati in due coppie: chiudendo una coppia si innesca ripetutamente la race condition, mentre l’altra coppia funge da “vittima”. In questo modo una scrittura UAF di soli 8 byte viene trasformata in un use-after-free completo su un oggetto file tramite cross-cache attack. Da lì, l’attaccante ottiene lettura arbitraria della memoria del kernel attraverso /proc/self/fdinfo e dirotta il flusso di esecuzione con una catena ROP (return-oriented programming) fino a ottenere una shell root.

# Schema semplificato della sequenza (pseudocodice concettuale)
fd1, fd2 = crea_coppia_epoll()   # coppia "trigger"
fd3, fd4 = crea_coppia_epoll()   # coppia "vittima"

thread_A: chiudi(fd1)   # innesca ep_remove() ripetutamente
thread_B: chiudi(fd3)   # __fput() concorrente osserva f_ep == NULL
# -> eventpoll_release_file() saltato
# -> free prematuro dell'oggetto eventpoll ancora referenziato
# -> alloc_empty_file() ricicla lo slot -> cross-cache attack

Perché nemmeno un modello AI lo ha trovato

La storia di questo bug ha un risvolto interessante per chi segue l’evoluzione degli strumenti di analisi automatica del codice. Entrambe le vulnerabilità nascono da un singolo commit del 2023 nello stesso percorso di codice di epoll, lungo circa 2.500 righe. La prima, oggi tracciata come CVE-2026-43074, era stata individuata dal modello AI di Anthropic, Mythos, e già corretta all’inizio del 2026. Bad Epoll è la seconda falla, gemella della prima ma molto più difficile da individuare, che Mythos non aveva notato.

Chung stesso indica due possibili ragioni: la finestra temporale è talmente stretta da rendere difficile “visualizzare” la sequenza esatta degli eventi anche leggendo il codice con attenzione, e l’errore di memoria raramente attiva KASAN, il principale rilevatore di bug del kernel, lasciando pochissime tracce a runtime. È un promemoria utile: gli strumenti di code review basati su AI stanno diventando sempre più capaci di individuare race condition nel kernel, ma i bug di concorrenza restano difficili da scovare a ogni livello, per una macchina come per una persona.

Patch e mitigazioni per i sistemisti

Non esiste un workaround praticabile, perché disabilitare epoll non è un’opzione realistica su un sistema Linux moderno. La correzione definitiva è arrivata con il commit upstream a6dc643c6931, dopo che un primo tentativo di patch non aveva risolto completamente il problema — la correzione corretta è arrivata a circa due mesi dalla divulgazione iniziale.

Le azioni concrete da intraprendere:

• Verificare la versione del kernel in uso: sono interessati i kernel basati su 6.4 e successivi; i kernel 6.1 più datati (compresi alcuni dispositivi Android come il Pixel 8) non sono vulnerabili perché il bug è stato introdotto solo con la 6.4.
• Applicare l’aggiornamento del kernel non appena la propria distribuzione rilascia il backport della patch (Debian, Ubuntu, RHEL e derivate stanno seguendo il processo standard di backport della sicurezza).
• Su flotte Android/embedded, verificare i cicli di aggiornamento del vendor per il patch level di sicurezza corrispondente.
• Non fare affidamento su mitigazioni lato SELinux/AppArmor come sostituto della patch: riducono la superficie d’attacco ma non chiudono la race condition nel kernel.

Vale la pena ricordare che Bad Epoll si inserisce in una serie di bug di privilege escalation del kernel Linux usati storicamente anche per il root di Android, come Bad Binder, Bad IO_uring e Bad Spin. A differenza di altri bug recenti più deterministici (come Copy Fail o Dirty Frag), Bad Epoll appartiene alla categoria più “classica” delle race condition da vincere, nello stile di Dirty Cow del 2016: meno affidabile in teoria, ma qui resa quasi deterministica da un exploit ben costruito.

Conclusione

Per chi amministra server Linux, workstation di sviluppo o flotte Android aziendali, Bad Epoll è un chiaro caso da trattare con priorità alta: patch del kernel disponibile, nessuna mitigazione alternativa valida, e un exploit pubblico con affidabilità prossima al 100%. La lezione più ampia è che, nonostante i progressi degli strumenti di analisi automatica basati su AI nel trovare bug di concorrenza nel kernel, la revisione umana e soprattutto la prontezza nell’applicare le patch di sicurezza restano parte essenziale della gestione del rischio su qualunque infrastruttura Linux.

Fonte: 4sysops.com, con approfondimenti da The Hacker News e Cyber Security News.

Manifest V2 è ufficialmente morto: cosa cambia da Chrome 150

Con il rilascio di Chrome 150 (fine giugno 2026), Google ha chiuso anche l’ultimo varco rimasto aperto sul Manifest V2: il flag sperimentale che permetteva, a chi lo attivava manualmente, di continuare a eseguire estensioni legacy. Il percorso di deprecazione era iniziato molto prima — le prime disattivazioni erano comparse già nei canali pre-stable di Chrome 127 a metà 2024, la rimozione del criterio enterprise che consentiva alle aziende di rimandare il cambio era arrivata con Chrome 139, e da Chrome 138 il Manifest V2 risultava già disabilitato su tutti i canali per gli utenti privati. Chrome 150 chiude il cerchio: da qui in avanti, chi mantiene un’estensione in Manifest V2 non ha più alcuna via di fuga lato utente, solo il downgrade manuale a una versione precedente del browser, un’operazione sconsigliata perché rinuncia a tutte le patch di sicurezza successive.

Per chi sviluppa o mantiene estensioni Chrome — plugin aziendali, ad blocker interni, tool di produttività distribuiti via policy — il messaggio è netto: la riscrittura in Manifest V3 non è più rimandabile. Vediamo cosa cambia concretamente e come affrontare la migrazione senza sorprese.

Perché Google ha fatto questa scelta

Manifest V3 nasce da un problema reale: il modello di background page persistente di V2 teneva in memoria un intero processo per ogni estensione installata, con un impatto misurabile su RAM e batteria. Inoltre l’API webRequest, che permetteva alle estensioni di intercettare e modificare ogni richiesta di rete in tempo reale con codice arbitrario, è da anni uno dei vettori più sfruttati per iniettare codice malevolo o dirottare il traffico dell’utente. Sostituendola con un sistema dichiarativo, Chrome elimina una classe intera di vulnerabilità, al costo di una minore flessibilità per gli sviluppatori legittimi (è il motivo per cui alcuni ad blocker complessi, come le versioni più sofisticate di uBlock Origin, hanno dovuto ripensare parte della loro logica di filtro).

Le tre modifiche strutturali che servono per migrare

1. Da background page a service worker

In Manifest V2 il background script veniva dichiarato così:

{
  "manifest_version": 2,
  "background": {
    "scripts": ["background.js"],
    "persistent": true
  }
}

{
  "manifest_version": 3,
  "background": {
    "service_worker": "background.js"
  }
}

• registrare tutti i listener di eventi (chrome.runtime.onMessage, chrome.alarms.onAlarm, ecc.) in modo sincrono, nella prima esecuzione dello script — se li registri dentro una callback asincrona rischi che il service worker si riattivi senza agganciare l’evento;
• spostare qualunque stato che deve sopravvivere ai riavvii su chrome.storage.local o chrome.storage.session, mai su variabili globali;
• sostituire i timer lunghi basati su setTimeout/setInterval con l’API chrome.alarms, l’unica garantita a sopravvivere alla terminazione del worker.

2. Da webRequest a declarativeNetRequest

Questo è il cambiamento che rompe più estensioni esistenti. In V2 potevi intercettare ogni richiesta e decidere via codice cosa farne:

chrome.webRequest.onBeforeRequest.addListener(
  (details) => ({ cancel: details.url.includes("ads") }),
  { urls: ["<all_urls>"] },
  ["blocking"]
);

{
  "permissions": ["declarativeNetRequest"],
  "declarative_net_request": {
    "rule_resources": [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules.json"
    }]
  }
}

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||ads.example.com",
      "resourceTypes": ["script", "image", "xmlhttprequest"]
    }
  }
]

chrome.declarativeNetRequest.updateDynamicRules({
  addRules: [ /* nuove regole */ ],
  removeRuleIds: [1, 2, 3]
});

3. Content Security Policy più rigida

Manifest V3 vieta il caricamento di codice remoto e l’uso di eval() o di stringhe passate a setTimeout. Ogni script deve essere incluso nel pacchetto dell’estensione al momento della submission. Se la tua estensione scarica script da un CDN esterno per aggiornare la logica senza ripassare dallo store, quella pratica va eliminata: è esattamente il tipo di comportamento che V3 vuole rendere impossibile.

Un percorso di migrazione pragmatico

Per un’estensione di media complessità, un ordine di lavoro che funziona bene nella pratica:

1. Aggiorna manifest_version a 3 e correggi gli errori di validazione più ovvi (campi rinominati, permessi da dichiarare esplicitamente in host_permissions invece che in permissions).
2. Converti il background script in service worker e verifica con i DevTools dell’estensione (chrome://extensions → “Ispeziona service worker”) che i tuoi eventi vengano ricevuti anche dopo un riavvio forzato del worker.
3. Mappa ogni regola di webRequest blocking in una regola dichiarativa equivalente; per i casi che non si lasciano esprimere in modo dichiarativo (analisi del body della richiesta, per esempio) valuta se il caso d’uso può spostarsi lato server o va accettato come limite architetturale.
4. Testa il ciclo di vita del service worker esplicitamente, non solo la logica funzionale: è la causa più comune di bug “intermittenti” post-migrazione.

Cosa fare se dipendi da un’estensione ancora in V2

Se in azienda usate ancora plugin legacy indispensabili, l’unica strada supportata da Google è il downgrade manuale a Chrome 148 (l’ultima build con supporto V2 completo), disabilitando i servizi “Google Updater” e “Google Updater Internal” da Windows per bloccare l’aggiornamento automatico, e aggiungendo flag da riga di comando al collegamento per bypassare la logica di deprecazione. È un compromesso rischioso, perché rinuncia a tutte le patch di sicurezza rilasciate da quel momento in poi, e va considerato solo come misura temporanea mentre si pianifica la migrazione o la sostituzione dell’estensione. Alcuni browser basati su Chromium, come Firefox (che usa un motore diverso ma supporta ancora API equivalenti a webRequest) o Opera, hanno dichiarato l’intenzione di mantenere più a lungo il supporto a funzionalità simili a V2: per estensioni interne aziendali può essere un’alternativa da valutare, con le dovute cautele su compatibilità e manutenzione nel lungo periodo.

Fonte: 4sysops.com

Si parla di:
Toggle

Per anni Scattered Spider ha costruito la propria reputazione criminale sulla capacità di restare invisibile, nascondendosi dietro VPN, servizi di anonimizzazione e infrastrutture usa e getta. Ora, atti giudiziari appena desecretati mostrano come gli investigatori statunitensi abbiano comunque ricostruito l’identità di un presunto membro del gruppo grazie a un ingrediente inatteso: un identificativo univoco che Windows assegna a ogni installazione e che Microsoft ha fornito all’FBI dietro ordine del tribunale.

Chi è Peter Stokes e cosa gli viene contestato

Al centro del caso c’è Peter Stokes, 19 anni, cittadino con doppio passaporto statunitense ed estone, arrestato in aprile in Finlandia mentre tentava di imbarcarsi su un volo diretto in Giappone, con la collaborazione della National Bureau of Investigation finlandese. È stato successivamente estradato negli Stati Uniti e ha affrontato la sua prima udienza davanti a un tribunale federale di Chicago il 30 giugno 2026. I procuratori lo accusano di aver fatto parte di Scattered Spider, il collettivo cybercriminale noto anche con gli alias Octo Tempest, UNC3944 e 0ktapus, e di aver partecipato a molteplici intrusioni informatiche, furti di dati e schemi di estorsione.

Secondo l’accusa, le autorità federali attribuiscono al gruppo oltre 100 intrusioni di rete e più di 100 milioni di dollari in pagamenti di riscatto dal 2022 a oggi, con un modus operandi che combina ingegneria sociale, furto di credenziali, SIM swapping e compromissione di ambienti cloud enterprise.

GDID: il “device fingerprint” che nessuno può disattivare

Il dettaglio tecnico più rilevante della vicenda riguarda il Global Device Identifier (GDID), un identificativo univoco assegnato da Microsoft a ogni installazione di Windows per finalità di telemetria a livello di dispositivo e per l’erogazione di alcuni servizi di piattaforma. Secondo l’affidavit dell’FBI reso pubblico, un account ngrok utilizzato durante una delle intrusioni contestate era stato creato attraverso una VPN — ma Microsoft, dopo aver ricevuto un ordine del tribunale, è stata in grado di associare quell’attività a uno specifico GDID.

Da lì, gli investigatori hanno incrociato il GDID con la telemetria storica di Microsoft, individuando ulteriori indirizzi IP riconducibili alla stessa installazione Windows in periodi diversi. Questi indirizzi sono stati poi correlati con i log di accesso ottenuti da Snapchat, Apple, Facebook, con i registri di viaggio e con altre fonti digitali, costruendo — secondo l’accusa — un pattern coerente che collega il dispositivo a Stokes. Microsoft, va precisato, non ha monitorato l’attività in tempo reale: ha fornito telemetria storica e informazioni sul dispositivo solo dopo un iter legale formale, e aveva già inoltrato segnalazioni penali su Stokes come possibile membro di Scattered Spider fin dal 2024.

Timeline del caso

• 2024 — Microsoft inoltra alle autorità le prime segnalazioni penali su Stokes come possibile membro di Scattered Spider
• Maggio 2025 — intrusione contro un rivenditore statunitense di gioielleria di lusso: l’help desk IT viene manipolato con ingegneria sociale per resettare le credenziali di un dipendente
• Maggio 2025 — esfiltrazione di circa 100 GB di dati e richiesta di riscatto da 8 milioni di dollari in criptovaluta; l’azienda rifiuta di pagare ma subisce perdite operative stimate in circa 2 milioni di dollari
• Aprile 2026 — Stokes viene arrestato a Helsinki mentre tenta di imbarcarsi su un volo per il Giappone
• 30 giugno 2026 — prima udienza federale a Chicago dopo l’estradizione

Non solo telemetria: un mosaico di prove digitali

Nonostante il dibattito online si sia concentrato quasi esclusivamente sul ruolo di Microsoft, l’affidavit chiarisce che gli investigatori si sono basati su molteplici fonti indipendenti: log dei provider cloud, infrastruttura sequestrata, comunicazioni intercettate e prove digitali raccolte nel corso di un’indagine più ampia. È un promemoria importante per chi si occupa di threat intelligence e incident response: l’attribuzione moderna raramente si basa su un singolo indicatore, ma su una correlazione incrociata tra fonti eterogenee — piattaforma, cloud provider, social network, dati di viaggio — che insieme riducono drasticamente lo spazio delle identità plausibili, anche quando l’attaccante ha fatto ampio uso di VPN e servizi di anonimizzazione.

Implicazioni per i difensori e per il settore

Il caso Stokes offre due lezioni parallele. La prima riguarda la resilienza dei processi organizzativi: l’attacco alla gioielleria di lusso è iniziato con un classico vishing/social engineering contro l’help desk IT, lo stesso schema che ha permesso a Scattered Spider di colpire catene alberghiere, compagnie aeree e assicurazioni negli ultimi anni. Rafforzare le procedure di verifica dell’identità per il reset delle credenziali — con callback verification, domande di sicurezza fuori banda o approvazione multi-step — resta la contromisura più efficace e meno costosa contro questo genere di intrusioni.

La seconda lezione riguarda l’attribuzione: la vicenda GDID dimostra che le piattaforme cloud e i sistemi operativi moderni generano una quantità di telemetria sufficiente a ricostruire pattern comportamentali anche a distanza di mesi, sollevando al contempo interrogativi legittimi sulla portata e sulla durata di conservazione di questi dati per finalità che vanno ben oltre il semplice funzionamento del prodotto. Per i team SOC, il takeaway operativo è monitorare con attenzione l’uso di strumenti di tunneling come ngrok all’interno del proprio perimetro: la loro presenza, specie se associata ad accessi VPN anomali, resta uno dei segnali più affidabili di attività Scattered Spider in corso.

Indicatori e TTP noti

Gruppo: Scattered Spider (alias Octo Tempest, UNC3944, 0ktapus)
Soggetto: Peter Stokes, 19 anni, cittadinanza USA/Estonia
Arresto: aprile 2026, Helsinki (Finlandia), tentata fuga verso il Giappone
Estradizione/udienza: 30 giugno 2026, tribunale federale di Chicago

TTP osservate:
  - Vishing / social engineering verso help desk IT per reset credenziali
  - SIM swapping
  - Furto di token/sessioni cloud (Azure, SaaS enterprise)
  - Tunneling via ngrok per infrastruttura C2 temporanea
  - Esfiltrazione dati seguita da estorsione in criptovaluta

Caso di riferimento: intrusione maggio 2025 contro rivenditore di gioielleria di lusso USA
  - ~100 GB di dati esfiltrati
  - Richiesta riscatto: $8.000.000 in criptovaluta (rifiutata)
  - Perdite operative stimate: ~$2.000.000

Fonte identificativa chiave: Microsoft Global Device Identifier (GDID)
  - Fornito all'FBI dietro ordine del tribunale
  - Correlato con IP storici, login Snapchat/Apple/Facebook, dati di viaggio

Perché systemd è ancora il cuore di ogni server Linux moderno

Chiunque amministri sistemi Linux ha digitato decine di volte comandi come systemctl start o systemctl enable senza fermarsi troppo a pensare a cosa succede realmente sotto il cofano. systemd è l’init system presente sulla stragrande maggioranza delle distribuzioni Linux in produzione, e gli unit file sono il meccanismo con cui gli si dice cosa eseguire, quando eseguirlo e come comportarsi in caso di errore.

Conoscere a fondo la sintassi degli unit file e le tecniche di troubleshooting non è un esercizio accademico: è ciò che fa la differenza tra risolvere un servizio bloccato in due minuti o passare mezza giornata a indovinare. Vediamo come scrivere service unit robusti, quali opzioni contano davvero e come diagnosticare i fallimenti più comuni.

Anatomia di un service unit file

Un unit file è un file di configurazione testuale che descrive una risorsa gestita da systemd: servizi (.service), timer (.timer), socket (.socket), mount point (.mount) e altro ancora. In questo articolo ci concentriamo sui service unit, che sono quelli con cui la maggior parte dei sistemisti ha a che fare quotidianamente.

Prima regola pratica: sapere dove vivono i file.

• /lib/systemd/system/ o /usr/lib/systemd/system/ — unit forniti dai pacchetti di sistema, da non modificare mai direttamente
• /etc/systemd/system/ — dove lavori tu: unit personalizzati e override
• /run/systemd/system/ — unit runtime, spariscono al reboot

I file in /etc/systemd/system/ hanno precedenza su quelli in /lib/systemd/system/: è così che funzionano gli override.

Un service unit tipico si compone di tre sezioni: [Unit], [Service] e [Install]. Ecco un esempio minimo ma realistico per un’app Python:

[Unit]
Description=My Python Web App
After=network.target

[Service]
Type=simple
User=webapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/python app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

La sezione [Unit]: ordinamento, non dipendenza

After=network.target indica solo l’ordine di avvio, non una vera dipendenza: il servizio parte dopo che la rete di base è stata configurata, ma non è garantito che un’interfaccia sia effettivamente raggiungibile. Per servizi che devono fare connessioni in uscita all’avvio (database, agenti di sincronizzazione, chiamate verso internet) è preferibile usare network-online.target:

[Unit]
After=network-online.target
Wants=network-online.target

systemctl is-enabled NetworkManager-wait-online.service

La sezione [Service]: dove si gioca la partita

Il parametro Type= descrive come si comporta il processo all’avvio, e sbagliarlo è una delle cause più comuni di servizi che sembrano non funzionare mai correttamente:

• Type=simple (default) — systemd considera il servizio avviato non appena parte il processo ExecStart. Va bene per processi in foreground.
• Type=forking — per demoni “vecchio stile” che fanno fork in background. systemd attende che il processo padre termini; serve quasi sempre PIDFile=.
• Type=notify — il processo notifica la propria disponibilità via sd_notify(). Più affidabile di simple per applicazioni complesse.
• Type=oneshot — per script che eseguono e terminano. Aggiungi RemainAfterExit=yes se vuoi che risulti “active” anche dopo l’uscita.
• Type=exec (systemd 240+) — simile a simple, ma systemd attende l’effettiva execve() del binario prima di considerare il servizio avviato, intercettando i casi in cui ExecStart non riesce nemmeno a partire.

Un dettaglio spesso sottovalutato riguarda i wrapper shell in ExecStart. Se usi:

ExecStart=/bin/bash -c 'echo started >> /var/log/myapp.log && /opt/myapp/start.sh'

Sulla gestione dei riavvii automatici, Restart=on-failure è la scelta più sensata per la maggior parte dei servizi (riavvia su codici di uscita diversi da zero, segnali o timeout), mentre Restart=always va usato con cautela. RestartSec=5 aggiunge un ritardo prima del riavvio: senza, un servizio rotto martella il sistema in loop.

Override sicuri: mai toccare i file dei pacchetti

Non modificare mai i file in /lib/systemd/system/: gli aggiornamenti dei pacchetti sovrascrivono le modifiche. Il modo corretto è usare i drop-in override:

systemctl edit nginx

[Service]
LimitNOFILE=65536
Restart=on-failure

Hardening: sandboxing gratuito integrato in systemd

systemd offre funzionalità di sandboxing native che riducono la superficie d’attacco in caso di compromissione del servizio. Da aggiungere nella sezione [Service]:

# Impedisce l'acquisizione di nuovi privilegi
NoNewPrivileges=yes

# /tmp privato e isolato
PrivateTmp=yes

# Accesso in sola lettura a /usr, /boot, /etc
ProtectSystem=strict

# Impedisce la scrittura nelle home directory
ProtectHome=yes

# Restringe le famiglie di indirizzi utilizzabili
RestrictAddressFamilies=AF_INET AF_INET6

# Limita le syscall a un set sicuro
SystemCallFilter=@system-service

systemd timer: un sostituto moderno di cron

I timer di systemd sono un’alternativa spesso sottovalutata a cron, con logging integrato, gestione delle dipendenze ed esecuzione “catch-up” se il sistema era spento all’orario previsto. Servono due file: il timer e il service corrispondente.

/etc/systemd/system/backup.service:

[Unit]
Description=Nightly Backup

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup.sh

[Unit]
Description=Run backup nightly at 2am

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now backup.timer
systemctl list-timers

Troubleshooting sistematico dei servizi falliti

Quando un servizio fallisce, conviene seguire un percorso ripetibile invece di procedere per tentativi.

1. Controlla lo stato

systemctl status myapp

● myapp.service - My Python Web App
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
     Active: failed (Result: exit-code) since Tue 2026-05-05 14:22:01 UTC
    Process: 1234 ExecStart=/opt/myapp/venv/bin/python app.py (code=exited, status=203/EXEC)

2. Leggi il journal

journalctl -u myapp -n 50      # ultime 50 righe
journalctl -u myapp -f         # segui in tempo reale
journalctl -u myapp -b         # dall'ultimo boot
journalctl -u myapp -b -1      # dal boot precedente

3. Verifica errori di sintassi

systemd-analyze verify /etc/systemd/system/myapp.service

4. Testa manualmente ExecStart

sudo -u webapp /opt/myapp/venv/bin/python app.py

Pattern di errore comuni

• status=203/EXEC: binario non trovato o non eseguibile
• status=217/USER: l’utente specificato in User= non esiste
• status=200/CHDIR: WorkingDirectory non esiste o non è accessibile
• Start request repeated too quickly: crash-loop; aggiungi RestartSec= e resetta il contatore con systemctl reset-failed myapp
• Timeout on start: il servizio non ha segnalato la propria disponibilità in tempo; verifica se Type= è corretto (un demone che fa fork con Type=simple va cambiato in Type=forking)

Un esempio production-ready

Ecco un unit file completo per un’API Node.js che riassume le best practice viste finora:

[Unit]
Description=Node.js API Server
Documentation=https://github.com/example/myapi
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/opt/myapi
ExecStart=/usr/bin/node /opt/myapi/server.js
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60
EnvironmentFile=/etc/myapi/env
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapi

# Hardening
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/myapi /var/log/myapi

[Install]
WantedBy=multi-user.target

Comandi rapidi da tenere a portata di mano

# Start, stop, restart, reload
systemctl start myapp
systemctl stop myapp
systemctl restart myapp
systemctl reload myapp

# Abilitazione al boot
systemctl enable myapp
systemctl disable myapp

# Unit completo con override applicati
systemctl cat myapp

# Servizi falliti
systemctl --failed

# Performance di boot
systemd-analyze blame
systemd-analyze critical-chain

Conclusione

Scrivere un service unit non è complicato una volta capito cosa fa ciascuna sezione: [Unit] gestisce ordinamento e dipendenze, [Service] definisce come il processo gira e si riprende dai fallimenti, [Install] controlla il comportamento al boot. Le opzioni di hardening richiedono pochi minuti in più ma vanno inserite di default su ogni servizio esposto in rete. E se ancora lanci job da cron, vale la pena provare un timer systemd: l’integrazione con il journal da sola giustifica il passaggio.

Fonte: LinuxBlog.io – systemd Services: Writing, Managing, and Troubleshooting Unit Files on Linux

Il problema delle soglie statiche negli alert

Chiunque gestisca alert su log query in Azure Monitor conosce il dilemma delle soglie statiche: se il valore è troppo basso, si ricevono notifiche continue per fluttuazioni normali (l’autoscaling di un cluster AKS, il traffico più alto del lunedì mattina, i picchi stagionali di un e-commerce); se è troppo alto, si rischia di non accorgersi di un’anomalia reale finché non è troppo tardi. Il risultato tipico è affaticamento da alert, team che silenziano le notifiche, e problemi che passano inosservati.

Azure Monitor affronta questo problema con le soglie dinamiche (dynamic thresholds) per gli alert su ricerca di log, ora in disponibilità generale e senza costi aggiuntivi rispetto alla normale tariffa degli alert su log query. Vale la pena approfondire come funzionano e come configurarle correttamente, perché il vantaggio pratico per chi gestisce infrastrutture Azure è notevole.

Come funzionano le soglie dinamiche

Le soglie dinamiche applicano algoritmi di machine learning ai risultati delle query di log per apprenderne il comportamento storico. Il sistema analizza i dati nel tempo e identifica pattern ricorrenti — la cosiddetta seasonality, ovvero le fluttuazioni prevedibili che si ripetono a intervalli regolari (orari, giornalieri, settimanali). Quando i risultati della query si discostano in modo significativo dal pattern appreso, l’alert scatta.

In pratica, quando si crea una regola di alert, le soglie dinamiche utilizzano inizialmente 10 giorni di dati storici per calcolare i pattern stagionali orari e giornalieri. Dopo tre settimane, il sistema ha raccolto abbastanza dati da identificare anche i pattern settimanali e aggiusta il modello di conseguenza. Le soglie continuano ad apprendere dai nuovi dati, migliorando l’accuratezza nel tempo.

Configurare un alert su log search con soglia dinamica

La configurazione parte dalla procedura standard per creare una regola di alert su ricerca di log nel portale Azure: si definisce la query, la misurazione e le dimensioni esattamente come si farebbe con una soglia statica. La differenza sta nella sezione Alert logic:

• Per Threshold, selezionare Dynamic invece di Static.
• Per Operator, scegliere tra tre opzioni: Greater than the upper threshold or lower than the lower threshold (l’opzione predefinita, che considera entrambe le direzioni), Greater than the upper threshold, oppure Lower than the lower threshold. Le soglie dinamiche calcolano sia un limite superiore sia uno inferiore, quindi si può scegliere quale tipo di deviazione deve far scattare l’alert.
• Per Threshold sensitivity, selezionare High, Medium (predefinito) o Low. La sensibilità alta imposta soglie strette vicine al pattern misurato e scatta anche per deviazioni minime; quella bassa tollera scostamenti maggiori e si attiva solo per anomalie evidenti.

Dopo aver configurato la condizione, il pulsante Preview Chart mostra i risultati storici della query insieme all’intervallo di soglia calcolato: una linea blu per i valori misurati, un’area viola per l’intervallo di soglia consentito, punti rossi per le violazioni della soglia e barre rosa per gli alert effettivamente scattati. Dopo ogni modifica alla condizione, è necessario selezionare Refresh Chart per aggiornare l’anteprima.

// Esempio di query KQL usata come base per un alert con soglia dinamica
// (conteggio dei riavvii dei pod in un cluster AKS)
KubePodInventory
| where TimeGenerated > ago(1h)
| summarize RestartCount = sum(PodRestartCount) by ClusterName, Namespace, Name

Suddividere l’alert per dimensioni

Una delle funzionalità più utili per chi gestisce ambienti multi-risorsa è la possibilità di suddividere la valutazione dell’alert per dimensioni, ovvero colonne dei risultati della query che contengono dati aggiuntivi come nomi di risorse, namespace o ID di sottoscrizione. Quando si usano le dimensioni, la regola di alert valuta separatamente ogni combinazione di dimensioni e genera un alert indipendente per ciascun gruppo che soddisfa la condizione. È possibile applicare fino a sei dimensioni per regola.

Un caso pratico: monitorare i riavvii dei pod in un cluster AKS suddividendo per Namespace e Name, in modo che ogni namespace e ogni pod ottenga una propria baseline di soglia dinamica. Questo evita che un singolo alert generico “spari” per l’intero cluster quando in realtà è un solo namespace ad avere un comportamento anomalo, e permette al modello di adattarsi a fluttuazioni normali dovute all’autoscaling.

Limiti da conoscere prima di usarle in produzione

Alcune limitazioni sono importanti da tenere a mente per non avere aspettative sbagliate:

• La frequenza minima di valutazione è di 5 minuti.
• Le regole non scattano prima di aver raccolto almeno 3 giorni e 30 campioni di dati: risorse nuove o con dati mancanti non genereranno alert finché non ci sono dati sufficienti.
• Servono almeno 3 settimane di dati storici per rilevare la stagionalità settimanale; pattern come cicli bi-orari o semi-settimanali potrebbero non essere rilevati affatto.
• Le soglie dinamiche sono pensate per rilevare deviazioni significative e improvvise, non problemi che si sviluppano lentamente: un degrado graduale delle prestazioni probabilmente non farà scattare l’alert.
• Non è possibile usare soglie dinamiche in regole che monitorano più condizioni contemporaneamente.
• La configurazione è possibile tramite portale Azure o template ARM; PowerShell e Azure CLI non sono ancora supportati per le regole di alert su log search con soglie dinamiche.
• Il grafico di anteprima ha limiti sull’intervallo temporale in base alla frequenza della regola: con frequenza di 5 minuti si vedono fino a 6 ore di dati, con frequenza di un’ora o superiore fino a 2 giorni.

Come ridurre il rumore (o aumentare la sensibilità)

Se una regola scatta troppo spesso, ci sono diverse leve da regolare prima di abbandonare l’approccio: abbassare la sensibilità della soglia a Low per tollerare deviazioni maggiori, aumentare la granularità di aggregazione (la finestra temporale usata per raggruppare i punti dati) per ridurre la sensibilità a picchi transitori, oppure configurare nelle impostazioni avanzate il numero di violazioni richieste in un determinato periodo prima che l’alert scatti effettivamente.

Al contrario, se una regola non è abbastanza sensibile nemmeno con sensibilità alta, è probabile che la distribuzione dei dati sia molto irregolare. In questi casi Microsoft consiglia di verificare se nei 10 giorni precedenti si è verificato un cambiamento drastico nel comportamento dei dati — per esempio un’interruzione di servizio — che può aver alterato il calcolo delle soglie. Un’altra opzione è monitorare una metrica complementare o modificare la granularità di aggregazione.

Due casi d’uso concreti

Microsoft evidenzia due scenari tipici. Il primo riguarda il monitoraggio dei riavvii dei pod Kubernetes tramite la tabella KubePodInventory, riassumendo i conteggi per cluster, namespace e nome del pod: le soglie dinamiche si adattano alle fluttuazioni normali causate dall’autoscaling e generano alert solo per anomalie reali. Il secondo riguarda il rilevamento di drift nell’inventario delle risorse tramite query di Azure Resource Graph: contando le risorse per tipo e ID sottoscrizione, le soglie dinamiche possono identificare picchi improvvisi nella creazione o cancellazione di risorse che potrebbero indicare deployment fuori controllo, adattandosi ai pattern stagionali di deployment che una soglia statica non riuscirebbe a gestire.

Conclusione

Le soglie dinamiche per gli alert su log search sono una delle funzionalità più concretamente utili di Azure Monitor per chi gestisce ambienti con carichi variabili nel tempo: riducono il rumore degli alert senza richiedere di indovinare manualmente una soglia statica per ogni metrica, e si adattano automaticamente quando cambia la scala dell’infrastruttura. Detto questo, non sono una bacchetta magica: richiedono tempo per costruire una baseline affidabile (fino a tre settimane per la stagionalità settimanale) e non sono adatte a rilevare degradi lenti e progressivi. Per la maggior parte degli scenari di monitoraggio di infrastrutture Azure dinamiche — cluster Kubernetes, ambienti con autoscaling, fleet di risorse in continua evoluzione — rappresentano comunque un netto miglioramento rispetto alle soglie statiche tradizionali.

Fonte: 4sysops.com, con riferimenti alla documentazione ufficiale Microsoft Learn.