Anatomia incydentu: Docker, iptables i port bazy wystawiony do internetu

Kontekst: przejęcie środowiska w utrzymanie

Klient zgłosił się do nas po odejściu poprzedniego wykonawcy. Zadanie brzmiało prosto: przejąć infrastrukturę opartą o Proxmox VE w stałe utrzymanie. Środowisko działało, użytkownicy nie zgłaszali problemów, dokumentacja istniała w formie szczątkowej.

Każde środowisko, które bierzemy w utrzymanie, przechodzi na wejściu standardowy health check: przegląd konfiguracji klastra, backupów, sieci i bezpieczeństwa. Nie dlatego, że zakładamy złą wolę poprzednika, tylko dlatego, że nie da się odpowiadać za coś, czego się nie zna. Ten przypadek pokazuje, po co ta procedura istnieje.

Znalezisko: kontener z bazą na hoście wirtualizacji

Na jednym z hostów PVE ktoś kiedyś zainstalował Dockera i uruchomił kontener z bazą danych. Kontener został wystartowany z opcją publikacji portu, klasyczne -p 5432:5432 bez podania adresu. Prawdopodobnie miało to być tymczasowe rozwiązanie na potrzeby jakiegoś testu. Zostało na miesiące.

Problem polega na tym, jak Docker współpracuje z iptables. Przy publikacji portu Docker dopisuje własne reguły NAT i FORWARD do łańcucha DOCKER. Te reguły są przetwarzane, zanim pakiet dojdzie do reguł firewalla skonfigurowanych przez administratora hosta. Ruch do opublikowanego portu w ogóle nie trafia do łańcucha INPUT, w którym administrator umieścił swoje blokady.

Efekt: port bazy danych odpowiadał z publicznego adresu serwera, mimo że firewall hosta teoretycznie blokował wszystko poza SSH i panelem. Administrator był przekonany, że jest bezpiecznie, bo patrzył na swoje reguły DROP i one faktycznie tam były. Po prostu nigdy nie miały okazji zadziałać dla tego ruchu.

Diagnoza: skan z zewnątrz, nie tylko widok od środka

Znalezisko nie wyszło z przeglądania konfiguracji w GUI. Wyszło z dwóch rzeczy, które robimy w każdym audycie:

• Zewnętrzny skan portów. Skanujemy publiczne adresy środowiska z niezależnego hosta w internecie. Skan pokazał otwarty port bazy tam, gdzie według konfiguracji firewalla nie miało prawa być nic.
• Przegląd pełnego iptables-save. Nie GUI firewalla, nie lista reguł "naszych", tylko kompletny zrzut wszystkich tabel i łańcuchów. Dopiero tam widać łańcuchy DOCKER i reguły NAT, których administrator nigdy sam nie napisał.

Lekcja z diagnozy jest prosta: audyt bezpieczeństwa musi patrzeć na środowisko z zewnątrz, oczami atakującego, a nie tylko od środka, oczami administratora. Widok od środka pokazuje intencje. Skan z zewnątrz pokazuje stan faktyczny. W tym przypadku różnica między jednym a drugim to był otwarty port bazy produkcyjnej.

Naprawa: od zatkania dziury do zmiany architektury

1. Natychmiast: zmiana bindowania portu na 127.0.0.1, dostęp do bazy wyłącznie przez tunel SSH. Port przestał odpowiadać z zewnątrz w ciągu minut od potwierdzenia znaleziska. Do tego rotacja haseł bazy i przegląd logów pod kątem śladów nieautoryzowanego dostępu.
2. Docelowo: przeniesienie kontenerów z hosta PVE do dedykowanej maszyny wirtualnej. Host wirtualizacji wrócił do swojej jedynej roli: uruchamiania VM i kontenerów LXC zarządzanych przez Proxmox.
3. Reguły firewalla dla Dockera w łańcuchu DOCKER-USER, czyli jedynym miejscu, którego Docker nie nadpisuje i które jest przetwarzane przed jego własnymi regułami. Tam trafiły jawne ograniczenia dostępu do usług kontenerowych.
4. Skan całej podsieci w poszukiwaniu podobnych przypadków. Jeden "tymczasowy" kontener rzadko występuje w pojedynkę. Sprawdziliśmy każdy publiczny adres środowiska.
5. Stały monitoring otwartych portów z zewnątrz. Cykliczny skan z niezależnego hosta z alertem przy każdej zmianie listy otwartych portów. Konfiguracja może się rozjechać ponownie, monitoring wyłapie to w godziny, nie w miesiące.

Wnioski