私はdockerが私のiptables / nftablesを動的に変更したくないので、iptables = falseを使用することにしました。それから提案に従った。ここコンテナ内でアウトバウンドインターネット接続を有効にします。
しかし、コンテナ間通信やブリッジ間通信を防止するための基本的な規則がないことをすぐに知りました。これはセキュリティのための幻想を作成します。信頼できないゾーンにある破損したコンテナは、単に信頼できるゾーンにある信頼できるコンテナを自分のホストに入れるためのジャンプとして使用できます。
たとえば、br1、br2、br3があります。 br1とbr2はzone1（完全デフォルト）、br3は完全デフォルトのzone2にあります。
zone1
target: default
icmp-block-inversion: no
interfaces: br1 br2
sources:
services: ssh
ports:
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
zone2
target: default
icmp-block-inversion: no
interfaces: br3
sources:
services: ssh
ports:
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
少なくともbr3はbr1 / br2への接続を開始できないと予想されます。だからnc -lk -p 12345 -e /usr/bin/catbr1でした。その後、NC通信を試みます。驚くべきことに、目詰まりはまったくありません。ポートが正常に開き、メッセージが送信されます。
なぜそんなことですか？私はそれがコンテナ3--> | br3 -->ホストのポートだと思ったので、sshを除くすべては基本的にここでブロックされます。
それでは、コンテナ1に正確にどのように接続しますか？たぶんコンテナ3--> | br3 --> br1|--> コンテナ 1
コンテナ3とコンテナ1が物理マシンで、br3とbr1が物理インターフェイスの場合。実際にトラフィックを許可するには、いくつかの転送ルールまたはクロスドメインポリシーを設定する必要があるようです。さらに、少なくともコンテナ3--> | br3はブロックする必要があるので、転送ルールが設定されていてもbr3にポートを開かないと、相手に連絡できないのでしょうか？
しかし、コンテナ/橋の場合はそうではありません。目詰まりはまったくありません。
1.コンテナが通信のために他のゾーンのブリッジに接続するのを防ぐための標準的な方法は何ですか？ 2. 同じゾーン内のコンテナ間の接続を防止します。
これは完全にファイアウォールの概念を超えていますか？それでは、生のnft呼び出しまたはiptables-nft呼び出しを介してのみ達成できますか？直接的なルールはnftのBear Callとほぼ同じです。これは、各ゾーンまたはゾーン間の使用に関する概念がないためです。
いいですね。これはおそらくbr_netfilterがロードされておらず、正しい隔離ルールが挿入されていないためです。これが思ったより複雑なようです。ファイアウォールが答えではない可能性があります