Docker 컨테이너의 네트워크 액세스 제한


14

SFTP 전용 Docker 컨테이너 를 만드는 중입니다.이 컨테이너는 자체 chroot환경 에서 파일을 업로드하고 관리하기 위해 여러 사람이 사용합니다 .

문서 상으로는 매우 안전합니다. 모든 형태의 bash로그인을 비활성화하고 다른 프로세스를 실행하지 않습니다. 그러나 나는 조금 더 강화하고 싶습니다.

SFTP 서버의 목적을 제외 하고는이 컨테이너가 인터넷을 내부에서 액세스하지 못하게하고 싶습니다.

명확하게하기 위해 : 외부 세계가 내 컨테이너에 액세스하지 못하게하는 방법을 알고 있습니다. 들어오는 iptables규칙을 설정할 수 있으며 docker run 명령에 SFTP 포트 만 노출시킬 수 있습니다.

그러나 컨테이너 내부 에서 실행될 때 다음 명령 (예 :)이 실패하게하고 싶습니다 .

curl google.com

제 의도는 해킹 된 컨테이너가 할 수있는 피해량을 줄이는 것입니다 (스팸 이메일을 보내는 데 사용할 수 없음 등).


이러한 유형의 작업에 도움이되는 보류중인 기능 요청이 몇 가지 있습니다. # 6743 을 사용하면 컨테이너가 시작되기 전에 호스트에서 iptables 규칙을 미리 만들 수 있고 # 6982 를 사용하면 컨테이너가 시작될 때 iptables 규칙을 추가 할 수 있습니다.
— Patrick

Docker는 컨테이너의 네트워크 인터페이스를 완벽하게 제어합니다. Docker가 컨테이너를 네트워크로 연결하는 방법을 참조하십시오 . 예를 들어, --net=none플래그를 설정하면 docker run모든 외부 네트워크 어댑터가 비활성화되어 고유 한 네트워크 트래픽 규칙을 추가하고 사용자 지정할 수 있습니다.
— sffc

답변:


4

공격을 피하기 위해 도커 인스턴스 내에 일부 수신 규칙을 배치하는 것이 합리적이지만 도커 이미지가 연결된 업스트림 라우터의 아웃 바운드 (인터넷) 액세스를 제한해야합니다. 그 이유는 인스턴스 내부의 방화벽 규칙으로 아웃 바운드 액세스를 차단하려고하면 인스턴스가 손상되면 공격자가 해당 규칙을 제거 할 수 있기 때문입니다. 인스턴스의 라우터를 통한 발신을 차단하면 손상이 발생한 경우에도 아웃 바운드 액세스를 차단할 수 있습니다. 침입자는 라우터를 손상시켜야합니다.


필터링이 컨테이너의 호스트를위한 것이라는 설명을받은 후, 달성하려는 것이 조금 더 명확합니다. 이 경우 호스트에서 다음과 유사한 규칙을 추가합니다.

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

처음 두 규칙은 호스트와 컨테이너 간의 액세스를위한 것입니다. 세 번째 규칙은 (대략적으로) SFTP로 향하는 호스트의 서브넷이 아닌 것은 우리가 괜찮다고 말합니다. 네 번째는 기본적으로 두 번째에서 세 번째에 이르는 아웃 바운드 규칙입니다. 다섯 번째 규칙은 모든 것을 포괄하는 규칙이며 (사용되는 다른 관련 포트가있는 경우) 필요하지는 않지만 제거 할 수 있습니다. 마지막 규칙은 호스트 서브넷 이외의 다른 것에 대한 액세스를 방지하는 마법입니다. 처음 몇 규칙에는 액세스 권한이 부여되므로 앞의 규칙 중 어느 것도 적용되지 않는 한 트리거되지 않습니다. 여기에서 갈 수 없습니다 " 외부로부터의 인바운드 트래픽은 세 번째 및 네 번째 규칙에 따라 충족됩니다.


컨테이너의 내용을 절대적으로 신뢰하지 않고 컨테이너 내부 에서이 작업을 수행 할 수있는 방법이 없다는 점에서 흥미로운 downvote .
— 에이버리 페인

도커 컨테이너의 업스트림 라우터 (기본적으로 가장 많이 지원되는 구성이라고 가정)는 실행중인 호스트이며 다른 도커 기능을 중단하지 않고 해당 컨테이너 (컨테이너가 아닌) 에서 단일 컨테이너의 인터넷 액세스 를 비활성화하는 방법을 찾고 있습니다 .
— Tarnay Kálmán

