Spcnet.it

2026-08-19 15:56:10

5 controlli infrastrutturali per mettere in sicurezza gli agenti AI (oltre il prompt)

Quanti team stanno collegando agenti AI a Slack, a un’interfaccia web o a server MCP proteggendo l’accesso solo con un prompt di sistema ben scritto? Secondo un’analisi pubblicata su DZone e basata su findings del Red Team di NVIDIA, è proprio questo l’errore architetturale più diffuso nelle implementazioni enterprise di agenti AI: “i guardrail basati sul prompt falliscono sotto pressione avversaria”. Un attaccante sufficientemente motivato può camuffare attività malevole da comportamenti legittimi, scalare privilegi gradualmente o nascondere esecuzione di codice dentro interazioni apparentemente normali.

Il punto chiave, riassunto efficacemente dall’articolo originale, è questo: il modello non è il punto di applicazione della sicurezza, è la cosa che va difesa. Va trattato come qualsiasi altro componente non fidato della vostra infrastruttura — proprio come fareste con un processo che esegue codice arbitrario ricevuto da input esterni. In questo articolo ripercorriamo i cinque controlli infrastrutturali proposti, con esempi pratici applicabili su Kubernetes e nello stack Microsoft.

1. Identità e propagazione dell’autenticazione

Il primo errore comune è usare credenziali condivise per l’agente, indipendentemente da chi lo stia effettivamente invocando (via Slack, web UI o endpoint MCP). Questo rende impossibile distinguere un’azione legittima da un abuso e complica ogni audit successivo.

La soluzione è propagare l’identità dell’utente umano fino ai sistemi a valle, invece di far agire l’agente con un account di servizio onnipotente. Lo standard di riferimento è OAuth 2.0 Token Exchange (RFC 8693), che permette di scambiare il token dell’utente con un token downstream a scope ridotto e vita breve:

POST /oauth2/token HTTP/1.1
Host: identity.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token={USER_TOKEN}
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=ticketing-api
&scope=tickets.read tickets.comment

Il token risultante è specifico per l’audience richiesta (in questo caso l’API di ticketing), ha uno scope minimo e una scadenza breve. Ogni chiamata a valle porta con sé l’identità originale dell’utente, non quella generica dell’agente: questo è ciò che rende possibile un audit trail affidabile.

2. Presupporre l’esecuzione di codice e limitarne gli effetti

Un agente con accesso a strumenti di code execution va trattato esattamente come un processo che esegue input non fidato, perché di fatto è quello che è. I controlli minimi da applicare a livello di container:

• filesystem di root read-only;
• noexec su tutti i mount scrivibili, per impedire l’esecuzione di binari scaricati a runtime;
• drop di tutte le capability Linux non strettamente necessarie;
• configurazione dell’agente montata come read-only da un mount point separato, così che l’agente stesso non possa alterare la propria configurazione;
• allowlist esplicita dei binari eseguibili.

Un esempio di `securityContext` Kubernetes coerente con questi principi:

securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
volumeMounts:
  - name: tmp
    mountPath: /tmp
    # mount separato per lo storage scrivibile, con noexec applicato a livello di nodo
  - name: agent-config
    mountPath: /etc/agent
    readOnly: true

3. Egress default-deny

Un agente compromesso o manipolato tramite prompt injection che possa raggiungere qualunque host su Internet è un rischio enorme: esfiltrazione dati, comando e controllo, o accesso agli endpoint di metadata del cloud provider (il classico 169.254.169.254, spesso usato per rubare credenziali IAM). La difesa è una NetworkPolicy Kubernetes default-deny in uscita, con eccezioni esplicite solo verso ciò che serve realmente:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ai-agent-default-deny-egress
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
    - Egress
  egress:
    # consente solo DNS e il proxy autenticato interno
    - to:
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53
    - to:
        - podSelector:
            matchLabels:
              app: egress-proxy
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-cloud-metadata
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

Le connessioni realmente necessarie devono passare attraverso un proxy autenticante con allowlist basata su FQDN, con logging completo di ogni richiesta e dell’identità utente associata: in questo modo ogni chiamata in uscita è tracciabile e limitata a destinazioni note.

4. Nessun segreto persistente

