Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

prosource

Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

probook 2023. 10. 15. 17:29

Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

방금 도커를 시험해 봤어요.그것은 굉장하지만 ufw와는 잘 작동하지 않는 것 같습니다.기본적으로 도커는 ipt 테이블을 약간 조작합니다.결과는 버그는 아니지만 제가 기대했던 결과는 아닙니다.자세한 내용은 UFW의 위험 + 도커를 읽어보실 수 있습니다.

제 목표는 다음과 같은 시스템을 구축하는 것입니다.

    Host (running ufw) -> docker container 1 - nginx (as a reverse proxy)
                       -> docker container 2 - node web 1
                       -> docker container 3 - node web 2
                       -> .......

나는 ufw를 통해 들어오는 트래픽을 관리하고 싶기 때문에 도커가 내 iptables를 터치하는 것을 원하지 않습니다.여기 제 시험이 있습니다.

환경:

새로 설치된 Ubuntu 14.04 (커널: 3.13.0-53)
도커 1.6.2
ufw 전달이 활성화됩니다. ( [UFW 전달 활성화] 2 )
--iptables=false도커 데몬에 추가되었습니다.

첫번째 시도

docker run --name ghost -v /home/xxxx/ghost_content:/var/lib/ghost -d ghost
docker run --name nginx -p 80:80 -v /home/xxxx/nginx_site_enable:/etc/nginx/conf.d:ro --link ghost:ghost -d nginx

운이 없습니다.첫번째 명령은 문제없지만 두번째 명령은 오류를 던집니다.

Error response from daemon: Cannot start container

세컨드 시도

그런 다음, --iptable= false #12701과 컨테이너를 연결할 수 없습니다.

다음 명령을 실행하면 모든 것이 정상으로 보입니다.

sudo iptables -N DOCKER

하지만 컨테이너 내부에서 아웃바운드 연결을 설정할 수 없다는 것을 알게 되었습니다.예를 들어,

xxxxg@ubuntu:~$ sudo docker exec -t -i nginx /bin/bash
root@b0d33f22d3f4:/# ping 74.125.21.147
PING 74.125.21.147 (74.125.21.147): 56 data bytes
^C--- 74.125.21.147 ping statistics ---
35 packets transmitted, 0 packets received, 100% packet loss
root@b0d33f22d3f4:/#

하면.--iptables=false도커 데몬에서 컨테이너의 인터넷 연결은 정상으로 돌아가지만 ufw는 '제대로' 작동하지 않습니다(음...내 정의에 의하면).

그렇다면 도커 + ufw의 최선의 방법은 무엇입니까?누가 좀 도와줄 수 있습니까?

문제

이 문제는 오래전부터 있어 왔습니다.

도커에서 iptables를 비활성화하면 다른 문제가 발생합니다.

먼저 롤백이 변경됨

당사가 인터넷에서 발견한 현재 솔루션에 따라 서버를 수정한 경우 다음과 같은 변경 사항을 먼저 롤백하십시오.

도커의 iptables 기능을 활성화합니다.과 같은 모든 --iptables=false을 포함하여 ,,/etc/docker/daemon.json.
UFW 의 FORWARD 로 .DROPACCEPT.
합니다./etc/ufw/after.rules.
도커 구성 파일을 수정한 경우 먼저 도커를 다시 시작합니다.UFW 구성은 추후 수정할 예정이며, 그때 다시 시작하면 됩니다.

UFW 및 도커 문제 해결

이 솔루션은 UFW 구성 파일 하나만 수정하면 되며, 모든 도커 구성 및 옵션은 기본값으로 유지됩니다.도커티블 기능을 비활성화할 필요가 없습니다.

UFW를 합니다./etc/ufw/after.rules파일 끝에 다음 규칙을 추가합니다.

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

하기 sudo systemctl restart ufw파일을 변경한 후 UFW를 다시 시작합니다.이제 퍼블릭 네트워크는 공개된 도커 포트에 액세스할 수 없으며 컨테이너와 프라이빗 네트워크는 정기적으로 서로 방문할 수 있으며 컨테이너는 내부에서 외부 네트워크에 액세스할 수도 있습니다.

