04 juni 2021

Nettverksflyt på innsiden av en Docker Server

3 min lestetid

Nettverksflyt på innsiden av en Docker Server

04. juni 2021

Når vi er sikkerhetsfokusert kan vi ikke anta hvordan ting skal fungere. Vi må vite hvordan ting fungerer, slik at vi kan ta de nødvendige skrittene for å sikre det. 

Det er med denne intensjonen jeg har skrevet denne korte artikkelen; Forklare hvordan nettverkstrafikk flyter på innsiden av en Docker server, og noen måter å sikre den på.

En Docker-server forklares med en serie linux-namespaces som er tilknyttet kjernen ved hjelp av en logisk bro eller direkte. I praksis betyr dette at en container ikke får sin egen tilgjengelige IP-adresse, men i stedet deler en bro og privat IP-pool med de andre containerne. Dette standardoppsettet har en sikkerhetstrussel. Docker har som standard ingen enkel måte å kontrollere interntrafikken mellom containere.

Nettverksflyt

Docker Network flow

Bildet viser hvordan nettverket ser ut på innsiden av Docker-serveren.

Som vist på bildet er alle containere koblet til en logisk lag 2 bro. Som deretter er koblet til en logisk lag 3 ruter, som har den primære funksjonen å oversette source-ip (NAT).

Hvis Container A ønsker å snakke med Container C vil den sende trafikken over broen å snakke direkte med Container C. Men hvis Container B blir kompromittert vil angriperen ha få problemer med å kompromittere de andre containerne.

Når Container C ønsker å snakke med en tjeneste utenfor serveren, vil den gå igjennom den logiske lag 3 ruteren. Ruteren vil erstatte source IP’en i datapakkene med server IP’en. Sesjonen blir så tilknyttet til den kortvarige kildeporten, source-port, Container C bruker i forbindelsen.

Sikkerhetstiltak #1

Docker Security Measure 1

Det første sikkerhetstiltaket vi kan ta er å fjerne broen; endre kommunikasjonen mellom containere på Docker-serveren til lag 3 i stedet for lag 2. Når vi gjør dette vil vi få større kontroll over nettverksflyten.

I dette eksemplet har jeg brukt Calico som løsning. Calico fungerer som en Container Network Interface (CNI) plugin. Det betyr at den kan endre hvordan pakkene vil bevege seg fra en container til en annen container eller en annen server. Calico har støtte for avanserte nettverksregler beregnet for container trafikk. Dette er nyttige for oss for å begrense trafikken mellom containere på samme server.

Videolink til en forklaring av Calico
Videolink til en forklaring av CNI

Sikkerhetstiltak #2

Docker Runtime_

https://blog.paloaltonetworks.com/2020/07/network-cn-series-firewalls/

Et annet sikkerhetstiltak vi kan ta er å installere en container-native brannmur inne på serveren, i dockermiljøet. Den container-native brannmuren vil da legge til en ny plugin til docker runtime. Den vil ikke erstatte den eksisterende nettverks-pluginen, men i stedet kjede seg på de andre pluginene.

Docker picture 3

Bildet viser tre containere eller pods. Den gule linjen viser den tiltenkte trafikken for Container A. Container A ønsker å snakke med Container C. Den begynner å sende pakkene utover til Net Plugin, som i vårt tilfelle er Calico. Og deretter vil den treffe chained-plugins, som i vårt eksemplet er Pan-CNI. Pan-CNI er konfigurert opp til å sende utgående pakker til containeren som heter CN-NGFW. CN-NGFW har som oppgave å analysere pakkene og deretter verifisere dem opp mot de avanserte sikkerhetsreglene vi har konfigurert. Dette skaper full visibilitet og kontroll på trafikken mellom containere.

I dette eksemplet har jeg brukt Palo Alto Network Next-Generation Firewall bygget for Kubernetes.
Mer info finner du her

 

 

Filip Fog

Skrevet av Filip Fog

Filip er sertifisert på alle de tre hovedområdene innenfor Palo Alto Networks. Strata (PCNSC & PCNSE), Cortex (PCSAE) og Prisma Cloud (PCCSE). Filip er også sertifisert innen hendelseshåndtering (GCFA) og nettverksundersøkelse (GCIA). Han jobber aktivt med å håndtere hendelser fra endepunkt og perimeter, og automatisere håndteringen av slike hendelser.

Relaterte artikler