Docker dla zielonych

[spex]

W dniu 13.04.2018 o 15:29, Archi napisał:

Teraz z kolei sposobów na izolację usług jest od groma, począwszy od chroota i jailkita, poprzez dockera, a na twardej wirtualizacji kvm kończąc, nie wspominając nawet o świetnym jailu z FreeBSD i podobnych narzędziach, które są wykorzystywane. Co jest najlepsze? A to już zależy od twojego widzimisię i tego jak bardzo ufasz lub też nie zabezpieczeniu, które chcesz stosować.

Mam pytanie, bo jakoś nie miałem jeszcze kontaktu z Dockerem.

 

1) Czy na jednej maszynie mogę mieć uruchomionych kilka Dockerów. Czy to jest na zasadzie 1 vps=1 docker?

2) Jeśli mogę uruchomić kilka dockerów, to co z usługami, które się powtarzają np. cowmail i coś jeszcze uruchamia ten sam serwer www itp.

[mck]

Uprzedzając - w dokerze jestem jeszcze raczej początkujący, więc mogę nie mieć racji

 

1. Na jednej maszynie może być tylko jeden docker (usługa). Natomiast jeden docker = nieograniczona (teoretycznie) liczba kontenerów.

2. Każdy kontener jest niezależny, więc chyba nic nie stoi na przeszkodzie, żeby każda usługa miała swój własny serwer www, jak i skonfigurować usługi tak, by wszystkie korzystały z jednego.

[spex]

To jeśli można mieć wiele kontenerów, to ktoś może mnie naprowadzić, jak korzystać wtedy z usług wspólnych?

[Archi]

Bardzo prosto - możesz przykładowo zdefiniować, że kontener 1 (nginx) może się porozumiewać z kontenerem 2 (php-fpm) tylko przez port 9000 i tylko w kiernku nginx -> php-fpm, a więc kontener 2 miałby zablokowane wszystkie porty poza allow na TCP ESTABLISHED oraz TCP SYN na 9000, i jedynie od kontenera 1.

 

https://docs.docker.com/v17.09/engine/userguide/networking/default_network/container-communication/

 

Idąc o krok dalej, obydwa kontenery miałyby wspólną przestrzeń plików dla danej strony WWW, ale mógłbyś ograniczyć uprawnienia w taki sposób, że nginx miałby dostęp tylko do statyki (wszystko poza plikami .php), a php-fpm tylko do plików .php (a nie do statyki). Oczywiście to już zależy od wymagań strony WWW (nie wiem czy np. nie czytasz plików txt z poziomu php), ale definitywnie można to ograniczyć. Jedno z takich ograniczeń to np. fakt, że nginx nie potrzebuje w ogóle mieć dostępu write do tego folderu, bo on nigdy żadnych plików tam tworzyć ani modyfikować nie będzie.

 

Idąc o krok dalej - nginx nie powinien mieć żadnego dostępu do kontenera 3, którym jest mysql. Połączenie pomiędzy php-fpm, a mysql wyglądałoby bardzo podobnie co między nginxem i php-fpm, z różnicą portu 3306.

 

Dzieki takiemu zabiegowi, zakładając, że ktoś by całkowicie przejął kontener 1 np. poprzez 0daya root na nginxa, jedynie co byłby w stanie zrobić to przeczytać pliki statyczne (które i tak serwujesz), oraz zawiesić/rozwalić samą usługę. O ile rzecz druga jest oczywista (w końcu 0day na nginxa), o tyle naprawa fuckupu po takiej akcji jest praktycznie bezbolesna i nie niesie za sobą żadnych innych problemów, jak np. fuckup całego serwera, wyciek danych czy dorzucenie malware'u po stronie serwowanych plików. Podobnie rzecz ma się w przypadku 0daya na mysql, ale tutaj byłoby już lepiej bo tego kontenera (jak i php-fpm) w ogóle nie wystawiasz na świat - pójście o krok dalej wymagałoby albo 0daya na php-fpm w specyficznej dla nas konfiguracji nginx -> php-fpm (co jest bardzo trudne biorąc pod uwagę, że nawet nie możemy stworzyć żadnego pliku), albo 0daya na dockera albo sam kernel. Obydwie dziury wymagają o wiele więcej zachodu niż jedynie 0day na nginxa i dodają bardzo sporą barierę w potencjalnej eskalacji, do tego stopnia że raczej bym się nie przejmował taką ewentualnością, choć jest ona oczywiście możliwa.

[spex]

Rozumiem, iż częściowo odpisujesz na tematy poruszone tu

 

Ale mi bardziej chodzi o sytuację, gdzie kontener #1 i #2 korzystają ze swojego nginx'a.  Czy nie lepiej było by, gdyby oba korzystały z jednego serwera? Mniejsze obciążenie?

 

