
Estou tentando criar um ambiente de laboratório para experimentar ataques MiTM. Também quero aprender o docker, então decidi fazer isso com o docker. Criei 2 imagens (atacante, vítima):
Vítima - baseado em Alpine, com curl instalado
Atacante - baseado em Ubuntu, com iputils-ping iproute2 curl iptables vim ettercap-text-only dsniff e tshark instalados.
Ambos estão em rede em ponte, então o roteador aqui seria a interface docker0 (padrão: 172.17.0.1).
Estou executando o contêiner do invasor com o sinalizador --privileged, para ativar o uso do ettercap.
Então, quando ambas as imagens estão sendo executadas, estou executando o ettercap (tentei também com a ferramenta arpspoof, mesmo efeito) do contêiner do invasor com:
ettercap -T -i eth0 -M arp:remote //victim_ip/ //172.17.0.1/
O tráfego da vítima está passando pelo invasor, mas há um problema: quando a vítima tenta fazer ping em google.com, não há resposta. O ataque MiTM está funcionando porque posso ver esse tráfego nos contêineres das vítimas, mas algo o está bloqueando.
Eu descobri qual é o problema aqui. Abri 2 wiresharks no meu host, um na interface docker0 e um na minha interface wifi padrão. Antes do ataque, quando estou executando ping em algo da rede global, o docker está traduzindo seu endereço IP do docker para o endereço IP do meu host e isso está funcionando bem, mas após o arpspoofing, não funciona corretamente - o host está enviando pacotes com fonte IP de contêiner da vítima do docker (172.17.0.3). Além disso, o estranho é que outro contêiner (atacante) está executando ping na rede externa sem problemas (o docker0 traduz o docker ip para o host ip corretamente). Foto de ambos os wiresharks, abaixo.
Verifiquei o iptables e esta regra (selecionada na imagem abaixo) está traduzindo meu endereço IP do docker para o endereço IP do host, mas após o ataque, esta regra não está funcionando (os pacotes não estão aumentando após o ataque de falsificação de arp). Tentei adicionar algumas regras extras de iptables, mas sem efeito. Não sou mestre em iptables, então se alguém tiver outras idéias sobre o que também deve verificar, me dê uma dica.
Talvez alguém possa me explicar ou me fornecer algumas fontes extras sobre como exatamente o docker está traduzindo seu endereço IP para o endereço IP do host na rede bridge e o que posso fazer para restaurar a tradução correta após um ataque de falsificação de arp. Cada conselho será apreciado.
Responder1
- Quando o Docker é instalado, uma interface de rede chamada
docker0
é criada para conectar cada contêiner. - Quando o Docker cria um contêiner, por padrão ele recebe uma interface de rede virtual com um nome começando com
veth
. Em seguida, o Docker encaminha o tráfego da interface de rede host para a interface de rede virtual por meio de regras de iptables. - Se você criar o contêiner com command
docker run --network=host ...
, fará com que o contêiner use a interface de rede do host. Neste ponto, o endereço IP do contêiner é igual ao do host.