가 제공하는 서비스에 수 가 , 가 Docker입니다80에서 이 서비스에 수 공용 네트워크가 이 서비스에 액세스할 수 있도록 다음 명령을 실행합니다.

ufw route allow proto tcp from any to any port 80

이 명령을 사용하면 공용 네트워크는 컨테이너 포트가 80인 모든 게시된 포트에 액세스할 수 있습니다.

:-p 8080:80, 를 .80, 8080.

서비스 포트가 80인 컨테이너가 여러 개 있지만 외부 네트워크가 특정 컨테이너에만 액세스하기를 원하는 경우.예를 들어 컨테이너의 개인 주소가 172.17.0.2인 경우 다음 명령을 사용합니다.

ufw route allow proto tcp from any to 172.17.0.2 port 80

네트워크 서비스 프로토콜(예: DNS 서비스)이 UDP인 경우 다음 명령을 사용하여 외부 네트워크가 게시된 모든 DNS 서비스에 액세스할 수 있도록 허용할 수 있습니다.

ufw route allow proto udp from any to any port 53

마찬가지로, IP 주소 172.17.0.2와 같은 특정 컨테이너에 대해서만:

ufw route allow proto udp from any to 172.17.0.2 port 53

어떻게 돼가요?

다음 규칙을 통해 전용 네트워크가 서로 방문할 수 있습니다.일반적으로 공중망보다 사설망이 더 신뢰를 받습니다.

-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

다음 규칙을 통해 UFW는 공용 네트워크가 도커 컨테이너에서 제공하는 서비스를 방문할 수 있는지 여부를 관리할 수 있습니다.그래서 모든 방화벽 규칙을 한 곳에서 관리할 수 있습니다.

-A DOCKER-USER -j ufw-user-forward

다음 규칙은 모든 공용 네트워크가 시작한 연결 요청을 차단하지만 내부 네트워크가 외부 네트워크에 액세스할 수 있도록 허용합니다.TCP 프로토콜의 경우 공중망에서 TCP 연결을 능동적으로 설정하지 못하도록 합니다.UDP 프로토콜의 경우 32767 미만의 포트에 대한 모든 액세스가 차단됩니다.여기가 왜 항구입니까?UDP 프로토콜은 상태 비저장이므로 TCP처럼 연결 요청을 시작하는 핸드셰이크 신호를 차단할 수 없습니다. GNU/리눅스다 수 ./proc/sys/net/ipv4/ip_local_port_range. 기본 범위는 다음과 같습니다.32768 60999 중인 때를 이 실행 중인 컨테이너에서 UDP 프로토콜 서비스에 액세스할 때, 로컬 포트는 포트 범위에서 임의로 선택되고, 서버는 이 임의 포트로 데이터를 반환합니다.따라서, 우리는 모든 컨테이너 내부의 UDP 프로토콜의 수신 포트가 32768보다 작다고 가정할 수 있습니다.이것이 32768 미만의 UDP 포트에 퍼블릭 네트워크가 액세스하지 않기를 원하는 이유입니다.

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN

더

https://github.com/chaifeng/ufw-docker

sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
chmod +x /usr/local/bin/ufw-docker

사용.

ufw-docker help
ufw-docker install
ufw-docker status
ufw-docker allow webapp
ufw-docker allow webapp 80
ufw-docker allow webapp 53/udp
ufw-docker list webapp
ufw-docker delete allow webapp 80/tcp
ufw-docker delete allow webapp

업데이트 : 2018-09-10

한 이유`ufw-user-forward`,것은 아니다.`ufw-user-input`

`ufw-user-input`

프로:

사용과 이해가 쉽고, 이전 버전의 Ubuntu를 지원합니다.

를 들어, 포트가 할 수 허용합니다.8080, 다음 명령을 사용합니다.

ufw allow 8080

반대:

컨테이너의 포트뿐만 아니라 호스트의 포트도 노출합니다.