Iniettare segreti tramite variabili d’ambiente, file di configurazione o, peggio, direttamente nel context window del modello è una pratica rischiosa: un agente che legge il proprio ambiente, o che viene indotto a farlo tramite prompt injection, può esfiltrare quei segreti con facilità.

L’approccio consigliato è il token brokering per singolo task, con TTL molto brevi (minuti, non ore) e revoca esplicita al completamento del task, non solo alla scadenza naturale:

• ogni task riceve un token appena sufficiente per l’operazione richiesta;
• il token viene revocato non appena il task termina, indipendentemente dalla sua scadenza nominale;
• ogni emissione di segreto viene registrata con l’identità dell’utente umano che ha originato la richiesta.

Strumenti come Azure Key Vault (con identità gestite e token a vita breve) o soluzioni dedicate di secret brokering per workload agentic vanno preferiti rispetto a qualunque forma di credential injection statica.

5. Controllo della supply chain dei pacchetti

Un agente con capacità di installare pacchetti (npm, pip, NuGet) durante l’esecuzione è una superficie di attacco enorme, soprattutto se può installare da repository VCS arbitrari o eseguire script di post-install non controllati. I controlli minimi:

• uso di repository proxy interni (Artifactory o equivalente) come unica fonte consentita;
• blocco esplicito delle installazioni da URL o VCS diretti (es. pip install git+https://...);
• abilitazione di ignore-scripts=true per prevenire l’esecuzione di script post-install, un vettore di attacco noto nell’ecosistema npm;
• verifica dell’hash dei pacchetti installati.

# .npmrc per l'ambiente dell'agente
registry=https://artifactory.contoso.com/api/npm/npm-proxy/
ignore-scripts=true
audit=true

Validare i controlli con test automatici, non con documentazione

Il consiglio più pratico dell’articolo è forse questo: questi cinque controlli vanno implementati come test case automatici nella pipeline CI/CD, non lasciati a una checklist di sicurezza scritta a mano. Alcuni esempi di assertion da includere:

• un chiamante non autenticato deve essere rifiutato;
• un tentativo di scrittura su file di configurazione nascosti (dotfile) deve fallire;
• ogni connessione in uscita non allowlisted deve essere bloccata e loggata;
• nessun segreto deve essere presente nelle variabili d’ambiente del processo agente;
• l’endpoint di metadata cloud deve risultare irraggiungibile;
• un’installazione di pacchetto da VCS diretto deve essere bloccata dal proxy.

Conclusione

Gli agenti AI non introducono nuovi principi di sicurezza: richiedono di applicare con rigore quelli che già conosciamo — least privilege, isolamento, gestione dei segreti a vita breve, egress controllato — a un tipo di workload che, per sua natura, esegue codice e prende decisioni sulla base di input non completamente prevedibili. Chi gestisce infrastrutture Kubernetes o Azure ha già gli strumenti per implementare questi controlli; il passo mancante, spesso, è semplicemente la decisione di applicarli con la stessa serietà riservata a qualunque altro workload che esegue codice non fidato.

Fonte originale: “5 Infrastructure Controls for Securing AI Agents” su DZone.

RFC 8693: OAuth 2.0 Token Exchange

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.

^{IETF Datatracker}

Spcnet.it

2026-08-19 15:56:13

Un agente AI è un sistema distribuito, non un chatbot: pattern di durable orchestration in .NET

Negli ultimi mesi molti team hanno scoperto a proprie spese che il problema più grande di un agente AI in produzione non è la qualità del prompt, ma la sua affidabilità operativa. Un articolo recente su DZone, “Your AI Agent Is a Distributed System, Not a Chatbot”, mette a fuoco un punto che chi progetta sistemi backend conosce bene da anni: se un componente deve sopravvivere a crash, timeout, retry e attese umane di ore, non puoi trattarlo come una semplice chiamata sincrona a un modello. Devi trattarlo come un sistema distribuito, con tutto ciò che questo comporta: stato persistente, checkpoint, idempotenza e recovery.

In questo articolo riprendiamo quei concetti e li caliamo nella pratica con .NET, mostrando come Azure Durable Functions (o alternative come Temporal) permettano di costruire agenti AI multi-step che non perdono lo stato quando qualcosa va storto — cosa che, in produzione, prima o poi succede sempre.

Perché un chatbot stateless non basta

Un chatbot classico è un ciclo request/response: l’utente scrive, il modello risponde, fine. Un agente AI enterprise, invece, tipicamente deve:

• orchestrare più chiamate a modelli e strumenti in sequenza o in parallelo;
• interrogare sistemi esterni (CRM, ticketing, knowledge base, database);
• attendere l’approvazione di un umano, che può richiedere minuti oppure ore;
• gestire fallimenti parziali senza dover ripartire da zero;
• garantire che un’azione con effetti collaterali (un rimborso, un invio email, una scrittura su un sistema esterno) non venga eseguita due volte per colpa di un retry.

Nessuno di questi requisiti è nuovo: sono gli stessi problemi che i sistemi distribuiti risolvono da decenni con pattern come saga, checkpointing e idempotency key. La differenza è che oggi il “servizio downstream” spesso è un LLM, e la latenza dominante non è più quella di rete, ma quella dell’attesa umana.

Durable orchestration: lo stato che sopravvive al crash

Il pattern architetturale proposto è un runtime di orchestrazione durevole, che mantiene lo stato del workflow indipendentemente dal ciclo di vita del processo che lo esegue. In .NET, l’implementazione più diretta è Azure Durable Functions, che introduce tre concetti chiave:

• Orchestrator function: decide “cosa succede dopo”, applica le retry policy e coordina le chiamate, ma non esegue lavoro con effetti collaterali direttamente;
• Activity function: esegue il lavoro reale (chiamata al modello, query, side effect) ed è il livello dove si applica l’idempotenza;
• Checkpointing automatico: dopo ogni `await`, il runtime salva lo stato dell’orchestrazione, così un crash del processo non fa perdere il progresso già fatto.

Un’alternativa nota, citata anche nell’articolo originale, è Temporal, che applica lo stesso principio con un modello di programmazione simile ma un runtime a sé stante, spesso preferito in contesti multi-linguaggio o Kubernetes-native.

Il pattern fan-out/fan-in per agenti multipli

Quando un task richiede il contributo di più agenti specializzati (per esempio: un agente diagnostico, uno di ricerca sulla knowledge base, uno che consulta lo storico dei casi e uno che verifica le policy aziendali), il pattern corretto è il fan-out/fan-in: l’orchestratore lancia tutte le attività in parallelo e aggrega i risultati solo quando sono tutte terminate.

Ecco un esempio realistico in C# con il modello isolato di Azure Functions, ispirato agli esempi ufficiali Microsoft:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var caseId = context.GetInput<string>();

    // Fan-out: 4 agenti specializzati lanciati in parallelo
    var diagnosticTask = context.CallActivityAsync<AgentFinding>(
        "RunDiagnosticAgent", caseId);
    var knowledgeTask = context.CallActivityAsync<AgentFinding>(
        "RunKnowledgeSearchAgent", caseId);
    var historyTask = context.CallActivityAsync<AgentFinding>(
        "RunHistoricalCaseAgent", caseId);
    var policyTask = context.CallActivityAsync<AgentFinding>(
        "RunPolicyAgent", caseId);

    // Fan-in: si attende che tutti i task completino
    AgentFinding[] findings = await Task.WhenAll(
        diagnosticTask, knowledgeTask, historyTask, policyTask);

    // Sintesi della raccomandazione finale
    var recommendation = await context.CallActivityAsync<Recommendation>(
        "SynthesizeRecommendation", findings);

    return new InvestigationResult(caseId, findings, recommendation);
}

