Analiza alata Google Rapid Response (GRR)

GRR, Google Rapid Response ili GRR Rapid Response je alat za udaljeno motrenje, forenziku i reagiranje na incidente. Alat se sastoji od dvije komponente: poslužitelja i klijenata. Jedan poslužitelj postavlja se kao upravljač za neku skupinu klijenata. Klijenti poslužitelju omogućuju administratorski pristup svojim resursima (datotečni sustavi, memorija, mrežna sučelja, …). Namijenjen je za primjenu u poslovnom okruženju gdje postoji tijelo zaduženo za sigurnost i reakcije na incidente. Alat je skalabilan i podržava do sto tisuća klijenata po poslužitelju. Forenzičke aktivnosti na udaljenim računalima omogućuje primjena postojećih alata poput YARA-e, TSK i Volatility Framework-a. GRR je objavljen pod Apache licencom (inačica 2.0).

Ključne riječi: reagiranje na incidente, motrenje, udaljena forenzika

U poslovnom okruženju brza reakcija na incidente i otkrivanje kompromitiranih dijelova računalne infrastrukture je od ključne važnosti. Klasičan način prikupljanja podataka u forenzičke svrhe zahtjeva isključivanje sumnjivog računala i kopiranja sadržaja diska. Takav pristup je nepoželjan iz nekoliko razloga. Možda je računalo fizički nedostupno, možda je to računalo odgovorno za kritične servise na računalnoj mreži i isključivanje bi značilo velik novčani gubitak. Kopiranje diska može potrajati a moguće je da to računalo nije jedino koje je potrebno provjeriti. Pojavljuje se potreba za alatom koji će agentima odgovorim za reakciju na incidente omogućiti efikasno prikupljanje informacija i djelovanje na veći dio računalne mreže. Takav alat ima administratorski pristup računalima koja se koriste u poslovnom okruženju i omogućuje prikupljanje forenzičkih informacija bez potrebe za zaustavljanjem rada računala koje se promatra i bez potrebe za fizičkim pristupom.

GRR je alat otvorenog koda namijenjen za motrenje, računalnu forenziku i upravljanje incidentima. Osmišljen je za primjenu na velikim računalnim sustavima u poslovnim okruženjima. Alat se sastoji od jednog poslužitelja i skupa klijenata kojima on upravlja. Velika prednost GRR u odnosu na konkurenciju je činjenica da je besplatan i podržava OSX, Linux i Windows platforme (konkurencija pretežito vezana za Windows). Nudi mogućnost rada s velikim brojem računala, podjelu rada, mehanizam za efikasno prikupljanje i arhiviranje informacija, itd. U dokumentu će biti prikazana pojednostavljena struktura GRR poslužitelja i klijenata, način komunikacije i prikupljanja informacija te djelovanje na klijente.

Dvije vršne komponente GRR radnog okvira su GRR poslužitelj i GRR klijent. Oboje su implementirani u programskom jeziku Python. Jedan poslužitelj odgovoran je za skup klijenata koji su se na njega registrirali. On djeluje kao centralna točka upravljanja. Svaki klijent periodički se javlja poslužitelju koji je za njega odgovoran i od njega preuzima zadatke. Po izvršenju zadataka rezultate dojavljuje poslužitelju. Rezultati zadataka su u većini slučajeva kopije ili popisi datoteka koji se skupljaju na poslužitelju radi forenzičke analize. Klijent instaliran na računalo ima administratorski pristup resursima tog računala, tj. direktan pristup primarnoj i sekundarnoj memoriji (RAM i disk), povezanim uređajima, itd. Kako bi se smanjilo opterećenje poslužitelja klijenti sadrže alate poput Volatility Framework-a i TSK-a kako bi pomoću njih izvršili analizu i poslužitelju poslali samo rezultate. GRR poslužitelj osim sustava za podjelu zadataka implementira grafičko sučelje. Grafičko sučelje namijenjeno je forenzičarima i omogućuje dodjeljivanje zadataka klijentima, pregled završenih analiza, itd.

