
MiTM 攻撃の実験を行うためのラボ環境を作成しようとしています。docker も学習したいので、docker でこれを行うことにしました。2 つのイメージ (攻撃者、被害者) を作成しました。
被害者 - Alpine ベース、curl インストール済み
攻撃者 - Ubuntu ベース、iputils-ping、iproute2、curl、iptables、vim、ettercap-text-only、dsniff、tshark インストール済み。
どちらもブリッジ ネットワーク内にあるため、ここでのルーターは docker0 インターフェイス (デフォルト: 172.17.0.1) になります
。ettercap の使用を有効にするために、--privileged フラグを使用して攻撃者コンテナーを実行しています。
したがって、両方のイメージが実行されているときに、攻撃者のコンテナから ettercap を実行します (arpspoof ツールも試しましたが、同じ効果がありました)。
ettercap -T -i eth0 -M arp:remote //victim_ip/ //172.17.0.1/
被害者のトラフィックは攻撃者を通過していますが、被害者が google.com に ping しようとしても応答がないという問題があります。被害者のコンテナでこのトラフィックを確認できるものの、何かがそれをブロックしているため、MiTM 攻撃が機能しています。
ここで何が問題なのかわかりました。ホストで 2 つの Wireshark を開きました。1 つは docker0 インターフェース、もう 1 つはデフォルトの Wi-Fi インターフェースです。攻撃前は、グローバル ネットワークから何かを ping すると、docker は docker の IP アドレスをホストの IP アドレスに変換し、正常に動作していましたが、ARP スプーフィング後は正しく動作しなくなり、ホストは docker の被害者コンテナー (172.17.0.3) の IP ソースでパケットを送信しています。また、奇妙なことに、別のコンテナー (攻撃者) は問題なく外部ネットワークに ping しています (docker0 は docker の IP をホストの IP に正しく変換します)。以下は両方の Wireshark の画像です。
iptables をチェックしたところ、このルール (下の図で選択) は docker の IP アドレスをホストの IP アドレスに変換していますが、攻撃後、このルールは機能していません (ARP スプーフィング攻撃後、パケットが増加しません)。iptables ルールをいくつか追加してみましたが、効果はありませんでした。私は iptables の達人ではないので、他に何を確認すべきかアイデアがあれば、ヒントをください。
おそらく、docker がブリッジ ネットワーク上で IP アドレスをホスト IP アドレスに変換する方法と、ARP スプーフィング攻撃後に正しい変換を復元するために何ができるかについて、誰か私に説明したり、追加のソースを提供したりできるでしょう。どんなアドバイスでも歓迎します。
答え1
docker0
Docker をインストールすると、各コンテナを接続するために という名前のネットワーク インターフェイスが作成されます。- Docker がコンテナを作成すると、デフォルトで で始まる名前の仮想ネットワーク インターフェイスが与えられます
veth
。次に、Docker は iptables ルールを通じてホスト ネットワーク インターフェイスのトラフィックを仮想ネットワーク インターフェイスに転送します。 - コマンドを使用してコンテナを作成すると
docker run --network=host ...
、コンテナはホストのネットワーク インターフェイスを使用するようになります。この時点では、コンテナの IP アドレスはホストと同じになります。