På jobb bruker jeg mye tid på å finne svakheter før noen andre gjør det. Hjemme har jeg derimot aldri egentlig sett på mitt eget nett med de samme øynene. Og hjemmenettet mitt har etter hvert blitt en liten jungel: varmeovner, kameraer, en robotstøvsuger, en NAS og et par servere – noe av det på samme nett, alt sammen med hver sin lille firmware som ingen egentlig følger med på.

Så jeg bestemte meg for å sette opp en sårbarhetsscanner hjemme. Valget falt på Greenbone, storebroren til det de fleste kjenner som OpenVAS – og som fint kjører i Docker.

Litt om Greenbone#

Historien er faktisk ganske morsom. I 2005 bestemte utviklerne bak sårbarhetsscanneren Nessus seg for å gå fra åpen kildekode til en lukket, kommersiell modell. Som svar tok noen av utviklerne den siste åpne versjonen og forket den videre – og resultatet ble etter hvert OpenVAS (Open Vulnerability Assessment Scanner). Prosjektet ble drevet frem med støtte fra det tyske BSI (deres svar på NSM), og siden 2008 er det selskapet Greenbone som har stått bak utviklingen.

I 2017 ryddet Greenbone litt i navnene. Det som før het «OpenVAS framework» ble til GVM – Greenbone Vulnerability Management. OpenVAS er i dag bare navnet på selve skannemotoren, mens GVM er hele rammeverket rundt: en manager-tjeneste (gvmd), et web-grensesnitt (gsad/GSA), og ikke minst Greenbone Community Feed – en samling på godt over 100 000 sårbarhetstester som oppdateres daglig. Alt sammen er gratis og åpen kildekode. Den gratis varianten heter i dag Greenbone Community Edition.

En grei måte å tenke på det: der nmap forteller deg hva som kjører på nettet, forteller Greenbone deg hva som er galt med det.

Hva skal man med sånt hjemme?#

Godt spørsmål – dette er tross alt enterprise-verktøy. Men det er flere gode grunner til å kjøre det i en hjemmelab:

  • Se nettet ditt utenfra. En uautentisert scan viser deg omtrent det en angriper på nettet ditt ville sett: åpne porter, eksponerte tjenester, gammel firmware.

  • Holde øye med IoT. Billige smartdingser er beryktet for å aldri få oppdateringer. Greenbone plukker opp kjente svakheter i akkurat den typen enheter.

  • Verifisere før og etter herding. Kjør en scan mot NAS-en eller serveren, gjør endringene dine, kjør på nytt og se forskjellen svart på hvitt.

  • Teste segmentering. Holder VLAN-ene og brannmurreglene faktisk vann? En scan fra ett segment mot et annet avslører raskt om isolasjonen er reell eller bare teoretisk.

  • Lære. Det er rett og slett lærerikt å bli kjent med verktøyene proffene bruker, i trygge omgivelser der du eier alt selv.

En liten advarsel med en gang: sårbarhetsscanning kan være røft mot skjøre enheter. De billigste IoT-dingsene kan i verste fall henge seg eller reboote under en scan. (klok av skade)

Én tjeneste? Nei – en hel stack!#

Det første som overrasket meg: Greenbone er ikke én container. Det er over tjue tjenester som spiller sammen – skannemotoren, manageren, web-UI-et, en PostgreSQL-database, Redis, og en haug med feed-containere som laster ned all sårbarhetsdataen.

Derfor passer docker compose så godt: i stedet for tjue løse docker run-kommandoer beskriver du hele stacken i én fil, og lar compose orkestrere oppstart og avhengigheter. Greenbone leverer en ferdig compose.yaml, så jobben min var mest å laste den ned og gjøre noen små tilpasninger.

Slik satte jeg det opp#

1. Hent den offisielle compose-fila# 


mkdir -p ~/greenbone && cd ~/greenbone

curl -f -O -L https://greenbone.github.io/docs/latest/_static/compose.yaml

2. Åpne porten#