Il vantaggio rispetto a un semplice `Task.WhenAll` in un servizio stateless è che, se il processo host crasha mentre due agenti su quattro hanno già risposto, l’orchestrazione riparte dal checkpoint e non richiama gli agenti già completati.

Human-in-the-loop senza tenere aperta la compute

Il collo di bottiglia più comune non è il modello, ma l’attesa di un’approvazione umana. Un workflow che tenesse una funzione serverless “in ascolto” per ore sarebbe insostenibile in termini di costo e di timeout. Il pattern corretto è sospendere l’orchestrazione in attesa di un evento esterno:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    // ... fan-out/fan-in come sopra ...

    await context.CallActivityAsync("NotifyHumanReviewer", recommendation);

    // Il workflow si sospende senza consumare risorse compute
    // fino a quando l'evento non arriva, anche dopo diverse ore
    var decision = await context.WaitForExternalEvent<HumanReviewDecision>(
        "HumanReviewCompleted");

    if (decision.Approved)
    {
        await context.CallActivityAsync("ApplyResolution", recommendation);
    }

    return new InvestigationResult(caseId, findings, recommendation, decision);
}

L’evento viene “consegnato” all’orchestrazione in pausa tramite una chiamata separata (per esempio da una Function HTTP-triggered collegata a un pulsante “Approva” nella UI), e il runtime si occupa di riprendere l’esecuzione esattamente dal punto in cui era stata sospesa.

