Skocz do zawartości
spex

Docker dla zielonych

Rekomendowane odpowiedzi

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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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.

  • Lubię 6

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
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.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Napisano (edytowane)

///

Edytowane przez MateuszCODE

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

×

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.