Kako bi se poboljšala skalabilnost i olakšalo održavanje sustava GRR poslužitelj podijeljen je u nekoliko komponenti. Svaka komponenta poslužitelja ima jasan zadatak i moguće ih je dodavati i uklanjati iz sustava kako bi se podržao različit broj klijenata. Centralna komponenta poslužitelja je baza podataka. Osim što sadrži prikupljene datoteke, tragove i rezultate analiza ona se koristi kao komunikacijski kanal za ostale komponente poslužitelja. Trenutno GRR podržava rad samo s MySQL DMS-om (Database Management System). U bazi podataka nalaze se redovi poruka. Komponente poslužitelja koriste te redove za komunikaciju. Frontend poslužitelj (Frontend server) je komponenta koja je zadužena za komunikaciju s klijentima. Zadaća frontend poslužitelja je dešifriranje poruka koje klijent šalje, postaviti te poruke u pripadni red poruka u bazi podataka. Ako postoje poruke koje nisu poslane klijentu frontend poslužitelj će ih preuzeti iz baze podataka i proslijediti klijentu. Budući da je sustav namijenjen za rad s velikim brojem klijenata frontend poslužitelji ne smiju obavljati kompliciranije zadatke.

Komponenta poslužitelja zadužena za obradu podataka i slične poslove je radnik (Worker). Komponente radnici zaduženi su za provjeru redova poruka koje je klijent poslalo. Ovisno o sadržaju tih poruka dodaju nove koje će se poslati klijentu ili započinju obradu podataka. Posljednja komponenta poslužitelja je WebUI. Ona implementira mrežno grafičko sučelje za upravljanje sustavom i pokretanje raznih aktivnosti. Osim grafičkog sučelja nudi i API radi lakše automatizacije i integracije s ostalim dijelovima sustava.

Slika prikazuje moguću instalaciju GRR poslužitelja. Dokumentacija savjetuje dodavanje sustava za uravnoteživanje prometa između frontend poslužitelja i klijenata. Broj komponenata radnika, frontend poslužitelja ili WebUI (GUI console na slici) možemo manipulirati za vrijeme rada ovisno o broju klijenata, opterećenju mreže, broju korisnika mrežnog sučelja (grafičkog ili API), itd. Da bi klijenti mogli prikupljati forenzičke tragove s računala na kojima su instalirani moraju imati administratorski pristup svim resursima. Posljedice takve implementacije su da bilo tko s pristupom grafičkom sučelju ili pravom pisanja u bazu podataka ima administratorski pristup svim računalima s instaliranim klijentima. Neki od koraka za smanjenje rizika su: potpuno onesposobiti ili strogo kontrolirati pristup komponentama poslužitelja (ssh, fizički, …) i nikako dozvoliti pristup WebUI poslužitelju s Interneta. Sposobnost GRR poslužitelja da pretražuje datotečne sustave klijenata dovodi u pitanje privatnost korisnika računala na kojima su klijeti instalirani. GRR rješava taj problem implementacijom sustava odobrenja. Kako bi forenzičari koji rade na poslužitelju mogli pokretati akcije na klijentima pregledavati datoteke ili rezultate analiza moraju dobiti odobrenje od kolega ili nadređenog osoblja. Tako se osigurava da barem dvoje ljudi zna da se odvija neko prikupljanje forenzičkih tragova.

GRR klijent je program instaliran na računalu koje želimo motriti. Klijent je dužan kontaktirati GRR poslužitelja, preuzeti zadatke, izvršiti ih i poslužitelju odgovoriti s rezultatima. Zadatke koje poslužitelj daje klijentu nazivamo akcijama (ClientAction). Te akcije su jednostavne funkcije implementirane u klijentu, npr. prenesi(datoteka, pomak, duljina). Naj jednostavnija i najčešća akcija koju klijent dobiva je čitanje datoteka i direktorija. Kako bi klijent mogao obaviti zadane akcije na svim resursima računala mora se izvršavati s administratorskim privilegijama (root korisnik). Kako bi osigurali stalan rad klijenta te da neće zapeti u izvođenju na računano se uz klijenta instalira i program čuvar (nanny, watchdog) koji je zadužen za motrenje rada klijenta. Ako klijent zapne u izvođenju čuvar će ga prekinuti i ponovno pokrenuti (samo na Windows platformi).

Trenutno postoje implementacije GRR klijenata za slijedeće platforme: Microsoft Windows, OSX i Linux. Na Linux i OSX platformama klijent je implementiran kao servis u vlasništvu korijenskog (root) korisnika. Proces klijenta može prestati s radom iz mnogo razloga, dužnost ponovnog pokretanja na tim platformama pada na sustav za upravljanje servisima (poput systemd). Osim klijentskog programa i promatrača za te dvije platforme implementiraju se i moduli jezgre koji dozvoljavaju potpuni pristup primarnoj memoriji računala i međuspremnicima datotečnih sustava.

