Restringindo o acesso à rede do contêiner do Docker

Estou no processo de criar um contêiner Docker exclusivo para SFTP , que será usado por várias pessoas com o único objetivo de fazer upload e gerenciar arquivos em seu próprio chrootambiente ed.

No papel, é bastante seguro: desabilitarei todas as formas de bashlogin e não executarei nenhum outro processo nela. No entanto, gostaria de endurecer um pouco mais:

Quero impedir que esse contêiner acesse a Internet de dentro para fora, exceto pelo propósito de ser um servidor SFTP.

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

No entanto, eu gostaria de fazer o seguinte comando (como exemplo) falhar, quando 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 podendo ser usado para enviar e-mails de spam, etc.).

Ainda faz sentido colocar algumas regras de entrada na instância do docker para ajudar a evitar ataques, mas você terá que limitar o acesso de saída (Internet) de qualquer roteador upstream ao qual a imagem do docker se conecte. O motivo disso é que, se você tentar bloquear o acesso de saída com as regras de firewall dentro de sua instância, se a instância estiver comprometida, essas regras poderão ser removidas pelo invasor. Ao bloquear a saída pelo roteador da instância, você bloqueia o acesso de saída mesmo no caso de um comprometimento - o invasor também precisará comprometer o roteador.

Ok, então, depois de receber algum comentário que explica que a filtragem foi planejada para o host do contêiner, fica 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 contêiner. A terceira regra diz (aproximadamente) que qualquer coisa que não seja a sub-rede do host direcionada para SFTP é apenas aceitável por nós; a quarta é a regra de saída que é basicamente uma irmã gêmea da terceira; a quinta regra é genérica (no caso de outras portas relacionadas serem usadas), embora não deva ser necessária, você provavelmente poderá 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 é fornecido 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ê deseja, você não encontrou nada com o que foi aprovado, então você não pode chegar lá daqui ". O tráfego de entrada de fora será atendido pelas 3ª e 4ª regras.

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

1. Use iptablesregras com estado para permitir conexões de entrada e tráfego relacionado / estabelecido e, em seguida, bloqueie todo o resto.

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

Em geral, se você não permite que seus usuários obtenham um shell e não executa programas a partir do contêiner, não precisa se preocupar com isso.

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

Para impedir o tráfego de saída em portas não SSH (SFTP) e Web, convém aplicar a política via IPTABLES ou outro firewall Layer4 ao tráfego DROP ou REJECT originado no segmento usado pelos contêineres do docker destinados a 0.0.0.0/0, exceto quando Destination A porta é TCP22.

Para resolver o problema de não aprovar lugares na Web, convém tentar configurar uma instância de um proxy de filtragem / armazenamento em cache, como squid ou bluecoat, que esteja ouvindo na interface docker0 e que esteja usando a rota padrão do host para acessar a Internet. A partir daí, você pode aplicar a política com base em vários critérios, além de salvar a utilização da rede, armazenando em cache o conteúdo estático. Você pode querer usar o NAT (acho que o IPTABLES e o 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 para eu quero proxy somente HTTP, mas não sei ao certo o que fazer com o tráfego HTTPS ). Isso implica ter um motivo para acessar a Web em primeiro lugar, em conformidade com as políticas da sua empresa.

Devido à natureza do SSH (no qual o SFTP se baseia), você não poderá fornecer interdição de tráfego para movimentação de arquivos, a menos que implemente uma política na qual os contêineres possam usar apenas pares de chaves fornecidos por você. Isso é bom para você, porque fornece alguns " Eu não tinha visibilidade ou controle sobre os arquivos transferidos"defesa se um de seus clientes transferir algo ilegal (como violação de IP ou usar seu serviço para exfiltrar informações com uma etiqueta de classificação ou negociarem com CP), se você for levado a tribunal por algo que seus clientes fazem (pense análogo a status de operadora comum para empresas de telecomunicações). Isso é ruim para você porque você não pode armazenar em cache freqüentemente arquivos transferidos e inalterados e porque qualquer política que você escrever no contrato com seus clientes será essencialmente inexequível por meios técnicos.