Spcnet.it

2026-07-10 13:26:33

Network Bonding su Linux: guida completa a ridondanza e throughput aggregato

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

Se restituisce le informazioni del modulo, si può procedere caricandolo:

sudo modprobe bonding

Prima di modificare qualsiasi configurazione, è indispensabile identificare le interfacce disponibili:

ip link show

Sui sistemi moderni i nomi saranno del tipo enp3s0, enp4s0, oppure i più tradizionali eth0, eth1. Annotarli, perché verranno referenziati per tutta la configurazione.

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"

Aggiungere le interfacce fisiche come slave del bond:

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

Assegnare un indirizzo IP statico al bond:

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

Oppure, per usare il DHCP:

sudo nmcli con modify bond0 ipv4.method auto

Attivare il bond:

sudo nmcli con up bond0

Le interfacce slave dovrebbero attivarsi automaticamente. In caso contrario, portarle su manualmente:

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

Verificare lo stato del bond:

cat /proc/net/bonding/bond0

Il file /proc/net/bonding/bond0 è lo strumento diagnostico principale: va consultato ogni volta che qualcosa non sembra funzionare come previsto.

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

Creare la configurazione di rete per l’interfaccia bond (esempio DHCP):

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

[Match]
Name=bond0

[Network]
DHCP=yes

Vincolare le interfacce fisiche al bond, un file per ciascuno slave:

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

[Match]
Name=enp3s0

[Network]
Bond=bond0

Riavviare systemd-networkd e verificare:

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

Applicare la configurazione:

sudo netplan apply

Se si sta lavorando da remoto, Netplan offre una modalità di test sicura che ripristina automaticamente la configurazione precedente dopo 120 secondi se non viene confermata:

sudo netplan try

Per usare LACP, basta modificare il blocco parameters:

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"

La policy transmit-hash-policy: layer2+3 distribuisce il traffico basandosi sia sull’indirizzo MAC sia sull’IP, offrendo una distribuzione del carico migliore rispetto alla policy predefinita solo layer2.

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

In un altro terminale, disattivare l’interfaccia attiva:

sudo ip link set enp3s0 down

Si osserveranno al massimo uno o due pacchetti persi, poi il traffico continuerà a fluire attraverso l’interfaccia di backup. Verificare lo stato del bond:

cat /proc/net/bonding/bond0

La riga Currently Active Slave mostrerà il passaggio alla seconda interfaccia. Per impostare un’interfaccia primaria preferita:

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

Se il contatore dei fallimenti su una sola interfaccia cresce mentre il sistema funziona normalmente, probabilmente c’è un cavo o una porta dello switch difettosa: conviene sostituirli prima che il guasto si presenti nel momento peggiore.

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"

updelay e downdelay prevengono il flapping su link instabili: impostarli ad almeno il doppio del valore di miimon.

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

Linux Network Bonding: Combine Network Interfaces | LinuxBlog.io

Two network interfaces are better than one. With Linux network bonding (also known as NIC bonding or link aggregation), you can combine multiple NICs into

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-10 13:26:37

NetScaler MCP Gateway: Citrix mette ordine nel traffico degli agenti AI aziendali

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

Citrix NetScaler adds MCP Gateway to secure and govern AI agent traffic – 4sysops

Citrix has updated its NetScaler platform to include Model Context Protocol (MCP) Gateway functionality for enterprise environments. The Model Context Protocol

^{IT News (4sysops)}

noyb.eu

2026-06-12 11:25:12

🇦🇹👤 #CRIF is one of the largest credit reference agencies in #Austria. It has built up a largely unknown ‘shadow registry’ and use this data to assign credit scores. However, for 90% of those affected, the score is based primarily only on address, gender and age.

❌ We are convinced that this unwarranted data collection and the scoring of those 90% violates the #GDPR. We are therefore bringing an injunction and a class action for damages.

To sign up, go to crif.noyb.eu! 🤝

Spcnet.it

2026-07-09 20:36:24

PHP-FPM: perché ‘pm static’ batte ‘dynamic’ e ‘ondemand’ sui server ad alto traffico

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" }'

Poi si divide la memoria che si intende dedicare a PHP-FPM per questo valore medio. Se un worker occupa in media 60 MB e si vogliono destinare 6 GB a PHP-FPM, il calcolo è 6144 / 60 ≈ pm.max_children = 100. È fondamentale lasciare margine per sistema operativo, web server e database, evitando di assegnare a PHP-FPM tutta la RAM fisica disponibile.

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

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

Con questi valori, anche con circa 200 utenti attivi simultanei (dato realistico osservato con Google Analytics), circa il 70% dei worker resta inattivo ma pronto: non deve essere creato al volo quando arriva un picco di traffico, e non viene distrutto dopo il timeout di pm.process_idle_timeout come accadrebbe con dynamic. Il valore di pm.max_requests va tenuto alto (o a 0, se non si hanno memory leak noti negli script) proprio per evitare che il process manager ricicli continuamente i worker, vanificando il vantaggio di static.

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

Il consiglio classico è aumentare i valori minimi, ma su traffico molto variabile il tuning di dynamic resta complesso. Passare a ondemand aiuta a risparmiare memoria, ma su un server costantemente sotto carico introduce l’effetto opposto: i worker vengono azzerati appena il traffico cala, per poi dover essere ricreati non appena il traffico torna, spostando il costo dalla memoria alla latenza di avvio.

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

PHP-FPM tuning: Using 'pm static' for max performance | LinuxBlog.io

Let's take a quick look at how best to set up PHP-FPM for high throughput, low latency, and more stable CPU and memory use. By default, most setups have

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-09 20:36:36

Infrastrutture AI esposte: come gli attaccanti dirottano gateway come LiteLLM per alimentare agenti autonomi

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.

Exposed Enterprise AI Systems Used to Power Autonomous Attack Agents

Cybercriminals are exploiting exposed enterprise AI infrastructure to run autonomous agents, reconnaissance tools, and offensive operations.

^{Rabia Noureen (Petri IT Knowledgebase)}

(in)sicurezza digitale

2026-07-09 20:40:08

Il Canada svela le sue cyber-armi: la CSE rivendica l’hackeraggio di una gang ransomware-as-a-service

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

N_{Dario Fadda}

2026-07-09 13:16:55

Il dettaglio italiano della votazione odierna sulla Proposta di rifiuto di Chat Control.

Dovremo ricordarci sempre di tutte le persone che ci rappresentano a favore di questa porcheria (quindi contrarie al rifiuto)

dariofadda.it/chat-control/202…

#stopchatcontrol

Chat Control - Dashboard votazione UE

^{dariofadda.it}