Kako bi se osigurao minimalan utjecaj klijenta na rad računala i na rezultate akcija koje klijent izvodi implementiraju se određena ograničenja. Prvo je memorijsko ograničenje. Klijent definira dvije granice na korištenje memorije, meku i čvrstu granicu. Meku granicu osigurava sam klijent, ako se ona prekorači klijent će završiti sve akcije koje je započeo i potom izaći iz glavne petlje. Čvrstu memorijsku granicu održava proces čuvar. U slučaju da klijent zauzme više memorije nego što mu je dozvoljeno proces čuvar će ga zaustaviti. Ograničenje na korištenje procesora osigurava proces čuvar. Poslužitelj će sa zadatcima klijentu poslati i vremensko ograničenje za svaki zadatak. Ako klijent ne završi akciju u danom vremenu promatrač će ga zaustaviti.

Ponašanje klijenta određujemo s nekoliko parametara. Parametar error_poll_min određuje vrijeme između pokušaja komunikacije ako je došlo do pogreške, poll_max i poll_min određuju koliko često će se kontaktirati poslužitelj u brzom i sporom načinu rada. Klijent će poslužitelja prokušati kontaktirati pomoću URL-a definiranih u listama server_urls i proxy_urls. Nakon pokretanja klijent će proći kroz sve kombinacije URL-a u te dvije liste i pokušati kontaktirati poslužitelja (sve kombinacije od jednom). Ako niti jedna kombinacija ne vrati odgovor klijent će nastaviti isprobavati kombinacije ali po jednu svakih poll_max sekundi. Kada dobije dogovor s jedne od kombinacija klijent će preuzeti zadatke od poslužitelja. Koliko dugo će mu trebati da ponovo pokuša kontaktirati poslužitelja ovisi o uputama koje je od njega dobio, ako nije bilo zadataka za izvršiti kontaktirat će ga tek za poll_max sekundi. Ako je klijent dobio odgovor od poslužitelja koji označava grešku u poslužitelju (HTTP kod 5xx) predpostavit će da se radi o privremenoj grešci i pokušat će ponovo uspostaviti vezu svakih error_poll_min sekundi. Parametar connection_error_limit određuje dozvoljen broj uzastopnih neuspješnih pokušaja komunikacije. Ako se taj broj prekorači klijent će prestati s radom. Očekujemo da će ga program čuvar ili sustav za upravljanje servisima ponovno pokrenuti.

Poslužitelj i klijenti komuniciraju razmjenom poruka. Poruke se prenose HTTP protokolom. Razmjenu poruka uvijek započinje klijent i uvijek koristi samo HTTP POST metodu. Poruke koje poslužitelj šalje klijentu nazivamo zahtjevima. Poruke klijenta poslužitelju nazivamo odgovorima. U jednoj HTTP razmjeni klijent može poslati više odgovora a poslužitelj više zahtjeva. Jedan zahtjev može uzrokovati više odgovora npr. zahtjev akcije elementiDirektorija(ime). Sva komunikacija klijenta i poslužitelja osigurana je AES128 enkripcijom za koju se kao ključ koristi nasumični identifikator sesije. Osim ključa koriste se inicijalizacijski vektor. Prijenos identifikatora sesije osigurava se RSA javnim ključem primatelja. Sve poruke poslane u jednoj razmjeni potpisane su privatnim ključem pošiljatelja.

Certifikat se poslužitelju dodjeljuje prilikom instalacije. Javni ključ poslužitelja dodaje se u konfiguracijske datoteke klijenata prije instalacije kako bi im se omogućilo da komuniciraju s poslužiteljem. GRR implementira mehanizme za brzu promjenu poslužiteljskog certifikata ako je to ikada potrebno. Nakon instalacije klijenti neće imati vlastiti certifikat. Pri prvom pokretanju klijent će uočiti da nema certifikat te će si stvoriti javni i privatni ključ i početi proces registracije na poslužitelja. Klijent će poslužitelju poslati zahtjev za registracijom certifikata šifrirani javnim ključem poslužitelja. Poslužitelj će potpisati taj zahtjev i klijentu će vratiti certifikat koji će se koristiti za daljnju komunikaciju. Kopiju certifikata poslužitelj sprema u bazu podataka. Ako ikada želimo ukloniti klijenta njegov certifikat brišemo iz baze podataka. Jedinstveno ime klijenta pod kojim se certifikat registrira je sažetak javnog ključa klijenta.