를 들어 중이고과 같은8080이..ufw allow 8080에서는 공용 및 다인 할 수 .8080인 서비스나에서 실행 중인 뿐 둘 그러나 호스트에서 실행 중인 서비스나 컨테이너 내부에서 실행 중인 서비스를 모두 노출하는 것은 아닙니다.

이러한 문제를 방지하기 위해 모든 컨테이너에 대해 다음과 유사한 명령을 사용해야 할 수도 있습니다.

ufw allow proto tcp from any to 172.16.0.3 port 8080

`ufw-user-forward`

프로:

동일한 명령으로 호스트와 컨테이너에서 동시에 실행되는 서비스를 노출할 수 없습니다.

를 들어,하려면 다음과 같이 하십시오.8080컨테이너의 경우 다음 명령을 사용합니다.

ufw route allow 8080

가 인 수 .8080.

는 8080호스트가 여전히 공용 네트워크에 액세스할 수 없습니다.이렇게 하려면 다음 명령을 실행하여 일반인이 호스트의 포트에 별도로 액세스할 수 있도록 합니다.

ufw allow 8080

반대:

이전 버전의 Ubuntu를 지원하지 않으며 명령이 조금 더 복잡합니다.하지만 당신은 https://github.com/chaifeng/ufw-docker 을 사용할 수 있습니다.

결론

의 Ubuntu 를를 할 수 .ufw-user-input체인. 그러나 노출되지 않아야 할 서비스가 노출되지 않도록 주의해야 합니다.

하는 Ubuntu를 ufw route다를 게 .ufw-user-forward슬 사용, 합니다.ufw route컨테이너의 방화벽 규칙을 관리하는 명령입니다.

업데이트: 2018년 10월 6일

스크립트 ufw-docker는 이제 도커 스웜을 지원합니다.자세한 내용은 최신 코드를 참조하시기 바랍니다. https://github.com/chaifeng/ufw-docker

Install for Docker Swarm mode

이 스크립트는 스웜 모드에서 사용할 때 관리자 노드에서만 방화벽 규칙을 관리할 수 있습니다.

after.rules 및
관리자 노드에 이 스크립트 배포

스웜() 이 는 글로벌 서비스 합니다를 합니다.ufw-docker-agent. 이미지 chaifeng/ufw-docker-agent도 이 프로젝트에서 자동으로 빌드됩니다.

몇 달 전부터 그런 문제가 있었는데 최근에 블로그에 해결책과 함께 그 문제를 설명하기로 했습니다.지름길은 여기 있습니다.

으로.--iptables=false당신이 설명한 사건에 큰 도움이 되지 않을 겁니다여기서는 도저히 충분하지 않습니다.기본적으로 어떤 컨테이너도 나가는 연결을 할 수 없습니다.

여기 UFW 뒤에 컨테이너를 두는 과정에서 누락된 작은 단계가 있습니다.합니다.--iptables=false아니면 만들기/etc/docker/daemon.json다음과 같은 내용으로 파일을 작성합니다.

{
  "iptables": false
}

에서는 , 를 시작해야 .service docker restart또는 도커가 이 기능을 사용하지 않도록 설정하기 전에 iptables 규칙을 추가할 기회가 있는 경우 재부팅할 수도 있습니다.

작업이 완료되면 두 가지만 더 수행합니다.

$ sed -i -e 's/DEFAULT_FORWARD_POLICY="DROP"/DEFAULT_FORWARD_POLICY="ACCEPT"/g' /etc/default/ufw
$ ufw reload

UFW에서 기본 전달 정책을 설정하여 다음을 사용합니다.

$ iptables -t nat -A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE

이렇게 하면 iptables 규칙에서 도커의 지저분한 동작을 비활성화할 수 있으며 동시에 도커에 필요한 라우팅이 제공되어 컨테이너가 발신 연결을 정상적으로 수행할 수 있습니다.그러나 UFW 규칙은 지금부터 여전히 제한될 것입니다.

이를 통해 문제가 해결되기를 바라며 여기에 답을 찾는 모든 사람들이 해결되기를 바랍니다.