Druga sprawa, jak wtedy wygląda sprawa z dostępem po IP do usługi? W końcu oba nginxy korzystają ze swoich vhostów. Czy to nie spowoduje iż jednak usługa będzie dostępnia na świat a druga nie? Gorzej, jak oba vhosty skonfigurowane są podobne. Będę dostał dostęp losowo do każdej z usług np. po "gołym" IP.

[Borian]

Rozumiem, iż częściowo odpisujesz na tematy poruszone tu
 
Ale mi bardziej chodzi o sytuację, gdzie kontener #1 i #2 korzystają ze swojego nginx'a.  Czy nie lepiej było by, gdyby oba korzystały z jednego serwera? Mniejsze obciążenie?
 
Druga sprawa, jak wtedy wygląda sprawa z dostępem po IP do usługi? W końcu oba nginxy korzystają ze swoich vhostów. Czy to nie spowoduje iż jednak usługa będzie dostępnia na świat a druga nie? Gorzej, jak oba vhosty skonfigurowane są podobne. Będę dostał dostęp losowo do każdej z usług np. po "gołym" IP.

Nie jestem ekspertem ale się wypowiem. Dwa kontenery działają na dwóch różnych portach i od Ciebie zależy na który kontener przekierujesz ruch z portu 80 i/lub 443 hosta. W zależności na który przekierujesz ten będzie widoczny gdy wpiszesz samo ip, na drugi możesz przekierować port np. 8080 i wtedy połączyć się z nim możesz przez IP:8080

[kafi]

10 godzin temu, spex napisał:

Ale mi bardziej chodzi o sytuację, gdzie kontener #1 i #2 korzystają ze swojego nginx'a.  Czy nie lepiej było by, gdyby oba korzystały z jednego serwera? Mniejsze obciążenie?

 

 

Istotą izolacji jest to, że każdy byt jest w swojej własnej piaskownicy po to, aby nawet w przypadku fuckupów czy włamań nie dało się dostać do innych zasobów. Jeżeli chcesz mieć jeden nginx (z punktu widzenia wydajności będzie to oczywiście lepsze aka mniej zasobów będzie zżerać) to daruj sobie po prostu dockera i umieść wszystko bezpośredniona jednym serwerze  

 

 

10 godzin temu, spex napisał:

Druga sprawa, jak wtedy wygląda sprawa z dostępem po IP do usługi? W końcu oba nginxy korzystają ze swoich vhostów. Czy to nie spowoduje iż jednak usługa będzie dostępnia na świat a druga nie? Gorzej, jak oba vhosty skonfigurowane są podobne. Będę dostał dostęp losowo do każdej z usług np. po "gołym" IP.

 

Na hoście dockera definiujesz przekierowanie portów. Oczywiście da się jeden port przekierować tylko do jednej maszyny - to dobrze opisał przedmówca.

Ale jest jeszcze jeden sposób - w osobnym kontenerze postawić serwer reverse proxy (i na niego przekierować publiczny IP) który będzie w zależności od nagłówka Host przekierowywał żądania do odpowiednich kontenerów.

[Archi]

6 godzin temu, kafi napisał:

Na hoście dockera definiujesz przekierowanie portów. Oczywiście da się jeden port przekierować tylko do jednej maszyny - to dobrze opisał przedmówca.

Ale jest jeszcze jeden sposób - w osobnym kontenerze postawić serwer reverse proxy (i na niego przekierować publiczny IP) który będzie w zależności od nagłówka Host przekierowywał żądania do odpowiednich kontenerów.

 

I właśnie to proponuję jak chcesz prawidłowo izolować wszystkie niezależne od siebie serwisy.

 

Oczywiście masz jasną stratę zasobów (niekoniecznie wydajności, ale zasobów) spowodowaną duplikacją procesów dla każdej strony. Plusem jednak jest to, że ewentualny fuckup w kontenerze #1 nie wiąże się z fuckupem w kontenerze #4, nawet jeśli wykorzystują ten sam soft i konfigurację (ponieważ atakujący musiałby jeszcze wiedzieć o tym, że ten kontener w ogóle istnieje na tym samym serwerze, i dostać się do niego).

 

Skonfontuj to sobie z sytuacją, w której dostaje się do serwera mysql i wywalam w kosmos wszystkie strony jednym DROP ALL DATABASES. Jasne, nie zrobi tego zwykłymi uprawnieniami, bo te mu zabierzesz, ale izolację robi się głównie na 0daye i czynniki nieznane, a nie te które możesz załatać, bo te które możesz załatać łatasz bez potrzeby używania dockera.

[Matix8981]

///

Edytowane 18 Kwietnia 2018 przez MateuszCODE