Idempotenza: il vero rischio nascosto

Un runtime durevole garantisce tipicamente semantica at-least-once: dopo un crash, un’attività può essere rieseguita. Questo va benissimo per operazioni pure (una query di lettura), ma è pericoloso per operazioni con side effect (un rimborso, un invio email, una scrittura irreversibile). Il momento critico è il cosiddetto crash window: l’intervallo tra il completamento effettivo di un’azione e il salvataggio del suo checkpoint.

La soluzione è associare a ogni operazione critica una idempotency key deterministica, così che una riesecuzione accidentale venga riconosciuta e ignorata a livello applicativo:

[Function("ApplyGoodwillRefund")]
public static async Task ApplyGoodwillRefund(
    [ActivityTrigger] RefundRequest request)
{
    string idempotencyKey = $"{request.CaseId}:goodwill-refund";

    if (await _paymentService.WasAlreadyProcessedAsync(idempotencyKey))
    {
        return; // operazione già eseguita, nessun effetto collaterale duplicato
    }

    await _paymentService.ProcessRefundAsync(request, idempotencyKey);
}

Questo pattern, ben noto a chi lavora con gateway di pagamento, va applicato sistematicamente a ogni activity che tocchi sistemi esterni non idempotenti per natura.

Successo parziale, non tutto-o-niente

Se uno dei quattro agenti fallisce (per esempio, il servizio di knowledge search va in timeout), il sistema non dovrebbe far fallire l’intera indagine. Meglio trattare i risultati come esiti strutturati, distinguendo tra “successo”, “fallito” e “degradato”, e permettere che la sintesi finale proceda comunque, segnalando esplicitamente quali fonti mancano:

public record AgentFinding(
    string AgentName,
    AgentStatus Status,   // Success, Failed, Degraded
    string? Result,
    string? FailureReason);

Questo approccio “graceful degradation” è preferibile a un fallimento totale che obbliga a rieseguire da capo un’indagine costosa in termini di tempo e token consumati.

Osservabilità come requisito di prodotto

In un sistema dove un’indagine può durare ore e coinvolgere quattro o più agenti, la tracciabilità non è un dettaglio tecnico: è parte dell’esperienza utente e, in molti contesti regolamentati, un requisito di audit. Vale la pena tracciare sistematicamente:

• workflow instance ID, correlation ID e case ID;
• lo stage corrente e la durata di ogni singolo agente;
• il numero di retry e il motivo di ogni fallimento;
• la latenza di revisione umana (spesso il fattore dominante);
• la tracciabilità delle evidenze usate per la raccomandazione finale, per scopi di audit.

Conclusione

Il messaggio di fondo è semplice ma spesso trascurato: il workflow conta più del prompt. Un agente AI ben progettato non è quello con il prompt più raffinato, ma quello costruito su un runtime capace di sopravvivere a crash, gestire attese umane di ore senza sprecare risorse, ed evitare effetti collaterali duplicati. Per chi lavora nello stack .NET, Azure Durable Functions offre oggi gli strumenti necessari per applicare questi pattern senza dover reinventare un motore di orchestrazione da zero; per contesti poliglotta o già containerizzati, Temporal resta un’alternativa solida con la stessa filosofia.

Fonte originale: “Your AI Agent Is a Distributed System, Not a Chatbot” su DZone.

