Docker i zapora sieciowa: bezpieczne publikowanie portów

To pułapka, w którą wpada większość osób. Port opublikowany w Dockerze za pomocą ports: jest dostępny z internetu, nawet jeśli ufw ten port blokuje. Docker ustawia własne reguły zapory, które mają pierwszeństwo przed regułami ufw.

Przykład tego, co idzie nie tak

services:
  db:
    image: mariadb:11
    ports:
      - "3306:3306"

Zapora wskazuje, że otwarte są tylko porty 22, 80 i 443. Mimo to Państwa baza danych jest teraz dostępna z całego świata na porcie 3306.

Trzy zasady, które zapewniają bezpieczeństwo

1. Prosimy publikować tylko to, co musi być dostępne z zewnątrz. W tym podręczniku jest to wyłącznie Caddy, na portach 80 i 443. Aplikacje komunikują się z Caddy przez wewnętrzną sieć compose. Nie potrzebują one ports:.
2. Port ma być dostępny tylko na samym serwerze? Prosimy poprzedzić go 127.0.0.1:. Wtedy dostęp do niego ma tylko sam serwer lub Państwo przez tunel SSH (zob. Plik konfiguracyjny SSH: logowanie za pomocą krótkiej nazwy).
3. Baza danych nigdy nie otrzymuje ports:. Aplikacja odnajduje ją po nazwie usługi, na przykład db.

    ports:
      - "127.0.0.1:3001:3001"

Kontrola z zewnątrz

Prosimy sprawdzić na serwerze, które porty są otwarte dla wszystkich:

anna@web1:~$ sudo ss -tlnp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096        0.0.0.0:443         0.0.0.0:*     users:(("docker-proxy",...))
LISTEN 0      4096      127.0.0.1:3001        0.0.0.0:*     users:(("docker-proxy",...))
LISTEN 0      128         0.0.0.0:22          0.0.0.0:*     users:(("sshd",...))

Wszystko z 0.0.0.0 lub [::] jest dostępne z zewnątrz. Wszystko z 127.0.0.1 jest dostępne tylko wewnętrznie. Aby sprawdzić to z zewnątrz, prosimy użyć na własnym komputerze skanera portów, takiego jak nmap, skierowanego na własny adres IP.

Uwaga: Prosimy nie montować /var/run/docker.sock w kontenerze, chyba że dokładnie wiedzą Państwo, dlaczego. Kto przejmie taki kontener, przejmuje tym samym cały Państwa serwer.