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