https://www.mkubaczyk.com/2017/09/05/force-docker-not-bypass-ufw-rules-ubuntu-16-04/ 에서 문제와 해결책에 대해 보다 포괄적으로 설명했습니다.

여기서 해결책이 잘못되었다고 말하는 것은 아니지만, 한 단계 빠른 지침을 찾고 있는 사람에게는 조금 "끔찍한" 오류를 범하는 것처럼 보입니다.저도 최근에 이 문제를 가지고 왔고, 온라인에서 비슷한 답변을 모두 읽었으며, 글을 쓰는 시점에서 빠르고 명확한 것을 발견하지 못했습니다.놀랍게도, 제 대안 솔루션은 이해하고 관리하기 쉬우며, 효과가 있습니다. 호스트 시스템 외부에 방화벽을 구현하기만 하면 됩니다.

Digital Ocean에는 추가 비용 없이 WYSIWYG 스타일의 멋진 방화벽이 있습니다.
보안 그룹을 제공하는 AWS
기타.

방화벽을 일류 시민으로 취급하는 것은 많은 이점이 있는 것 같습니다.

위의 제안과 다른 게시물들을 두 시간 동안 시도했습니다.유일한 해결책은 Tsuna가 이 Github 스레드에 올린 글에서 나온 것입니다.

합니다 끝에 합니다./etc/ufw/after.rules(외부 대면 인터페이스로 eth0 대체):
# Put Docker behind UFW
*filter
:DOCKER-USER - [0:0]
:ufw-user-input - [0:0]

-A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A DOCKER-USER -m conntrack --ctstate INVALID -j DROP
-A DOCKER-USER -i eth0 -j ufw-user-input
-A DOCKER-USER -i eth0 -j DROP
COMMIT
그리고 다음을 모두 실행 취소합니다.

/etc/docker/daemon.json에서 "iptables": "false" 제거

/etc/default/ufw에서 DEFAULT_FORWARD_POLICY="DROP"로 복구

/etc/ufw/before. 규칙에 대한 도커 관련 변경 사항을 모두 제거합니다.

재부팅 후에는 모든 것이 정상적으로 작동하는지 테스트해야 합니다.저는 여전히 도커의 행동이 위험하다고 생각하며, 그렇지 않으면 안전한 iptable 구성에 구멍을 뚫는 도커로 인해 더 많은 사람들이 의도치 않게 내부 서비스를 외부에 계속 노출시킬 것입니다.

면책 사항: 이 응답은 ufw(예: Ubuntu)에 적용됩니다. 기본/표준 도커 브리지 네트워크가 172.17.0.0/16에서 작동합니다(참조).docker inspect bridge 가장 할 일:넷),한 IMHO다.

ufw allow from 172.17.0.0/16

@mkubaczyk의 게시물을 요약하면 다음과 같습니다.

도커에게 내 방화벽에서 떨어져 있으라고 말합니다.

cat << EOF >> /etc/docker/daemon.json
{
     "iptables": false
}
EOF

echo "DOCKER_OPTS=\"--iptables=false\"" >>  /etc/default/docker
service docker restart

순방향 정책을 변경

sed -i -e 's/DEFAULT_FORWARD_POLICY="DROP"/DEFAULT_FORWARD_POLICY="ACCEPT"/g' /etc/default/ufw

컨테이너 대상으로 nat 규칙 추가

cat << EOF >> /etc/ufw/before.rules
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0 - Change to match your out-interface
-A POSTROUTING -s 10.66.66.0/24 -o ens0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT

EOF
ufw reload

전체 설정에 더 많은 브리지 네트워크가 관련된 경우에 대한 @mkubaczyk의 답변에 부록을 제공합니다.이것들은 Docker-Compose 프로젝트에 의해 제공될 수 있으며, 이 프로젝트들이 다음에 의해 제어된다는 것을 고려할 때, 적절한 규칙을 생성하는 방법은 다음과 같습니다.systemd.

/etc/systemd/system/compose-project@.service