GRR klijenti moraju imati što manji utjecaj na rad računala na kojem su instalirani. Zato su akcije koje implementiraju iznimno jednostavne. Poslužitelj kombinira te jednostavne akcije klijenta u tokove (Flow). Tok je smisleni niz akcija koje se zahtjevima (porukama) zadaju klijentu i čiji se rezultati izvođenja prikupljaju. Tok će ovisno o rezultatima akcija davati nove zadatke, pokretati analize, itd. Akcije od kojih se tok sastoji klijentu se zadaju asinkrono. Kod klasične komunikacije poslužitelja i klijenta poslužitelj će zauzeti i držati resurse (datoteke, radna memorija, socket-i, …) operacijskog sustava za vrijeme komunikacije. Iako je većina akcija koje klijenti izvode jednostavna i odgovor se može očekivati vrlo brzo ne postoji garancija da će doći. Klijent može u bilo kojem trenutku biti prekinut (gašenje računala, proces čuvar, pucanje veze, …) ili sama akcija može potrajati ako je računalo opterećeno. To začni da će se resursi na poslužitelju zadržati dulje nego što je potrebno i ograničiti broj klijenata tog poslužitelja.

Tokovi su implementirani kao konačni automati stanja. Promjenu stanja toka uzrokuju odgovori klijenta na zahtjeve tog toka. Implementirani su u programskom jeziku Python tako da dozvoljavaju serijalizaciju stanja, tj. sve informacije potrebne za izvođenje toka (i sam tok) mogu se spremiti u bazu podataka. Takva implementacija omogućuje oslobađanje resursa poslužitelja dok tok čeka na rezultate zahtjeva. Za serijalizaciju toka i potrebnih podataka koristi se standardna biblioteka Pickle.

Izvođenje toka koji preuzima datoteku s klijenta prikazano je na slici. Tok se dodaje u sustav kroz mrežno grafičko sučelje ili API. Komponenta poslužitelja radnik (worker) inicijalizirat će tok i početi s izvođenjem. Prvi zahtjev toka je da klijent izračuna sažetak datoteke. Taj zahtjev postavlja se u izlazni red poruka klijenta u bazi podataka. Budući da je to prvi zahtjev u izlaznom redu poruka klijenta nema odgovora i tok mora čekati. Komponenta radnik na kojoj se tok izvodi serijalizirati će tok i njegove podatke, rezultat će spremiti u bazu podataka. Sljedeći put kada klijent kontaktira frontend poslužitelja on će provjeriti ima li zahtjeva u izlaznom redu poruka koji pripada tom klijentu. Frontend poslužitelj će klijentu poslati zahtjev (ne briše se iz baze). HTTP transakcija je gotova i klijent izvršava zadanu akciju. Traženi sažetak datoteke se postavlja u izlazni red poruka na tom klijentu. Kada sljedeći put klijent kontaktira poslužitelja poslat će mu sažetak datoteke. Frontend poslužitelj će postaviti odgovore u ulazni red poruka u bazi podataka, kako nema zahtjeva u izlaznom redu klijent neće dobiti nove zadatke. Zahtjev na koji se dobiveni odgovor odnosi tek se sada uklanja iz izlaznog reda poruka. Postavljanjem nove poruke u ulazni red klijenta tok za koji je taj odgovor namijenjen se označava kao spreman za izvršavanje. Kada tok dođe na red neki od radnika će ga preuzeti iz baze, deserijalizirati i početi izvršavati. Prvi korak će biti čitanje sažetka datoteke iz ulaznog reda poruka. Ako je taj sažetak isti onome kojeg već imamo u bazi podataka (ako postoji) to začni da se datoteka nije promijenila i ne treba je kopirati, tok će priječi u stanje TERMINATED i završiti s radom. Ako je datoteka različita od kopije u bazi podataka ili ne postoji u bazi tok će u izlazni red poruka postaviti niz zahtjeva za prijenosom dijelova datoteke npr. kopiraj(ime, pomak, duljina).