Durable Functions Overview: Stateful Serverless Workflows

Learn how Durable Functions extends Azure Functions to build reliable, stateful workflows in a serverless environment. Get started with supported languages, storage providers, and quickstarts.

^{learn.microsoft.com}

(in)sicurezza digitale

2026-08-19 15:54:25

Handala: lo spionaggio iraniano del MOIS che si finge amico dei giornalisti su WhatsApp

Si parla di:
Toggle

Da due anni si spacciava per movimento hacktivista filo-palestinese. Il Dipartimento di Giustizia americano ha invece confermato ciò che gli analisti sospettavano da tempo: dietro il collettivo “Handala” opera il Ministero dell’Intelligence iraniano (MOIS), e il suo bersaglio attuale sono i giornalisti israeliani, contattati su WhatsApp e Telegram con la stessa cura con cui si costruisce una fonte, per rubare loro le credenziali e, in alcuni casi, l’intero telefono.

Lo Shin Bet e l’Autorità nazionale per la cybersicurezza israeliana hanno diffuso il 16 agosto 2026 un avviso congiunto, raro per esplicitezza, in cui si afferma che “gli operativi dell’intelligence iraniana stanno tentando di raccogliere informazioni sensibili su sviluppi politici e di sicurezza, ottenere accesso a fonti giornalistiche, materiali di lavoro e corrispondenza”. Non è un’allerta generica: arriva dopo mesi di segnalazioni da parte di redazioni come Haaretz, i cui cronisti sono stati impersonati per avvicinare colleghi e contatti.

Chi è davvero Handala

Il nome richiama la celebre vignetta del fumettista palestinese Naji al-Ali, e per due anni il brand “Handala Hack Team” ha coltivato un’immagine da collettivo hacktivista indipendente, rivendicando data breach e defacement contro obiettivi israeliani sui propri canali Telegram. È la stessa tattica di copertura vista in altri cluster iraniani — un layer “civile” che permette a Teheran di condurre operazioni offensive negando plausibilmente il coinvolgimento statale, mentre online si costruisce consenso e narrativa a supporto della causa filo-palestinese.

A marzo 2026 il Dipartimento di Giustizia USA ha reso pubblica un’incriminazione che collega individui operanti sotto l’ombrello Handala al MOIS, inquadrando le loro attività in un più ampio programma di “operazioni psicologiche cyber-abilitate” — disinformazione, intimidazione e raccolta di intelligence combinate nello stesso apparato. Lo stesso ecosistema di attori legati a Teheran è stato osservato a marzo colpire con un wiper l’azienda Stryker e violare la casella di posta personale del direttore dell’FBI, segno di un’operatività che spazia dal sabotaggio industriale allo spionaggio mirato su singole persone.

Come funziona l’avvicinamento

La campagna descritta da Shin Bet non punta a exploit zero-day, ma a ingegneria sociale paziente e su misura, costruita specificamente attorno al mestiere del giornalista. Gli operatori contattano il bersaglio fingendosi conoscenti, colleghi o addirittura firme note — tra i nomi usati come esca, secondo le ricostruzioni giornalistiche, anche quello del noto reporter Barak Ravid — con proposte di collaborazione, richieste di intervista o l’offerta di materiale esclusivo su sviluppi politici e militari, l’esca perfetta per chi vive di scoop.

Da lì si dipartono tre vettori distinti, spesso combinati nella stessa conversazione:

• Link a pagine di login contraffatte che imitano Google, per catturare credenziali dell’account principale e, con esso, l’accesso a mail, contatti e cronologia dei documenti condivisi;
• Link a Google Drive falsificati che rimandano a documenti “esclusivi” ma in realtà instradano verso pagine di raccolta credenziali identiche a quelle originali;
• File malevoli inviati come allegati — presunti dossier, registrazioni o documenti di interesse — che una volta aperti concedono accesso completo al dispositivo mobile, inclusi messaggistica, microfono e geolocalizzazione.

L’obiettivo dichiarato dalle autorità israeliane non è solo la singola casella di posta: è la ricostruzione della rete di fonti del giornalista, l’accesso a materiali di lavoro non ancora pubblicati e, in prospettiva, la possibilità di alimentare operazioni di influenza usando conversazioni sottratte, come già avvenuto in altri episodi in cui gruppi legati a Teheran hanno pubblicato messaggi privati rubati per screditare bersagli israeliani.

