Restringindo o acesso de rede do contêiner Docker

Question

Estou no processo de criar um contêiner de Docker apenas para o SFTP, que será usado por várias pessoas com o único propósito de upload e gerenciamento de arquivos em seu próprio ambiente chroot ed.

No papel, é bastante seguro: desabilitarei todas as formas de bash login e não executarei nenhum outro processo. No entanto, gostaria de endurecê-lo um pouco mais:

Eu quero evitar que esse contêiner acesse a Internet internamente, exceto pelo fato de ser um servidor SFTP.

Para esclarecer: eu sei como impedir que o mundo externo acesse meu contêiner - posso configurar as regras de entrada iptables e posso expor apenas a porta SFTP no meu comando docker run.

No entanto, gostaria de fazer com que o seguinte comando (como um exemplo) falhasse, quando fosse executado dentro do contêiner:

curl google.com

Minha intenção é diminuir a quantidade de dano que um contêiner hackeado pode causar (não poder ser usado para enviar e-mails de spam, etc.).

    

Answer 1

Ainda faz sentido colocar algumas regras de entrada dentro de sua instância do docker para ajudar a evitar ataques, mas você terá que limitar o acesso de saída (Internet) de qualquer roteador upstream com o qual a imagem do docker se conecte. A razão para isso é que, se você tentar bloquear o acesso de saída com as regras de firewall dentro de sua instância, se a instância for comprometida, essas regras poderão ser removidas pelo invasor. Ao bloquear a saída por meio do roteador da instância, você bloqueia o acesso de saída mesmo em caso de comprometimento - o invasor também teria que comprometer o roteador.

Ok, então depois de receber alguns comentários que explicam que a filtragem foi feita para o host do contêiner, é um pouco mais claro o que está tentando ser realizado. Nesse caso, no host, você adicionaria algumas regras semelhantes a esta:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

As duas primeiras regras são para acesso entre o host e o container. A terceira regra diz (mais ou menos) que qualquer coisa que não seja a sub-rede do host para SFTP é OK por nós; a quarta é a regra de saída que é basicamente uma gêmea para a terceira; a quinta regra é um pega-tudo (caso haja outras portas relacionadas que sejam usadas), embora não devesse ser necessário, você provavelmente poderia removê-la; a última regra é a mágica que impede o acesso a qualquer coisa que não seja a sub-rede do host. Como o acesso é dado nas primeiras regras, ele nunca será acionado a menos que nenhuma das regras anteriores se aplique. Nesse caso, estamos dizendo "não nos importamos com o que você quer, você não corresponde a nada que seja aprovado para você". então você não pode chegar lá a partir daqui ". O tráfego de entrada do exterior será satisfeito pela 3ª e 4ª regras.

    

Answer 2

Este não é realmente um problema específico do docker. Existem algumas maneiras de resolver isso.

1. Use as regras stateful iptables para permitir conexões de entrada e tráfego relacionado / estabelecido e, em seguida, bloquear todo o resto.

2. Use um serviço somente de sftp, como o ProFTPD , que é incapaz de executar um shell.

Em geral, se você não permitir que seus usuários recebam um shell e não permitam que eles executem programas de dentro do contêiner, não será necessário se preocupar com isso.

    

Answer 3

Este é apenas um brainstorm rápido, e eu não testei ainda. Você vai querer examiná-lo no laboratório antes de levá-lo para produção.

Para evitar tráfego de saída em portas não-SSH (SFTP) e Web, você pode aplicar a política via IPTABLES ou outro firewall Layer4 ao tráfego DROP ou REJECT proveniente do segmento usado por contêineres docker destinados a 0.0.0.0/0 exceto quando a Porta de Destino é TCP22.

Para resolver o problema de ir para desaprovação de lugares na web, convém configurar uma instância de um proxy de filtragem / armazenamento em cache, como o squid ou o bluecoat, que está escutando na interface docker0 e que está usando a rota do defall do host para sair da internet. A partir daí, você pode aplicar políticas com base em muitos critérios, além de economizar a utilização da rede armazenando em cache o conteúdo estático. Você pode querer usar o NAT (acho que IPTABLES e Masquerade fornecem isso no Linux) na máquina host para reforçar o uso do proxy de forma transparente (eu descrevi isso na minha resposta a Eu quero fazer proxy apenas HTTP, mas estou Não tenho certeza do que fazer com o tráfego HTTPS . Isso implica ter um motivo para entrar na Web, em primeiro lugar, em conformidade com as políticas da sua empresa.

Devido à natureza do SSH (no qual o SFTP é baseado), você não poderá fornecer interdição de tráfego para movimentação de arquivos, a menos que você implemente uma política na qual os contêineres possam usar somente pares de chaves fornecidos por você. Isso é bom para você, porque dá a você alguma proteção " não tenho visibilidade ou controle sobre arquivos transferidos " se um de seus clientes transfere algo ilegal (como infração de IP ou usa seu serviço para exfiltrar informações carregando um selo de classificação, ou eles negociam em CP), se você for levado a tribunal por algo que seus clientes fazem (pense em analogia com o status de operadora comum para as empresas de telecomunicações). Isso é ruim para você porque você não pode armazenar em cache arquivos frequentemente transferidos, inalterados, e porque qualquer política que você escrever no contrato com seus clientes será essencialmente inexeqüível através de meios técnicos.