Som standard binder web-grensesnittet seg til 127.0.0.1 – altså kun tilgjengelig fra selve verten. Kjører du dette på en headless server (som meg), vil du nå det fra en annen maskin. Jeg fjernet derfor 127.0.0.1-låsen på nginx-tjenesten:


  nginx:

    image: registry.community.greenbone.net/community/nginx:latest

    ports:

      - 443:443

      - 9392:9392

En liten felle her: nginx sender all HTTP-trafikk (port 9392) videre til HTTPS på 443. Du bør derfor bruke https://<server-ip> for å komme inn. Er port 443 allerede opptatt på verten din, kan du mappe den til noe annet, for eksempel 8443:443, og bruke https://<server-ip>:8443.

3. Start stacken# 


docker compose -f compose.yaml up -d

Første oppstart drar ned en drøss med images, så her er det bare å smøre seg med tålmodighet.

Tips: På treg lagring kan feed-containerne bruke lang tid på å bli «healthy», og da kan resten av stacken time ut under oppstart. Løsningen er å starte feed-containerne først og la dem laste ferdig i fred, før du fyrer opp resten:


docker compose -f compose.yaml up -d notus-data vulnerability-tests scap-data \

dfn-cert-data cert-bund-data report-formats data-objects

# vent til de er «healthy», så:

docker compose -f compose.yaml up -d

4. Sett admin-passord#

Standardbrukeren er admin. Sett et skikkelig passord med en gang:


docker compose -f compose.yaml exec -u gvmd gvmd gvmd --user=admin --new-password='ditt-passord'

5. Vent på feeden#

Nå kommer den delen som krever mest tålmodighet. Selv om alle containerne kjører, må Greenbone laste hele feeden – alle CVE-ene, sårbarhetstestene og advisories – inn i databasen. Dette kan ta alt fra en halvtime til flere timer.

Du følger med under Administration → Feed Status. Så lenge radene står som «Update in progress…» jobber den fortsatt. Når de i stedet viser en versjon/dato, er feeden inne og scanneren klar til bruk. Ikke start en scan før dette er på plass – uten ferdig feed blir resultatene ufullstendige.

Slik setter du opp en scan#

Greenbone bygger på tre byggeklosser: et Target (hva som skal skannes), en Task (som kobler targetet til en skannekonfigurasjon) og et Report (resultatet).

Target#

Under Configuration → Targets lager du et nytt target:

  • Hosts: subnettet ditt, for eksempel 10.0.0.0/24

  • Alive Test: dette er viktig. Standarden bruker ping for å avgjøre om en host «lever» før den skannes. Problemet er at mange enheter – særlig IoT og Windows-maskiner – ikke svarer på ping, og da hoppes de over selv om de er i live. Jeg satte den derfor til Consider Alive, som behandler alle adresser som levende. Den bruker mer tid, men får med seg alt.

Task#

Under Scans → Tasks lager du en ny task:

  • Scan Targets: targetet du nettopp lagde

  • Scan Config: Full and fast er et godt standardvalg – grundig, men optimalisert for hastighet

  • Scanner: OpenVAS (default)

  • Credentials: la stå tomt for første runde. En uautentisert scan ser nettet slik en utenforstående ville sett det. Autentiserte scans (der Greenbone logger inn på hver host og sjekker patch-nivå innenfra) er kraftigere, men det er et eget kapittel.

Kjør – og vær tålmodig#

Trykk på den grønne start-pilen. Statusen går til Running med en prosentindikator.

En ting å merke seg: prosenten regnes ut fra hosts, ikke tid. Den kan stå lenge på lave tall, hoppe ujevnt, og henge på 1 % eller 98 % i det som føles som en evighet. Det betyr ikke at noe har hengt seg. Et fullt nettverksscan kan fint ta flere timer – la den gjerne gå over natten.

Du kan følge resultatene fortløpende ved å klikke deg inn på selve tasken og se rapporten bygge seg opp per host, med funn sortert etter alvorlighetsgrad (High/Medium/Low).

Resultat#

Etter noen timer satt jeg igjen med et ganske avslørende bilde av mitt eget nett – hvilke enheter som eksponerer mest, hvor det ligger gammel firmware, og hvilke tjenester jeg egentlig ikke visste var åpne. Jeg har planer om dykke mer i Greenbone og andre sårbarhetsscannere.

!Image Description