Perché conta per chi si occupa di difesa

Il caso Handala è un promemoria scomodo per chi lavora in redazioni, ONG e uffici stampa che trattano materiale sensibile su Medio Oriente: l’anello debole non è quasi mai l’infrastruttura tecnica, ma la fiducia interpersonale che il mestiere stesso richiede di concedere a sconosciuti. Un attaccante di livello statale che parla la lingua del settore — propone uno scoop, cita eventi reali, imita lo stile di un collega — supera in un colpo solo gran parte delle difese tecniche standard, perché la vittima interagisce volontariamente con il contenuto malevolo.

Per i team di sicurezza che proteggono realtà editoriali o organizzazioni esposte, le raccomandazioni diffuse da Shin Bet restano il primo presidio praticabile:

• Verificare l’identità di chi propone collaborazioni o interviste tramite un canale separato da quello di primo contatto, prima di aprire qualunque link o allegato;
• Non inserire mai credenziali dopo aver seguito un link ricevuto in chat, per quanto il mittente sembri legittimo — meglio digitare manualmente l’indirizzo del servizio;
• Attivare l’autenticazione a due fattori tramite app authenticator (non SMS) su tutti gli account di posta e cloud storage;
• Impostare indirizzi di recupero account separati e monitorati;
• Segmentare i dispositivi usati per il lavoro giornalistico da quelli personali, quando possibile, e mantenere aggiornati i sistemi operativi mobili.

Handala dimostra ancora una volta come i confini tra hacktivismo, spionaggio statale e guerra dell’informazione si siano ormai dissolti: lo stesso gruppo che rivendica breach “per la causa” su Telegram può, il giorno dopo, star raccogliendo materiale per un dossier destinato ai servizi. Per i difensori, l’unica postura sensata è trattare ogni contatto non sollecitato — anche il più credibile — come potenzialmente ostile.

Indicatori e riferimenti

Attore: Handala (Handala Hack Team) — collegato al MOIS iraniano
Vettori: WhatsApp, Telegram
TTP: impersonificazione di giornalisti/contatti noti, phishing credenziali Google,
     Google Drive link contraffatti, allegati malevoli per compromissione mobile
Target: giornalisti e figure pubbliche israeliane (es. redazioni come Haaretz)
Incriminazione USA: marzo 2026 (Dipartimento di Giustizia, MOIS)
Allerta ufficiale: Shin Bet + National Cyber Directorate, 16 agosto 2026
Canale di segnalazione IL: hotline 119 (National Cyber Directorate)

Spcnet.it

2026-08-18 13:29:09

Il filesystem /proc su Linux: la guida completa per il troubleshooting da sistemista

Ogni sistemista Linux, prima o poi, si trova davanti a una domanda che top o free non riescono a risolvere del tutto: perché questo processo consuma tanta memoria? Perché una porta risulta occupata ma netstat non mostra nulla? Perché un servizio continua a scrivere su un file che, in teoria, è stato cancellato? La risposta, quasi sempre, si trova in un posto che molti amministratori conoscono solo superficialmente: /proc.

/proc non è una directory come le altre. È un filesystem virtuale, di tipo procfs, generato e mantenuto interamente dal kernel in memoria: non un singolo byte dei suoi contenuti risiede su disco. È, di fatto, una finestra live sullo stato interno del kernel, esposta attraverso strumenti che ogni sistemista già conosce: cat, grep, awk. Comandi come free, ps, top e iostat non fanno altro che leggere e formattare i dati che /proc mette a disposizione: imparare a leggerlo direttamente significa avere accesso alle stesse informazioni, ma senza filtri, e con la possibilità di combinarle in modi che nessun tool preconfezionato offre.

La struttura: due mondi in una directory

/proc contiene sostanzialmente due categorie di contenuti. Da un lato le directory numerate, una per ogni processo in esecuzione (/proc/1234/, dove 1234 è il PID), che espongono lo stato specifico di quel processo. Dall’altro i file di sistema globali, come /proc/meminfo o /proc/cpuinfo, che riflettono lo stato del kernel nel suo complesso, indipendentemente da quale processo li legga.

