나는 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가 로드되지 않고 올바른 격리 규칙을 삽입하지 않았기 때문일 것입니다. 이게 생각보다 복잡한 것 같아요. 방화벽이 답이 아닐 수도 있습니다