Sljedeći put kada klijent kontaktira poslužitelja frontend komponenta će mu proslijediti zahtjeve iz njegovog izlaznog reda u bazi podataka. Svaki put kada se klijent javi s odgovorom (djelom datoteke) frontend komponenta će ukloniti pripadni zahtjev iz izlaznog reda i dodati odgovor u ulazni red. Nakon svakog novog rezultata tok će se označiti kao spreman za izvršavanje. Ako klijent nije poslao sve odgovore a tok se počne ponovo izvoditi na nekoj radnoj komponenti jednostavno će se ponovo serijalizirati i vratiti u bazu. Tek kada se u ulazni red klijenta postavi posljednji odgovor tok može nastaviti s izvođenjem. Komponenta radnik će preuzeti tok iz baze podataka, deserijalizirati ga i izvesti ga. Tok će provjeriti jesu li prisutni svi odgovori i počet će računati sažetak datoteke. Zatim će provjeriti razlikuje li se sažetak u odnosu na sažetak dobiven od klijenta. Ako se sažeci razlikuju tok će preči u stanje ERROR s opisom greške da je datoteka promijenjena za vrijeme izvođenja toka. Ako je datoteka uspješno preuzeta s klijenta usporedit će se dio po dio s kopijom iz baze podataka i spremit će se samo oni blokovi koji se razlikuju od lokalne kopije.

Dokumentacija savjetuje instalaciju posljednje inačice GRR poslužitelja (3.4.0) na Ubuntu distribuciju GNU/Linux operacijskog sustava (izdanje Xenial 16.04). U vrijeme pisanja članka (28.12.2019.) instalaciju nije moguće izvesti zbog zabrane pristupa python3.6 PPA arhivu. Kako bi zaobišli problem testiranje ćemo provesti na starijoj inačici GRR-a (3.2.6) koja je implementirana za stariju inačicu (2.7) Python interpretera. Testno okruženje sastojat će se od jednog GRR poslužitelja i jednog klijenta. Sve komponente poslužitelja i klijent bit će instalirani na jednom virtualnom računalu. Za pokretanje virtualnog računala koristimo Oracle VirtualBox. Za operacijski sustav virtualnog računala odabran je operacijski sustav Ubuntu Xenial(18.04). Upute za instalaciju preuzete su s ovog bloga.

Nakon što ste pokrenuli virtualno računalo otvorite terminal i pokrenite sljedeće naredbe. Posljednja naredba u bloku će pokrenuti instalaciju MySQL DMS-a. Instalacija će postaviti nekoliko pitanja o konfiguraciji. Postavite lozinku za administratora baze podataka i odgovorite sa: N, Y, Y, Y, Y.

sudo -i
apt-get update -y
apt-get upgrade -y
apt-get install mariadb-server -y
mysql_secure_installation

Pokrenite MySQL konzolu i stvorite novu bazu podataka za GRR poslužitelja. Između 'grr' i 'localhost' nalazi se simbol @ bez razmaka. DokuWiki ne dozvoljava niz “quote@quote”. Ako želite možete promjeniti lozinku ('password') za korisnika 'grr'.

mysql -u root -p

CREATE DATABASE grr;
GRANT ALL PRIVILEGES ON grr.* TO 'grr'@ 'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
SET GLOBAL max_allowed_packet=41943040;
FLUSH PRIVILEGES;
EXIT;

Ponovno pokrenite servis baze podataka kako bi ažurirali postavke. Provjerite odgovara li izlaz druge naredbe slici, tj. je li servis mariadb aktivan nakon ponovnog pokretanja.

systemctl restart mariadb
systemctl status mariadb

Sljedeće naredbe preuzet će i instalirati paket GRR poslužitelja. Paket sadrži sve komponente poslužitelja i pakete za instalaciju klijenata. Druga naredba će pokušati instalirati poslužitelja ali neće uspjeti zato što nisu instalirani svi potrebni paketi. Treća naredba će instalirati pakete koji nedostaju i završiti instalaciju poslužitelja. Instalacija će ponovo postaviti nekoliko pitanja o konfiguraciji. Postavite lozinku GRR administratora i adresu 127.0.0.1 kao hostname. Iz naredbe not_wget uklonite not_(DokuWiki ne dozvoljava_wget u tekstu???).

not_wget https://storage.googleapis.com/releases.grr-response.com/grr-server_3.2.4-6_amd64.deb
dpkg –i grr-server_3.2.4-6_amd64.deb
apt --fix-broken install

Odgovori:

