Taggat med: sysdig

Guide till säkrare containers

Guide till säkrare containers

Senast uppdaterad 2023-09-22

Att containers har blivit en del av många organisationers vardag råder det ingen tvivel om. Med hjälp av populära verktyg såsom Docker, Podman eller Kubernetes (K8s) så realiserar dessa en containerbaserad infrastruktur och applikationsdistribution.

Det är av stor vikt att hålla dessa säkra och nedan följer en guide hur du kan minska risken för eventuella cyberattacker.

Minska attackytan

Först och främst gäller det att minska attackytan. Detta för att minska risken, och att uppnå en 100%-ig säkerhet är så klart helt omöjligt. Men hur gör man för att minska attackytan? Jo det består i flertalet saker:

  • Använd användare med låga behörigheter inne i containern. Kör rootless utanför om möjligt
  • Använd en container till ett syfte. Dvs inte både webbserver och databas, exponera eller installera ej sshd inne i en container
  • Exponera minimalt med kataloger, sockets eller annat mellan containers och mot värden (operativsystemet som kör containers) och vice versa
  • Stäng av sådant som inte behövs, såsom nätverk. Kan stängas av med: –network none
  • Utgå från minimala containers såsom -slim och distroless
  • Skydda API:et eller socketen för att kommunicera med din containermjukvara såsom Podman, Docker osv. Dvs podman.socket och /var/run/docker.sock samt TCP-portarna 2376/2375
  • Håll dockerd, podman etc uppdaterat och även containers
  • Undvik argument såsom : –privileged och –cap-add då dessa öppnar upp för ”container escape” sårbarheter

Attacker via mjukvarukedjan (supply chain)

Ladda inte hem och använd godtyckliga containers, utan utgå ifrån sådana som är signerade och verifierade. Använd verktyg såsom cosign och docker trust för att verifiera. Det har hänt flertalet gånger att containers innehåller bl.a. crypto-miners.

Exempel på hur docker trust inspect kan användas för att validera alpine:latest

dock trust inspect alpine:latest

Och för cosign där jag verifierar distroless python3-debian11:

Även om containers är signerade så är det givetvis ingen garant för att den innehåller bakdörrar.

Loggning och spårbarhet

Det är av stor vikt att logga även sådant som händer i containers. Det vanligaste sättet är att skriva loggarna till stdout och sedan fånga upp detta. Viktigt är att centralt samla in loggarna och analysera dessa ytterligare efter avvikande mönster, kända attacker osv.

Även så finns det verktyg såsom Sysdig Falco eller auditd som kan kontrollera beteendet på dockerd eller inviduella containers. Exempel på hur audit.rules kan se ut för docker:

-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

Glöm inte heller att logga och analysera nätverkstrafik som går in/ut ur respektive container, använd Suricata, Zeek eller Arkime. Försök att skilja på applikationsloggar, operativsystemsloggar, prestandaloggar etc. Även om alla är viktiga så har alla sina unika mönster för att identifiera intrång. Andra saker som kan skilja är hur länge du vill lagra dessa.

Sårbarhetsskanning

Det finns många bra verktyg för att genomföra sårbarhetsskanning av containers. Dels det inbyggda kommandot docker scout (tidigare docker scan som använde Snyk) och dels tredjepartsverktyg såsom trivy och grype.

Jag tänkte göra en snabb jämförelse mellan dessa tre enligt nedan.

Trivy

Jag använder en test-image vid namn hello-python. Sedan kör jag kommandot:

trivy image hello-python

Då identifierar den tre sårbarheter i python-paket och 47 st i alpine 3.11.5:

trivy container vulnerability scan

Grype

För att skanna av en container med grype kör jag kommandot:

grype hello-python

Och då hittar den enligt nedan. Totalt blir det 118 kända sårbarheter som identifieras, vilket är flest antal av de tre verktyg jag testar. Men dock räknar jag antalet CVE:er och GHSA:s individuellt så blir det 81 st.

grype docker vulnerability scan

Docker Scout

Kör jag med senaste versionen av docker scout, som tyvärr måste laddas hem separat då nyaste versionen ej ingår i Docker Desktop så hittar den 67 sårbarheter i 12 paket.

Även Docker Scout identifierar tre sårbarheter i python-paket (pypi). Kommandot jag använder är:

./docker-scout cves hello-python
docker scout vulnerability scan

Övrigt

