GRR Rapid Response: la forensics remota "live" di Google, open source

Quando un computer di un'organizzazione viene compromesso, una delle prime domande è cosa sta succedendo su quella macchina, adesso? Se il parco macchine è di decine, centinaia o migliaia di dispositivi, andare a guardare fisicamente ogni computer non è praticabile. GRR Rapid Response nasce per questo.

GRR è un framework di incident response focalizzato sulla live forensics da remoto. È composto da un agente (client) scritto in Python, da installare sulle macchine da monitorare, e da un'infrastruttura server, anch'essa in Python, che gestisce i client e comunica con loro. Il progetto è nato in Google ed è rilasciato con licenza Apache 2.0. Sul repository ufficiale ha circa 5.100 stelle, e l'ultima release, la 4.0.0.0, è di dicembre 2025. Il codice è per circa il 71% Python e per il 24% TypeScript, quest'ultimo per la nuova interfaccia web.

GRR permette a chi gestisce la sicurezza di interrogare da un'unica console le macchine di una flotta, senza muoversi dalla scrivania. Gli usi tipici sono questi:

• Raccolta di evidenze: scaricare file, cercare nel filesystem e, su Windows, nel registro di sistema.
• Analisi live: elencare processi, connessioni di rete e servizi in esecuzione, e in generale osservare lo stato del sistema mentre è acceso, dove un'analisi su disco "spento" perderebbe informazioni volatili.
• Hunting: lanciare la stessa ricerca su molte macchine insieme, ad esempio "quali client hanno questo file o questa chiave di registro?". Serve a capire quanto si è esteso un incidente.
• Triage rapido: decidere in pochi minuti se una macchina va isolata e analizzata a fondo.

Supporta client Linux, macOS e Windows.

Come funziona

Il client. Sulla macchina gira un agente composto da due processi. Uno è il client Fleetspeak, che gestisce la comunicazione con il server su una connessione HTTPS in streaming. L'altro è il client GRR vero e proprio, che scambia messaggi con il server ed esegue le operazioni richieste. Il client è un'applicazione leggera che resta in attesa di istruzioni. Non c'è un "motore" che analizza tutto in autonomia e poi invia report.

Il server. È modulare. I componenti principali sono:

• i frontend, che ricevono i messaggi dai client attraverso il server Fleetspeak, li mettono in coda nel datastore e recapitano ai client i messaggi in attesa;
• i worker, che elaborano il lavoro in coda;
• l'Admin UI, l'interfaccia web, con API REST, da cui l'analista opera;
• il datastore, per impostazione predefinita MySQL.

Nelle installazioni piccole ogni componente gira come processo separato sulla stessa macchina. Per ambienti più grandi i componenti possono stare su macchine diverse. github

Il flusso di lavoro. Dall'interfaccia si cerca un client, si sceglie un'operazione (nel vocabolario di GRR un flow, per esempio "raccogli questi file") e la si accoda. Alla prossima connessione il client la esegue e i risultati tornano sul server, dove l'analista li consulta o li scarica. Un hunt è lo stesso meccanismo applicato a molte macchine insieme. Per chi preferisce automatizzare, esiste anche un client API Python, utilizzabile dai notebook Colab.

Come si installa

Il metodo consigliato oggi è Docker Compose. Servono Docker (la documentazione indica la versione 19.03 come minimo e la 20.10 come ben testata), Docker Compose e Git.

git clone https://github.com/google/grr

cd grr

 # genera chiavi e certificati (solo al primo avvio)

./docker_config_files/init_certs.sh

 # avvia lo stack

docker compose up -d

Quando tutti i servizi sono attivi, l'interfaccia web risponde su 127.0.0.1:8000. Lo stack include anche un client di prova già collegato. Cercando . nel campo di ricerca compare una macchina online, e da lì si possono provare i primi flow. Per fermare tutto si usa docker compose down, e docker compose down --volumes cancella anche i dati persistiti.

Due avvertenze pratiche:

1. Quello di Compose è un ambiente di prova. In produzione si usa di solito un database MySQL esterno, con parametri adatti. La documentazione ufficiale segnala per esempio che max_allowed_packet non deve scendere sotto circa 20 MB, altrimenti GRR ha problemi a scrivere dati voluminosi.
2. I client vanno distribuiti sulle macchine reali. I template dei client vengono "riconfezionati" (repacked) con la configurazione del tuo server e diventano installer da distribuire con i normali strumenti di gestione del software (apt, GPO, MDM e simili).

Per approfondire ci sono la documentazione ufficiale su grr-doc.readthedocs.io, le issue del progetto su GitHub e la mailing list grr-users.

GRR è uno strumento potentissimo, e questo è anche il suo punto delicato. Un agente che può leggere file, registro e memoria di una macchina da remoto è, per definizione, un accesso privilegiato molto ampio. Per questo sono essenziali:

• governance chiara: chi può usarlo, su quali macchine, per quali finalità e con quale tracciamento;
• informativa e base giuridica, soprattutto quando le macchine sono di dipendenti o di utenti e non solo dell'organizzazione;
• protezione dell'infrastruttura GRR stessa, perché chi la compromette ottiene un controllo su tutta la flotta.

Per chi vuole evitare soluzioni commerciali e opache, GRR resta una delle poche alternative aperte e verificabili per l'incident response su larga scala. Il prezzo è la complessità di installazione e gestione.