MySQL Host [localhost]: 
MySQL Port (0 for local socket) [0]: 
MySQL Database [grr]: 
MySQL Username [root]: grr
Please enter password for database user grr: password
Please enter your hostname e.g. grr.example.com [<machine>]: 127.0.0.1
Frontend URL [http://127.0.0.1:8080/]: 
AdminUI URL [http://127.0.0.1:8000]: 
Email Domain e.g example.com [localhost]: 
Alert Email Address [grr-monitoring@localhost]:
Emergency Access Email Address [grr-emergency@localhost]: 
Rekall is no longer actively supporeted. Enable anyway? [yN]: [N]: 
Please enter password for user 'admin': <lozinka>
Server debs include client templates. Re-download templates? [yN]: [N]: Y
Repack client templates? [Yn]: [Y]:

Nakon što je instalacija završena ponovno pokrenite računalo. Ako je instalacija uspješna naredba systemctl list-units –type=service | grep grr trebala bi ispisati instalirane komponente poslužitelja, barem jedan proces za svaku komponentu. Mrežno grafičko sučelje bit će aktivno na adresi http://localhost:8000.

Prijavite se u mrežno grafičko sučelje kao administrator i s poveznice “Manage Binaries” preuzmite instalacijski paket grr_3.2.4.6_amd64.deb. U terminalu kao administrator naredbom dpkg -i grr_3.2.4.6_amd64.deb instalirajte klijenta na računalo. Postavite kursor u traku za pretraživanje i kliknite na ikonu povećala. Ako se nakon kratkog vremena klijent pojavi u rezultatima pretraživanja postavljanje testnog okruženja je završeno.

U potrazi za tragovima na računalu informacije se pojavljuju u obliku dnevničkih zapisa operacijskog sustava i drugih programa, popis aktivnih servisa, procesa ili korisnika, itd. Lokacije informacija na računalu i njihov format ovisi o faktorima poput: operacijskog sustava, inačice operacijskog sustava ili razmatranog programa, metodi instalacije programa, itd. Kako bi se omogućilo automatsko prikupljanje informacija u sklopu GRR-a razvijeni su artefakti. Artefakti opisuju tražene informacije u YAML jeziku. Upotrebom artefakata moguće je definirati pretrage za specifičnim informacijama poput povijesti web preglednika Mozilla Firefox neovisno o platformi na kojoj se klijent nalazi ili inačici preglednika. Primjer artefakta koji definira lokacije i format povijesti mrežnog preglednika možete vidjeti ovdje (linija 292). Poslužitelj dozvoljava uvoz i izvoz vlastitih artefakata.

Za demonstraciju primjene toka odabran je ArtifactCollectionFlow iz kategorije Collectors. Taj tok kao argument prima listu artefakata. Ovisno o informacijama koje poslužitelj ima (o klijentu na kojem će se tok pokrenuti) transformirat će puteve i nazive datoteka iz artefakta i zatražiti od klijenta da prenese informacije poslužitelju. Osim naziva i puteva do datoteka moguće je definirati uvjete koje datoteka mora zadovoljiti da bi se našla u rezultatu toka. Neki od tih uvjeta su veličina datoteke ili postojanje uzorka u nazivu ili sadržaju datoteke, itd. ArtifactCollectionFlow će uvjete provjeravati na poslužitelju. U slučaju da takav pristup generira pre velik mrežni promet možemo koristiti ClientArtifactCollector koji će zadatak provjere uvjeta prenijeti na klijenta. Mana takvog pristupa je da poslužitelj neće znati da postoje datoteke koje odgovaraju artefaktu kojeg tražimo ali ne zadovoljavaju neki uvjet.

Novi tok možemo pokrenuti tako da kroz tražilicu nađemo željenog klijenta i otvorimo stranicu s njegovim detaljima. S lijeve strane prozora ažurirat će se meni s novim opcijama specifičnim za tog klijena (slika). Klikom na Start new flows(1) otvara se prozor prikazan na slici. U lijevom dijelu novonastalog prozora nalazi se lista s kategorijama tokova koje možemo pokrenuti. Odabiremo tok ArtifactCollectonFlow(2) iz kategorije Collectors. U sredini prozora otvara se meni s argumentima(3) koje možemo zadati tom toku. Iz liste instaliranih artefakata odabiremo artefakte FirefoxHistory i LinuxLogFiles. Odmah ispod liste artefakata nalaze se dodatne opcije za svaki tok. Najzanimljivija od njih je Use tsk. Ako ju odaberemo klijent će pokušati naći artefakte primjenom TSK alata. Tu bi opciju odabrali ako postoji sumnja da je korisnik pokušao ukloniti povijest pretraživanja preglednika. U našem slučaju nećemo odabrati tu opciju. Nakon što smo odabrali sve opcije na dnu prozora pritiskom na Launch pokrećemo tok.

Stanje pokrenutog toka možemo vidjeti odabirom opcije Manage launched flows(1) iz lijevog menija. U gornjem djelu prozora prikazano je nekoliko posljednjih tokova. Jednom pokrenut tok može biti u sljedeća tri stanja: TERMINATED, ERROR i RUNNING. Prvo označava da je tok uspješno završen, drugo da je prekinut zbog greške i treće da još nije završio. Tok na dnu liste (slika) je tipa CAEnroler i vidimo ga ga je pokrenut od strane komponente radnika. To je prvi tok koji se izvodi za svakog novog klijenta i zadužen je za registraciju klijentskog certifikata. Nakon njega izvodi se Interrogate tok. Njega je postavio i pokrenuo CAEnroler tok, a zadatak mu je od klijenta preuzeti osnovne informacije o računalu na kojem je instaliran. Na vrhu liste nalazi se posljednji pokrenuti tok(2), u ovom slučaju naša pretraga povijesti mrežnog preglednika. Kvačica u stupcu Status označava da je tok uspješno izveden. Rezultate toka možemo pregledati odabirom kartice Results(3). Klikom na tablicu u nižoj polovici prozora pojavljuje se povijest preglednika koju je klijent uspio pronaći koristeći artefakata koje smo mu zadali.

Kada smo sigurni da neki tok funkcionira i da vraća dobre rezultate na jednom klijentu moguće ga je pokrenuti na većem skupu klijenata. Mehanizam za pokretanje nekog toka na više klijenata naziva se lov (Hunt) i ključan je u istragama u poslovnom okruženju. Najlakši način za pokrenut novi lov je iz prozora Manage launched flows. Klikom odabiremo tok koji želimo pokrenuti na većem skupu računala i iznad liste tokova odabiremo opciju create new hunt from flow (ikona nišana). U novom prozoru možemo podesiti parametre lova. Glavni parametri su naziv lova, ograničenje na broj klijenata koje će lov obuhvatiti i vrijeme trajanja lova. Kada se novi klijenti registriraju na poslužitelja on će provjeriti postoji li neki lov koji je aktivan i koji bi se trebao pokrenuti na tom klijentu. Moguće je postaviti takva pravila lova da neće završiti dok god se prijavljuju novi klijenti, zato postoji vrijeme trajanja. Lov se smatra gotovim kada se tok koji lov pokreće uspješno izvrši na svim klijentima koje obuhvaća ili na definiranom broju klijenata.

Skup klijenata koje će lov obuhvatiti definiramo parametrima u kategoriji Where to run. Neka od pravila kojima se skup definira su operacijski sustav, instaliranim zakrpama na sustavu, inačici klijenta, inačici operacijskog sustava, itd. Kad smo postavili sva pravila lov pokrećemo klikom na Create Hunt. Stanje lova možemo vidjeti u prozoru Hunt Manager. Lov se neće pokrenuti odmah pri dodavanju u sustav, potrebno ga je ručno pokrenut klikom na Run Hunt. Pri prvom pokretanju lova savjetuje se postaviti ograničenje na broj klijenata. Ako lov uspješno napreduje to se ograničenje može kasnije ukloniti kako bi lov obuhvatio cijeli skup. Za razliku od toka greška na jednom klijentu neće uzrokovati neuspjeh lova, on će se nastaviti do isteka roka ili dok ne prođe cijeli skup klijenata. Moguće ga je prekinuti u bilo kojem trenutku i do tada skupljeni rezultati neće biti odbačeni.

Svaku datoteku koju klijent prenese, bez obzira je li ona dio rezultata toka, poslužitelj će pohraniti u bazu podataka. U direktoriju /home/rac/test stvorili smo 10 datoteka. Koristeći tok FileFinder iz FileSystem kategorije pokušat ćemo pronaći te datoteke. Tok FileFinder kao argument uzima listu puteva na kojima će tražiti datoteku. Put na kojem ćemo pretraživati je [users.homedir]/test/file* (simbole [ i ] zamjenite simbolima % x2, DokuWiki ne dozvoljava % x2). Taj će se put proširiti u sljedeći /home/rac/test/file[x] gdje će se x zamijeniti znamenkom iz naziva datoteke. Parametar Pathtype određuje koji će se datotečni sustav na klijentu pretraživati. Moguće je odabrati jednu od tri vrijednosti: OS, TSK i REGISTRY. OS govori klijentu da pretraži datotečni sustav kroz pozive operacijskog sustava tj. na način na koji ga vide programi i korisnici. Postavljanjem TSK klijent će iskoristiti direktan pristup uređaju i sam rekonstruirati datotečni sustav pomoću alata TSK. Treća opcija je REGISTRY i odnosi se na Windows Registry bazu podataka. Klijenti instalirani na Windows platformi mogu interpretirati Windows Registry kao datotečni sustav i poslužitelju prenijeti vrijednosti iz njega. Akciju koju klijent izvesti kada pronađe datoteku određena je trećim parametrom. Moguće akcije su zabilježiti postojanje datoteke (STAT), preuzeti sažetak datoteke (HASH) ili preuzeti datoteku u cijelosti (DOWNLOAD). Odabrat ćemo parametre OS i STAT i pokrenuti tok.

Skupljene datoteke i metapodatke moguće je pretraživati kroz virtualni datotečni sustava (VFS). VFS-u nekog klijenta moguće je pristupiti odabirom Browse Virtual Filesystem u lijevom izborniku. U lijevoj polovici novog prozora nalazi se stablo virtualnog datotečnog sustava s korijenskim direktorijem naziva fs. Taj direktorij za svakog klijenta ima dva poddirektorija koji predstavljaju dva pogleda na sadržaj sekundarne memorije računala. Pod direktorijem os nalaze se datoteke prikupljene koristeći pozive operacijskog sustava a pod direktorijem tsk koristeći TSK alat. Na desnoj polovici prozora nalazi se lista datoteka i direktorija koje pripadaju trenutno izabranom direktoriju. U toj listi vidimo 10 datoteka koje smo stvorili. Sada te datoteke možemo ukloniti naredbom rm -rf test i ponovo pokrenuti tok FileFinder ali ovaj put s Pathtype parametrom postavljenim na TSK. Ako klijent upije pronaći te datoteke koristeći TSK alat one će se pojaviti u podstablu tsk direktorija. Direktoriji tsk i os su potpuno odvojeni što zaći da otkriće tih (sada izbrisanih) datoteka TSK alatom neće utjecati na sadržaj os direktorija. Ako ponovo pokrenemo FileFinder tok s parametrom OS sadržaj (os direktorija) će se ažurirati i datoteke će nestati iz trenutnog prikaza. Kada klijent obavijesti poslužitelja da ne može naći navedene datoteke (da su obrisane) poslužitelj će ažurirati stanje virtualnog datotečnog sustava. On neće ukloniti starije kopije datoteka i informacije o njima. Starijim stanjima virtualnog datotečnog sustava možemo pristupiti preko padajućeg izbornika Timeline u gornjem desnom kutu prozora.

GRR Rapid Response je jedinstveni alat koji omogućuje forenzičku analizu udaljenih računala za vrijeme rada. Iznimno je skalabilan i omogućava brzu reakciju na incidente. Testno okruženje za alat lako je postaviti ali to nije istina za primjenu u stvarnom svijetu. Od organizacija koje odluče koristiti ovaj alat očekuje se da sam postave infrastrukturu potrebnu za njegovu primjenu. Budući da je alat besplatan Google ne nudi nikakvu podršku pri postavljanju i primjeni alata. Dokumentacija je oskudna s obzirom na mogućnosti alata i od organizacija koje se odluče koristiti alat se očekuje da pomognu pri razvoju i dokumentaciji. Svi ovi uvjeti ograničavaju skup organizacija koje bi mogle izvući korist iz ovog alata. Zakrpe za pronađene mane redovito se objavljuju na github repozitoriju. Ovaj rad pokriva samo osnovne mogućnosti i osnove arhitekture alata. Čitateljima koje zanima više savjetuje se da pročitaju dokumentaciju i članke koji opisuju alat i njegove komponente te da zavire u izvorni kod alata. Alat je besplatan i otvorenog koda izdan pod Apache 2.0 licencom.

[1] GRR documentation

[2] Distributed forensics and incident response in the enterprise

[3] OpenNSM (GRR Rapid Response – Greg Castle)

[4] GRR Users Meetup: Fleetspeak, API client, Go rewrite

[5] GRR: Find All the Badness, Collect All the Things