I file di sistema che contano davvero

/proc/cpuinfo e /proc/stat

/proc/cpuinfo elenca i core logici della CPU con modello, velocità di clock, dimensione della cache e i flag di supporto per estensioni come vmx (virtualizzazione hardware), aes e avx2. Un one-liner molto usato per contare le CPU logiche disponibili è:

grep -c '^processor' /proc/cpuinfo

/proc/stat, invece, espone i contatori di tempo CPU aggregati e per singolo core, suddivisi in colonne: user, nice, system, idle, iowait, irq, softirq. Su un server sotto carico I/O-intensivo, tenere d’occhio la colonna iowait nel tempo è spesso più diagnostico di qualunque dashboard grafica, perché permette di isolare il momento esatto in cui la CPU comincia ad attendere lo storage invece di lavorare.

/proc/meminfo: oltre a “free”

/proc/meminfo è la fonte dati grezza dietro al comando free, ma contiene molti più campi di quelli che free mostra normalmente. Due meritano attenzione particolare: MemAvailable, che indica la memoria realmente disponibile per nuovi processi tenendo conto della cache riclamabile (a differenza di MemFree, che è quasi sempre un numero fuorviante), e Dirty, che riporta quanta memoria contiene dati modificati ancora in attesa di essere scritti su disco — un valore che cresce pericolosamente su sistemi con storage lento e scritture intense.

Per un monitoraggio in tempo reale della pressione di memoria, questo comando è estremamente utile in fase di troubleshooting:

watch -n1 'grep -E "MemAvailable|Dirty|Writeback|SwapFree" /proc/meminfo'

/proc/diskstats, /proc/loadavg, /proc/net/

/proc/diskstats fornisce le statistiche I/O per dispositivo — letture, scritture, settori trasferiti, tempo speso in operazioni — ed è la fonte dietro iostat. /proc/loadavg espone le tre celebri medie di carico a 1, 5 e 15 minuti, mentre /proc/uptime riporta i secondi trascorsi dal boot e il tempo cumulativo di inattività della CPU.

La sottodirectory /proc/net/ merita un capitolo a sé: /proc/net/dev contiene i contatori di byte e pacchetti per ogni interfaccia di rete, /proc/net/tcp e tcp6 elencano tutte le connessioni TCP attive in formato esadecimale, /proc/net/sockstat riassume l’utilizzo dei socket a livello di sistema, e /proc/net/snmp espone contatori SNMP utili per individuare retransmit e fallimenti di connessione anomali.

Il mondo per-processo: /proc/PID/

Qui si trova la parte più preziosa per il debugging quotidiano. Alcuni file chiave:

• /proc/PID/cmdline — il comando esatto con cui il processo è stato lanciato, con gli argomenti delimitati da byte null.
• /proc/PID/status — un riepilogo leggibile con UID, GID, utilizzo di memoria e numero di thread. Il campo VmRSS indica la memoria residente effettivamente occupata, mentre VmSwap segnala se (e quanto) il processo è finito in swap.
• /proc/PID/fd/ — una directory di symlink, uno per ogni file descriptor aperto dal processo. È la base dati su cui si appoggia lsof. Contare i descrittori aperti è semplice: ls /proc/12345/fd | wc -l.
• /proc/PID/io — la contabilità I/O del processo, con read_bytes e write_bytes che riflettono i dati effettivamente passati al layer di storage.
• /proc/PID/maps e /proc/PID/smaps — le regioni di memoria mappate dal processo (codice, stack, heap, librerie condivise). smaps va oltre e fornisce, per ogni regione, i dettagli su RSS, PSS e swap.
• /proc/PID/environ — le variabili d’ambiente al momento del lancio, anch’esse delimitate da byte null.
• /proc/PID/cwd e /proc/PID/exe — symlink rispettivamente alla directory di lavoro corrente e all’eseguibile su disco. Sono fondamentali per identificare binari che sono stati cancellati o sostituiti mentre il processo era ancora in esecuzione (un classico segnale da cercare dopo un aggiornamento di sicurezza mal gestito).
• /proc/PID/oom_score e oom_score_adj — il punteggio che l’OOM killer del kernel usa per decidere quale processo terminare per primo in caso di esaurimento memoria. oom_score_adj, con un range da -1000 a 1000, permette di proteggere o “sacrificare” volontariamente un processo specifico.