Kan även rekommendera att titta på lösningar såsom Kata och Gvisor som tillför ett extra lager med säkerhet i Er container-miljö.

Vissa IT-forensiska utmaningar kan också uppstå i en container-baserad miljö. Se därför till att öva på olika scenarion där en container eller dess host-operativsystem drabbats av intrång, eller möjlighet att söka efter IOC:er (Indicators of Compromise).

Fick tips om att UFW ej fungerar tillsammans med Docker. Även en rekommendation om att skapa upp SBOM:s för alla dina containers, som jag bloggat tidigare om.

Se även över om ni kan upprätta ett eget container-index och således få en bättre överblick över vilka containers om används inom organisationen.

Bild skapad med Midjourney

Threat Hunting med osquery

Osquery är ett open-source projekt från Facebook som släpptes under år 2014. Osquery är ett verktyg för att ställa SQL-liknande frågor mot servrar och klienter. Detta är bra för att hålla koll på vad som händer i infrastrukturen. Ett axplock med några av de frågeställningar som osquery kan svara på:

  • Vilka processer körs på våra klienter?
  • Vilka TCP och UDP-portar lyssnar våra servrar på?
  • Vilka USB-minnen har varit anslutna till våra system?
  • Finns filen med namn eller checksumman XX någonstans?
  • Vilka processer kommunicerar ut på nätverket?

Osquery stödjer Windows, Linux, FreeBSD samt macOS. Dock kan funktionaliteten skilja sig mellan olika operativsystem.

Exempel på SQL-fråga som ställs via osqueryui:

I sin grundinstallation är osquery relativt avskalat och saknar mycket av den funktionalitet som man kan få med ett kommersiellt verktyg som kommer färdigt med avancerade rapporteringsfunktioner och signaturer. Därför kan du bygga stödfunktioner själv till osquery eller använda något av det som finns tillgängligt såsom Kolide, Doorman eller Uptycs som ser till att SQL-frågor kan ställas över nätverket. Loggningen från osquery kan med fördel hällas in i ELK-stacken eller Splunk.

När det gäller mallar för osquery för att titta på avvikelser eller anomalier så kan jag rekommendera Palantirs osquery-configuration, så kallade query packs.

Här är en skärmdump som visar på att jag 5 st query packs installerade i Kolide Fleet med fokus på Windows:

Det query pack som heter windows-attacks har 15 st SQL-frågor som går var 60:de sekund på 3 st klienter. Rapporter på utfall hamnar hamnar i filen osquery_result centralt på servern som kör Kolide Fleet, och filen ser ut ungefär enligt följande:

Och vill vi titta på hur just den SQL-frågan som genererade ovan JSON-loggrad så tittar vi bara på windows-pack/os-version som ser ut enligt följande:

SELECT * FROM os_version;

Eftersom action är added så är det första gången denna SQL-fråga kördes. Men du behöver inte köra frågor regelbundet utan kan även ställa vissa typer av realtidsfrågor beroende på operativsystem, se stödet i denna tabell (längst uppe i högra hörnet ser du en OS-symbol för varje tabell).

Fördelar med osquery 👍

Osquery gör att du kan inventera hela din infrastruktur och söka rätt på hot, så kallad Threat Hunting. Nästan allt är öppen källkod med bra licenser och gör det enkelt för organisationer med resurser att anpassa osquery till sina behov. För realtidsövervakning skulle jag dock komplettera med sysdig eller sysmon.

Du har även full insyn i samtliga regler och varför dessa larmar , vilket kan vara ett problem med många antivirus-mjukvaror då dessa ofta är stängda.

Nackdelar med osquery 👎

Du måste göra mycket själv och bör ha en god kännedom gällande open-source utveckling. Majoriteten av alla frågor är så kallade poll-baserade och gör att en angripare kan flyga under radarn. Precis som många andra skyddsfunktioner så kan en angripare stänga ner eller modifiera osquery.

Sammanfattning

Jobbar du med cybersäkerhet och inte har tittat på osquery efter att ha läst detta gör du tjänstefel. Undersök och labba själv på egen kammare med exempelvis DetectionLab.

Jag är även rätt säker på att osquery är en av de få säkerhetsrelaterade mjukvaror som snurrar på Mark Zuckerbergs Macbook.

Även kan Wazuh v3.5.0, uppföljaren till OSSEC kan stödja osquery sedan fem dagar tillbaka.

Stöd gärna mitt bloggande via Patreon.