O Docker ignora silenciosamente seu firewall e a maioria dos laboratórios domésticos não percebe isso

A simplicidade de criar contêineres no Docker é uma das poucas simplicidades de um laboratório doméstico. Encontre um serviço que pareça interessante, extraia uma imagem, escreva um arquivo Compose rápido ou um comando de inicialização do docker, publique uma porta, abra uma interface da web em um navegador. Demora cinco minutos para passar de uma ideia a um serviço executável.

O problema é que o firewall configurado no host – UFW com negação padrão, algumas regras de permissão claras – nunca negocia o tráfego que flui para seu novo contêiner. O serviço pode ser acessado a partir de seu laptop, telefone, smart TV e daquela lâmpada IoT que você planejou colocar em uma VLAN separada. “ufw status” ainda diz “ativo” e não informa incorretamente, o que é todo o problema. O Docker facilita a ativação de serviços, mas também prejudica a rede devido à sua simplicidade.

Docker refatora silenciosamente seu firewall

Não há indicação de que algo esteja errado

O mecanismo pelo qual o Docker modifica seu firewall não é tão malicioso, mas sacrifica a segurança pela simplicidade. Quando você publica uma porta com -pO Docker coloca suas próprias regras no iptables para lidar com o NAT e o encaminhamento necessários para levar o tráfego do host para o contêiner. Essas regras são executadas em uma cadeia chamada DOCKER, que está na cadeia FORWARD. O UFW, por outro lado, opera principalmente na cadeia INPUT e assume que o tráfego destinado a serviços locais flui através dela.

O tráfego para as portas de contêineres publicadas não ocorre dessa forma. Ele vai para a interface de rede do host, é comparado com as regras NAT do Docker e encaminhado para o namespace de rede do contêiner. sem As regras do UFW INPUT estão sempre em discussão. As implicações práticas são as seguintes ufw dias 8080 não faz exatamente nada para o contêiner publicado 8080. O UFW relata “ativo”, mas seu serviço está totalmente aberto. Ambas as afirmações são verdadeiras ao mesmo tempo e é aí que reside o problema.

Um ecossistema de treinamento treina os usuários nesta armadilha

O Docker é aberto sobre isso, mas os tutoriais geralmente não mencionam isso

Consulte quase todos os guias de introdução à auto-hospedagem e você verá o mesmo conselho. A maneira recomendada de descobrir um serviço é -p host_port:container_portsem eliminatórias. Os arquivos de compilação copiados e colados do projeto README geralmente são publicados em 0.0.0.0 por padrão, ou seja, todas as interfaces de host acessíveis de todos os dispositivos na rede. O atrito que deveria existir com a descoberta de serviços é removido.

Desta forma, um iniciante cria uma pilha de dez serviços, cada um acessível de forma independente a partir de qualquer dispositivo na LAN, e assume que o firewall do host é a última linha de defesa. Às vezes, um túnel Tailscale ou WireGuard fica visível na imagem e o usuário assume que a VPN está restringindo o acesso quando a exposição lateral da LAN estava realmente aberta o tempo todo. Essa smart TV pode afetar diretamente esse serviço, assim como seus dispositivos IoT e qualquer outra coisa conectada à sua rede. Basta um dispositivo mal-intencionado e seu serviço auto-hospedado se torna uma enorme vulnerabilidade.

As configurações padrão são muito razoáveis

Não é que as configurações padrão do Docker sejam predatórias

O Docker foi desenvolvido para desenvolvedores que usam contêineres em estações de trabalho, onde publicar uma porta para localhost e além é um padrão razoável. Pedir à plataforma para pesquisar cada usuário sobre sua topologia de rede antes de expor o serviço não corresponde à experiência do desenvolvedor com a qual o Docker teve sucesso, então faz sentido que esse seja o padrão.

Você poderia argumentar que o UFW não é a ferramenta certa para o tráfego de contêineres e que os proxies reversos e a segmentação deliberada são a abordagem correta. Esperar que o firewall do host regule o tráfego de contêineres é um erro conceitual por parte do usuário, e a leitura da documentação resolveria completamente o problema.

Como consertar uma rede de contêineres ruim

É fácil

A maior mudança de alavancagem vincula as portas publicadas ao host local se o serviço for alcançado apenas por meio de um proxy reverso: -p 127.0.0.1:8080:80 em vez de -p 8080:80. O contêiner agora pode ser acessado pelo próprio host, mas não por outra rede. Combine-o com um proxy reverso como Caddy ou Nginx e você terá um ponto de exposição deliberado.

Se você deseja realmente impor o firewall do host, o Docker oferece USUÁRIO DO DOCKER cadeia especificamente para regras definidas pelo usuário que não são limitadas pela automação do Docker. Você pode digitar as regras do iptables diretamente lá ou usar ufw-dockerum projeto comunitário que automatiza a integração entre as cadeias UFW e Docker. Funciona bem e é amplamente utilizado, mas é uma ferramenta de terceiros, portanto sua milhagem pode variar.

Construir uma rede de contêineres pode ser difícil

A simplicidade do Docker cria desafios para quem é iniciante em segurança de rede, mas não vale a pena jogar o bebê fora junto com a água do banho. Cada porta publicada deve ser feita com cautela e os tutoriais do Docker não a descrevem com precisão para o usuário novato. Vincule serviços ao localhost quando eles precisarem apenas de um proxy reverso, use a cadeia DOCKER-USER quando desejar uma filtragem real e não presuma que “ufw status: active” significa que seus contêineres estão protegidos. O Docker torna os serviços de laboratório doméstico maravilhosamente fáceis de construir, mas provisioná-los ainda requer alguma intencionalidade.