[Unit]
Description=Docker-Compose project: %I
After=docker.service
BindsTo=docker.service
AssertPathIsDirectory=/<projects_path>/%I
AssertFileNotEmpty=/<projects_path>/%I/docker-compose.yml

[Service]
Type=simple
Restart=always
WorkingDirectory=/<projects_path>/%I
ExecStartPre=/usr/bin/docker-compose up --no-start --remove-orphans
ExecStartPre=+/usr/local/bin/update-iptables-for-docker-bridges
ExecStart=/usr/bin/docker-compose up
ExecStop=/usr/bin/docker-compose stop --timeout 30
TimeoutStopSec=30
User=<…>
StandardOutput=null

[Install]
WantedBy=multi-user.target

/usr/local/bin/update-iptables-for-docker-bridges

#!/bin/sh

for network in $(docker network ls --filter 'driver=bridge' --quiet); do
  iface=$(docker network inspect --format '{{index .Options "com.docker.network.bridge.name"}}' ${network})
  [ -z $iface ] && iface="br-${network}"
  subnet=$(docker network inspect --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' ${network})
  rule="! --out-interface ${iface} --source ${subnet} --jump MASQUERADE"
  iptables --table nat --check POSTROUTING ${rule} || iptables --table nat --append POSTROUTING ${rule}
done

분명히, 이것은 그렇게 잘 확장되지 않을 것입니다.

컨테이너에서 실행 중인 응용 프로그램에 대한 연결 소스를 전체 기본 개념이 위장한다는 점도 주목할 만합니다.

도커 데몬의 false flag라는 iptables에서 요구하는 운영 오버헤드가 마음에 들지 않습니다.사실, 제가 보기에 제가 틀리면 고쳐주세요. 모든 해결책은 너무 복잡한 해킹입니다.

*filter 섹션 앞에 /etc/ufw/after.rules에 삽입하면 됩니다.

*mangle
# Allow a whitelisted ip to access postgres port
-I PREROUTING 1 -s <whitelisted_ip> -p tcp --dport 5432 -j ACCEPT
# Allow everyone to access port 8080
-I PREROUTING 2 -p tcp --dport 8080 -j ACCEPT
# Drop everything else
-I PREROUTING 3 -p tcp -j DROP
COMMIT

도커 네트워킹이나 불필요한 해킹을 할 필요가 없습니다.

이 오래된 실을 파서 미안합니다.나도 같은 문제가 있었고 단지 ufw를 특정 ip와 인터페이스로 제한하는 것에 도움이 되었습니다.기본적으로 ufw는 도커의 내부 인터페이스와 모든 네트워크 인터페이스에 적용되기 때문입니다.그래서 이 멋진 도커 포트 포워딩 스토리(예: -p80:8080)가 작동하지 않습니다.이 문제를 해결하기 위해 특정 인터페이스와 적용해야 할 ufw에 대한 ip를 지정하면 됩니다.제 경우에는 서버에서 세상에 노출되는 것이었습니다.

ufw allow in on eth0 to ip_of_eth0 port 22 proto tcp
ufw allow in on eth0 to ip_of_eth0 port 80 proto tcp
ufw allow in on eth0 to ip_of_eth0 port 443 proto tcp

eth0를 원하는 인터페이스로 변경합니다.

이 솔루션을 사용하면 iptables 또는 iptables:false in /etc/docker/daemon.json 플래그를 사용하여 실제로 필요한 포트만 표시할 수 있습니다.

외부 컴퓨터에서 nmap 출력:

Starting Nmap 7.91 ( https://nmap.org ) at <time>
Nmap scan report for <domain> (ip)
Host is up (0.042s latency).
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 11.44 seconds

저도 이런 문제가 있었습니다.저 같은 경우에는 도커0 인터페이스 전체에 대해 ufw 방화벽을 열기로 했습니다.

sudo ufw allow in docker0

또는 서브넷 도커 사용을 허용할 수도 있습니다.예:

sudo ufw allow from 172.0.0.0/8

두 가지 규칙 모두 제게 효과가 있었습니다.

저도 비슷한 경우가 있었습니다.

제가 해결한 방법은 맞춤형 네트워크를 만들어 외부로 정의하는 것입니다.

docker network create my_app_net

# put this in all the project related containers' docker compose files.
networks:
      - my_app_net

networks:
  my_app_net:
    external: true

그런 다음 (도커 구성에서) 정의한 호스트 이름을 통해 컨테이너에 연결할 수 있었습니다.

호스트 이름:"my_app_db" 컨테이너_name: "my_app_db"

그리고 컨테이너 중 하나에서 db 서버로 연결할 수 있었습니다.또한 서버가 모든 IP(예: 0.0.0.0)에 바인딩되는지 확인했습니다(이에 대해 사용자 지정 my.cnf 파일을 사용하고 있습니다). mysql -uUSER -pPASS -hDOCKER_HOST --port 3306 --protocol=tcp DB_NAME

mysql 사용자를 생성할 때 user@localhost가 아닌 %를 db host로 지정하여 모든 호스트에서 연결할 수 있도록 하는 것도 중요한 세부 사항입니다.

UFW는 꽤 간단하며 내가 강요받지 않는다면 ipt 테이블에 뛰어들고 싶지 않습니다.또한 iptables/ufw에 대한 도커의 행동은 문서화가 충분하지 않지만 저에게는 괜찮아 보입니다.컨테이너를 시작할 때 노출된 포트에서 무슨 일이 일어나고 있는지 정확히 파악해야 한다고 생각합니다.에.docker ps명령어는 무슨 일이 일어나고 있는지에 대한 좋은 피드백을 제공합니다.

MariaDb 컨테이너를 실행합니다.

$ docker run --detach --env MARIADB_ROOT_PASSWORD="superSecret" mariadb:10.4

$ docker ps --format "table {{.Names}}\t{{.Ports}}"
NAMES           PORTS
happy_jackson   3306/tcp

에는 서 PORTs 됩니다가 됩니다.3306/tcp: 포트 3306은 잠재적으로 사용 가능하지만 실제로는 게시되지 않았습니다. 즉, 3306 포트는 호스트나 호스트 네트워크에서 액세스할 수 없습니다.

다른 MariaDb 컨테이너를 실행해 보겠습니다.

$ docker run --detach --env MARIADB_ROOT_PASSWORD="superSecret" -p 3306:3306 mariadb:10.4

$ docker ps --format "table {{.Names}}\t{{.Ports}}"
NAMES              PORTS
trusting_goodall   0.0.0.0:3306->3306/tcp

에 PORTs 됩니다가 됩니다.0.0.0.0:3306->3306/tcp: port가 게시됨으로써 포트를 호스트 및 호스트 네트워크에서 사용할 수 있습니다.

마지막 MariaDb 컨테이너를 실행합니다.

$ docker run --detach --env MARIADB_ROOT_PASSWORD="superSecret" -p 127.0.0.1:3306:3306 mariadb:10.4

$ docker ps --format "table {{.Names}}\t{{.Ports}}"
NAMES             PORTS
quizzical_gauss   127.0.0.1:3306->3306/tcp

에 PORTs 됩니다가 됩니다.127.0.0.1:3306->3306/tcp: 포트 3306은 로컬에서 게시되므로 호스트 네트워크가 아닌 호스트에서만 사용할 수 있습니다.

예, 도커는 UFW를 조정해야 하지만, 이는 포트를 로컬 또는 네트워크에 노출하는 것과 같은 요청 사항을 달성하기 위한 것입니다.따라서 포트 퍼블리싱에 대해 무엇을 하고 있는지 아는 한 안전해야 합니다.

또한 저는 네트워크 보안 전문가는 아니지만 서버에서 전체 포트 검색을 몇 번 해본 것이 저를 안심시켰습니다. 결과는 예상했던 것과 일치합니다.

응용 프로그램에서 네트워크 분리가 크게 중요하지 않은 경우 호스트 네트워크에 컨테이너를 연결하도록 선택할 수도 있습니다.

참조:

https://docs.docker.com/network/host/

도커 내에서 실행 중인 앱에 액세스할 수 있는 사용자에 대한 통제력을 향상시키시겠습니까?IP 테이블이 아닌 프론트 엔드 프록시를 통해 트래픽을 제어하기 위한 유사한 질문에 답했습니다.도커 컨테이너 외부 접근 차단

편집

위의 접근 방식을 사용하면 UFW를 사용하여 포트 80(즉, 프록시)에 대한 수신 연결만 허용할 수 있습니다.이렇게 하면 프록시 구성 및 DNS를 통해 트래픽을 제어할 수 있는 추가 보너스와 함께 포트 노출을 최소화할 수 있습니다.

Ubuntu 22.04에서는 체인의 이름이 변경됩니다./etc/ufw/after.rules 파일에 추가했습니다.

-A ufw-after-forward -j ACCEPT -s 172.16.0.0/12

커밋전에

이것은 저에게 효과가 있었습니다: (또한 https://docs.docker.com/network/iptables/) 를 참조하십시오.

sudo iptables -I DOCKER-USER -i eth0 ! -s 10.56.122.0/24 -j DROP

특히 10.56.122.0에서 트래픽을 제외한 모든 트래픽을 삭제하는 규칙을 추가합니다. 이 규칙은 제 경우에는 컴퓨터 간의 사설 네트워크였습니다.

결과: 공용 트래픽이 통과할 수 없으며 로컬 네트워크의 트래픽이 통과할 수 있습니다.

언급URL : https://stackoverflow.com/questions/30383845/what-is-the-best-practice-of-docker-ufw-under-ubuntu

'prosource' 카테고리의 다른 글

Powershell에서 사용자 지정 개체 배열을 문자열 배열로 변환 (0)	2023.10.20
다른 디브에 디브 센터를 지정하려면 어떻게 해야 합니까? (0)	2023.10.20
Woocommerce에서 Ajax Overlay Spinner 시작 및 중지 (0)	2023.10.15
C:\wamp\apps\phpmyadmin4.1.14에서 최대 실행 시간 360초를 초과했습니다. (0)	2023.10.15
SSL 오류: npm 명령을 사용하는 동안 CERT_UNTRUSTED (0)	2023.10.15

현재글Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

각종 프로그래밍 정보를 다루는 블로그입니다.

C, spring-boot, Python, jQuery, TypeScript, reactjs, JSON, GIT, Excel, MySQL, oracle, MongoDB, sql-server, WPF, Ajax, WordPress, AngularJS, mariaDB, ASP.NET, PowerShell,

Today :
Yesterday :

probook

Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

문제

먼저 롤백이 변경됨

UFW 및 도커 문제 해결

어떻게 돼가요?

더

사용.

업데이트 : 2018-09-10

한 이유`ufw-user-forward`,것은 아니다.`ufw-user-input`

`ufw-user-input`

`ufw-user-forward`

결론

업데이트: 2018년 10월 6일

도커에게 내 방화벽에서 떨어져 있으라고 말합니다.

순방향 정책을 변경

컨테이너 대상으로 nat 규칙 추가

편집

'prosource' 카테고리의 다른 글

'prosource'의 다른글

티스토리툴바

« 2024/09 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

Ubuntu에서 도커 + ufw의 모범 사례는 무엇입니까?

문제

먼저 롤백이 변경됨

UFW 및 도커 문제 해결

어떻게 돼가요?

더

사용.

업데이트 : 2018-09-10

한 이유ufw-user-forward,것은 아니다.ufw-user-input

ufw-user-input

ufw-user-forward

결론

업데이트: 2018년 10월 6일

도커에게 내 방화벽에서 떨어져 있으라고 말합니다.

순방향 정책을 변경

컨테이너 대상으로 nat 규칙 추가

편집

'prosource' 카테고리의 다른 글

'prosource'의 다른글

관련글

티스토리툴바

한 이유`ufw-user-forward`,것은 아니다.`ufw-user-input`

`ufw-user-input`

`ufw-user-forward`