(한숨) 나는 단지 6 시간의 수면 중에 답변을 다시 쓰지 말아야합니다. 주어진 답변을 수정했습니다.
— Avery Payne

Docker (기본적으로 가장 많이 지원되는 구성이라고 가정)는 사용자 공간 tcp 프록시를 통해 호스트의 컨테이너 포트를 게시하므로 전달 체인이 sftp 서비스와 관련된 규칙과 관련이 있는지 확실하지 않습니다.
— Tarnay Kálmán

테스트 환경을 설정하고 Docker를 끌어 내고 관련 내용을 확인해야한다고 생각합니다. 규칙을 앞뒤로 이동해야한다고 제안하는 것 같습니다.
— Avery Payne

1

이것은 실제로 도커 특정 문제가 아닙니다. 이 문제를 해결할 수있는 몇 가지 방법이 있습니다.

  1. 상태 저장 iptables규칙을 사용하여 인바운드 및 관련 / 설정된 트래픽 연결을 허용 한 다음 다른 모든 것을 차단하십시오.

  2. 쉘을 실행할 수없는 ProFTPD 와 같은 sftp 전용 서비스를 사용하십시오 .

일반적으로 사용자가 쉘을 얻지 못하게하고 컨테이너 내에서 프로그램을 실행하지 못하게하는 경우 걱정할 필요가 없습니다.


1.) Docker는 기본적으로 몇 가지 규칙을 자체적으로 설정하며 규칙을 추가하면 이미 catch-allish 규칙이 ​​있으므로 아무 것도 수행하지 않으며주의하지 않으면 기존 기능 (예 : 링크)을 중단하면 그렇게 사소한 것이 아닙니다. 2) 질문에 대답하지 않습니다. 그리고 OP는 이미 그렇게 설정했습니다. 또한 내 유스 케이스가 다릅니다.
— Tarnay Kálmán

0

이것은 단지 빠른 브레인 스토밍이며 아직 테스트하지 않았습니다. 프로덕션 환경으로 가져 가기 전에 실험실에서 검사해야합니다.

비 SSH (SFTP) 및 웹 포트에서 아웃 바운드 트래픽을 방지하기 위해 IPTABLES 또는 다른 Layer4 방화벽을 통해 0.0.0.0/0으로 향하는 도커 컨테이너가 사용하는 세그먼트에서 트래픽을 DROP 또는 REJECT 트래픽에 적용 할 수 있습니다. 포트는 TCP22입니다.

웹에서 승인되지 않은 위치로 이동하는 문제를 해결하려면 인터페이스 docker0에서 수신 대기 중이고 사용중인 오징어 또는 블루 코트와 같은 필터링 / 캐싱 프록시 인스턴스를 설정하려고 할 수 있습니다. 인터넷에 나가기위한 호스트의 확실한 경로. 여기에서 여러 가지 기준에 따라 정책을 적용 할 수있을뿐만 아니라 정적 콘텐츠를 캐싱하여 네트워크 사용률을 절약 할 수 있습니다. 프록시를 투명하게 사용하기 위해 호스트 컴퓨터에서 NAT (IPTABLES 및 Masquerade가 Linux에서 이것을 제공한다고 생각합니다)를 사용하고 싶을 수도 있습니다 ( HTTP 만 프록시하고 싶다는 응답으로 이것을 설명 했지만 어떻게 해야할지 모르겠습니다. HTTPS 트래픽으로 수행 ). 이것은 회사의 정책을 준수하는 웹에 먼저 갈 이유가 있음을 의미합니다.

SFTP의 기반이되는 SSH의 특성으로 인해 컨테이너가 사용자가 제공 한 키 쌍만 사용할 수있는 정책을 구현하지 않으면 파일 이동을위한 트래픽 차단을 제공 할 수 없습니다. " 전송 된 파일에 대한 가시성이나 제어권이 없었습니다. ""고객 중 한 명이 불법적 인 물건 (IP 침해 등의 정보를 전송하거나 분류 레이블이있는 정보를 유출하기 위해 서비스를 사용하거나 CP에서 거래하는 경우)을 변호하는 경우 고객이하는 일에 대해 법정에 출두 할 경우 자주 전송되는 변경되지 않은 파일을 캐시 할 수없고 고객과의 계약서에 작성하는 정책은 본질적으로 기술적 인 수단을 통해 시행 할 수 없기 때문에 이는 좋지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.