Implicações de segurança da configuração do UFW default_forward_policy para aceitar?

7

O manual do docker ( link ) declara que é necessário definir os UFWs DEFAULT_FORWARD_POLICY como " ACEITAR "para que os contêineres do estivador possam alcançar um ao outro.

  1. Qual é a implicação de segurança de fazê-lo em um servidor com interfaces de rede acessíveis publicamente?

  2. O que deve ser feito para proteger um host de docker?

por Niko 28.11.2014 / 16:49

1 resposta

5

Eles parecem ter resolvido essa parte do problema, pelo menos na última versão 1.4.1. Minha política FORWARD é eliminar os pacotes e a comunicação entre contêineres sem problemas.

Essas são as regras padrão na cadeia FORWARD criada pelo docker:

$ iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in      out      source               destination         
 6902   96M ACCEPT     all  --  *       docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 6151  482K ACCEPT     all  --  docker0 !docker0 0.0.0.0/0            0.0.0.0/0           
    3   180 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           

De baixo para cima:

  • A terceira regra é a comunicação docker- & docker, que é aceita sem restrições.
  • A segunda regra é docker- > em qualquer lugar (mas não na janela de encaixe), que também é aceita sem restrições.
  • A primeira regra é em qualquer lugar - > docker, apenas os pacotes "answer" são aceitos.

Sem problemas aqui. (A menos que você queira filtros de saída)

Você pode configurar a política FORWARD + INPUT para DROP / REJECT.

Agora, você pode querer fornecer um serviço na internet. Por exemplo. um simples servidor:

$ docker run -d -p 80:80 dockerfile/nginx

OK, agora vá para yourserver.com. Você verá a página nginx padrão. Por quê? O Docker adicionou algumas regras especiais no iptables para você.

$ iptables -vn -t nat -L # NAT table, truncated for clarity
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  189 11900 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:172.17.0.15:80

$ iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.15          tcp dpt:80
 6903   96M ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 6159  483K ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
    3   180 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           

Essas regras contornam todas as regras do ufw se houver um contêiner de escuta. O ufw não faz nada na tabela nat e o Docker define suas regras em primeiro lugar na cadeia FORWARD. Portanto, não é possível bloquear um endereço IP ou limitar a taxa de qualquer tipo.

Soluções possíveis:

  • Inicie o Docker com --iptables=false e faça tudo manualmente. Solução meticulosa, porque toda vez que você reinicia um container, ele recebe um novo IP (por enquanto, eles planejam mudar isso).
  • Vincule todas as portas no host local com -p 127.0.0.1:30080:80 e crie suas próprias regras de iptables para chegar lá.
  • Modifique o ufw de alguma forma?
  • Não use nenhum framework de firewall. Eu faço isso por enquanto. Todas as minhas regras são salvas em um script separado como comandos do iptables. Este script é executado após as reinicializações e a cada service docker start . Embora um pouco hacky funcione ...
por 24.12.2014 / 04:11

Tags