Due scorciatoie tornano utili spesso: /proc/self/ punta sempre al processo che sta effettuando la lettura, mentre /proc/$$/ punta alla shell corrente all’interno di uno script.

Casi pratici di troubleshooting

Trovare quale processo ha in ascolto una determinata porta (qui la porta 443/0x01BB su IPv6), senza usare ss o lsof:

inode=$(awk '$2 ~ /:01BB$/ {print $10; exit}' /proc/net/tcp6)
ls -l /proc/*/fd/ 2>/dev/null | grep "socket:[$inode]"

Individuare processi che tengono aperti file già cancellati — una causa classica di dischi che risultano pieni pur senza file visibili, perché lo spazio non viene liberato finché il file descriptor resta aperto:

find /proc/*/fd -ls 2>/dev/null | grep '(deleted)'

Ispezionare i contatori di interrupt per CPU, utile per diagnosticare squilibri di IRQ affinity su macchine multi-core:

cat /proc/interrupts | head -20

/proc/sys e il tuning via sysctl

Sotto /proc/sys/ si trovano i file scrivibili che espongono i tunable del kernel — la stessa interfaccia usata da sysctl. Ad esempio, per modificare a caldo la propensione del kernel allo swap:

echo 10 | sudo tee /proc/sys/vm/swappiness

Tra i tunable più comuni: vm.swappiness (0-200, propensione allo swap), net.ipv4.ip_forward (abilitazione dell’IP forwarding), net.core.somaxconn (backlog massimo per i socket in ascolto) e fs.file-max (limite di file descriptor a livello di sistema). Ricordiamo che le modifiche fatte così sono volatili: per renderle permanenti serve intervenire su /etc/sysctl.conf o su un file in /etc/sysctl.d/.

/proc dentro i container

Un punto che genera spesso confusione: /proc è namespace-aware. Dentro un container Docker, la directory mostra il namespace PID del container, non quello dell’host — il PID 1 visto dall’interno è l’entrypoint del container, non l’init dell’host. Attenzione però: campi come quelli di /proc/meminfo o /proc/stat spesso riflettono ancora i totali dell’host e non i limiti imposti dai cgroup al container, un dettaglio che ha tratto in inganno più di un tool di monitoring scritto ingenuamente.

/proc contro /sys: quando usare cosa

/sys (sysfs) è il filesystem virtuale complementare a /proc, ma orientato al modello dei dispositivi del kernel: driver, bus, block device, gestione dell’energia. Un esempio tipico è /sys/devices/system/cpu/cpu0/cpufreq/, che espone i parametri di scaling della frequenza per singolo core. La regola pratica: /proc per processi e stato del kernel a livello di sistema, /sys per configurazione e stato dei dispositivi hardware.

Conclusione

Conoscere /proc non è un esercizio accademico: è uno degli strumenti diagnostici più potenti a disposizione di un sistemista Linux, proprio perché sta sotto ogni tool di monitoring che si finisce per usare quotidianamente. Quando top, free o netstat non bastano — o semplicemente non sono installati sulla macchina compromessa o minimale su cui ci si trova a lavorare — sapere leggere direttamente /proc/meminfo, /proc/PID/status o /proc/net/tcp fa la differenza tra un troubleshooting rapido e ore perse a indovinare. Vale la pena tenere a portata di mano, come riferimento minimo, i file /proc/meminfo, /proc/cpuinfo, /proc/stat, /proc/net/dev e la struttura di /proc/PID/: coprono la stragrande maggioranza dei casi reali di debugging su sistemi in produzione.

Fonte originale: A Guide to Linux /proc Filesystem, LinuxBlog.io

A Guide to Linux /proc Filesystem | LinuxBlog.io

The /proc filesystem is a live window into the Linux kernel: process state, memory layout, CPU counters, network stats, and writable kernel tunables, all accessible with nothing but cat and grep.

^{Hayden James (LinuxBlog.io)}