网络安全运维【免费下载链接】ufw-dockerTo fix the Docker and UFW security flaw without disabling iptables项目地址https://gitcode.com/gh_mirrors/uf/ufw-docker点击查看免费下载本篇技术指南围绕 ufw-docker 项目仓库根目录 README.md的完整解决方案展开在不关闭 Docker iptables 的前提下通过在 UFW 配置文件中追加一组DOCKER-USER链规则让 UFW 重新掌控 Docker 发布端口的进出流量并配合ufw route allow命令实现按容器、按端口、按协议精细放行。读完本文你将掌握漏洞成因、回滚旧配置的步骤、核心 iptables 规则块的逐条语义、无 conntrack 的旧方案原理以及ufw-docker脚本的全部子命令含 Docker Swarm 模式与源码级实现依据。问题背景装了 Docker 之后UFW 形同虚设UFWUncomplicated Firewall是 Ubuntu 上非常流行的 iptables 前端可以很方便地管理防火墙规则。但当服务器安装了 Docker 之后UFW 便无法管理 Docker 发布出来的端口了。具体现象是在一个对外提供服务的服务器上启用了 UFW并且默认阻止所有未被允许的传入连接。运行一个 Docker 容器并使用-p选项把容器的某个端口发布到服务器的所有 IP 地址上。例如执行docker run -d --name httpd -p 0.0.0.0:8080:80 httpd:alpine会运行一个 httpd 服务并将容器的80端口发布到服务器的8080端口上。UFW 不会阻止所有对8080端口的访问请求即使执行ufw deny 8080也无法阻止外部访问这个端口。这个问题的严重性在于一个原本只打算在内部提供服务、供内网访问的端口实际上被暴露到了公共网络上。早在 Docker 早期版本这个问题就在 moby/moby 的 Issue #4737、Docker 官方论坛、Ask Ubuntu 等多个社区被反复讨论可以说这是 Docker 与 UFW 共存场景下最经典的安全隐患之一。根源Docker 直接接管 iptablesDocker 守护进程默认直接操作 iptables通过nat表完成端口发布 DNAT通过filter表的DOCKER链放行转发流量而 UFW 管理的规则位于INPUT、OUTPUT、FORWARD等链中两者互不感知。发往已发布端口的流量经 Docker 的 DNAT 规则重定向后走的是 FORWARD 路径UFW 对INPUT链的默认拒绝策略根本拦不到它——这正是UFW 失效的根本原因。网上常见方案为什么不可取网上能搜索到的解决方案大都殊途同归且都不优雅先禁用 Docker 的 iptables 功能如--iptablesfalse这等于放弃了 Docker 自身的网络管理功能典型副作用是容器无法访问外部网络。在 UFW 配置文件中手工添加 NAT 规则例如-A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE这只对172.17.0.0/16这一个网络有效。一旦新建了其他 Docker 网络就必须手工为每个新网络再添加类似的 iptables 规则维护成本极高。期望的目标一个好的解决方案应当满足以下三点不要求禁用 Docker 的 iptables让 Docker 继续像往常一样管理自己的网络。这样新增 Docker 网络时无需手工维护任何 iptables 规则也避免了禁用 iptables 之后可能带来的副作用。公共网络不能访问 Docker 发布出来的端口即使是用-p 0.0.0.0:8080:80把端口发布到所有 IP 地址上同时容器之间、内部网络之间都能正常互相访问。虽然也可以让 Docker 把端口只映射到服务器的私有 IP 上但服务器可能有多个私有 IP且这些私有 IP 还可能变化并不稳妥。能像ufw allow 8080/ufw delete allow 8080一样方便地放行/拒绝公共网络对容器端口的访问无需额外软件和额外配置。开始之前先撤销原先的修改如果你已经按照网上搜到的旧方案修改过服务器请先回滚这些变更包括启用 Docker 的 iptables 功能删除所有类似--iptablesfalse的修改包括/etc/docker/daemon.json配置文件中的相关项。将 UFW 的默认FORWARD规则改回默认的DROP而不是ACCEPT。删除 UFW 配置文件/etc/ufw/after.rules中与 Docker 网络相关的规则。如果修改了 Docker 相关的配置文件先重启 Docker稍后还要修改 UFW 配置可以一并重启。核心方案只改一个 UFW 配置文件本方案只需要修改一个 UFW 配置文件即可生效Docker 的所有配置和选项全部保持默认——既不用--iptablesfalse也不需要手工维护 NAT 规则。编辑/etc/ufw/after.rules在文件末尾追加如下规则块# BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :ufw-docker-logging-deny - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j ufw-user-forward -A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN -A DOCKER-USER -m conntrack --ctstate INVALID -j DROP -A DOCKER-USER -i docker0 -o docker0 -j ACCEPT -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-docker-logging-deny -m conntrack --ctstate NEW -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -m conntrack --ctstate NEW -d 172.16.0.0/12 -A DOCKER-USER -j ufw-docker-logging-deny -m conntrack --ctstate NEW -d 192.168.0.0/16 -A DOCKER-USER -j RETURN -A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix [UFW DOCKER BLOCK] -A ufw-docker-logging-deny -j DROP COMMIT # END UFW AND DOCKER保存后重启 UFWsudo systemctl restart ufw # 或者 sudo ufw reload此后效果是公共网络无法访问 Docker 发布出来的任何端口容器内部以及私有网络地址之间可以正常互相访问容器也可以正常访问外部网络。⚠️ 注意事项可能存在某些未知原因导致重启 UFW 之后规则未能生效此时请直接重启服务器。这一规则块正是 ufw-docker 脚本中ufw-docker--check-installufw-docker#L425-L478与ufw-docker--check-install_ipv6ufw-docker#L480-L533按模板生成的内容测试文件 test/ufw-docker.test.sh 中的test-check-install-ipv4-asserttest/ufw-docker.test.sh#L787-L828也以逐行断言的方式验证了这套规则块与 README 文档完全一致。如何放行用ufw route allow管理容器端口默认情况下公共网络无法访问任何发布端口若希望允许外部访问某个容器服务需要使用ufw route子命令并以容器的服务端口而非宿主机发布端口作为端口参数。例如容器的服务端口是80放行所有容器内端口为80的已发布服务ufw route allow proto tcp from any to any port 80注意如果发布端口时用的是-p 8080:80这里应写容器端口80而不是宿主机的8080。如果有多个容器的服务端口都是80但只想放行某个特定容器例如该容器的私有地址是172.17.0.2ufw route allow proto tcp from any to 172.17.0.2 port 80如果服务是 UDP 协议例如 DNS 服务放行所有已发布的 DNS 服务ufw route allow proto udp from any to any port 53同样地只针对特定容器如 IP 地址172.17.0.2ufw route allow proto udp from any to 172.17.0.2 port 53ufw route allow之所以能放行容器端口是因为规则块中第一句-A DOCKER-USER -j ufw-user-forward把控制权交还给了 UFW 的 forward 链——UFW 会把route类规则写到ufw-user-forward链中从而接管外部网络 → 容器方向的所有转发流量实现在一个地方集中管理全部防火墙规则。核心规则逐条解析规则作用-A DOCKER-USER -j ufw-user-forward将流量交给 UFW 的 forward 链使ufw route allow规则可以生效统一管理容器端口放行-A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN允许已建立和相关连接保证返回流量能够通过-A DOCKER-USER -m conntrack --ctstate INVALID -j DROP丢弃连接跟踪状态为非法的数据包-A DOCKER-USER -i docker0 -o docker0 -j ACCEPT允许 Docker 内部通信例如默认网桥上的容器之间互相访问-A DOCKER-USER -j RETURN -s 10.0.0.0/8等三条放行来自私有网络地址段的流量10.0.0.0/8、172.16.0.0/12、192.168.0.0/16通常情况下私有网络比公共网络更值得信任-A DOCKER-USER -j ufw-docker-logging-deny -m conntrack --ctstate NEW -d 10.0.0.0/8等三条阻止所有由公共网络发起的、目的地址为私有网段的新连接请求内部网络访问外部网络不受影响-A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix [UFW DOCKER BLOCK] 对被阻止的连接以每分钟最多 3 条、突发 10 条的速率写入系统日志日志前缀为[UFW DOCKER BLOCK]便于排查-A ufw-docker-logging-deny -j DROP最终丢弃进入该链的数据包值得注意的细节是被拦截流量的目标地址是私有网段RFC 1918而不是宿主机公网 IP。因为 Docker 端口发布后外部流量经由 DNAT 转发进容器时其目标地址已被改写为容器所在的私有网段地址公共网络发起的新连接到达DOCKER-USER链时目标即私有网段因此在这条链上按目标网段判别即可精准拦截公共网络同时不误伤内网。旧方案不使用 conntrack的原理如果使用的是较旧的内核或更偏好旧方案README 也给出了不使用 conntrack 的规则集。编辑/etc/ufw/after.rules在末尾追加# BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :ufw-docker-logging-deny - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j ufw-user-forward -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 -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN -A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix [UFW DOCKER BLOCK] -A ufw-docker-logging-deny -j DROP COMMIT # END UFW AND DOCKER旧方案的核心思路是阻止公共网络发起新连接但允许内部网络访问外部网络对 TCP通过--tcp-flags FIN,SYN,RST,ACK SYN匹配 SYN 包阻止从公共网络主动建立 TCP 连接。对 UDP由于 UDP 无状态无法像 TCP 那样靠握手信号区分主动发起连接因此改用端口范围判定——阻止所有对小于32767的 UDP 端口的访问。为什么是这个端口在 GNU/Linux 上查看/proc/sys/net/ipv4/ip_local_port_range可以看到本机发出 TCP/UDP 数据包时使用的本地源端口范围默认是32768 60999。当容器向外访问一个 UDP 服务时本地端口会从该范围内随机选取一个服务器把响应数据返回到这个随机端口上。因此可以假定所有容器内部监听的 UDP 端口都小于32768于是公共网络对小于32768的 UDP 端口发起主动访问都被视为可疑并阻止。特殊场景如果某个容器接收数据时没有遵循操作系统的端口设定最小端口小于32768比如运行了 Dnsmasq 容器——Dnsmasq 用于接收数据的最小端口号默认是1024——可以用下面的命令允许 Dnsmasq 使用更大的端口范围接收 DNS 数据包ufw route allow proto udp from any port 53 to any port 1024:65535因为 DNS 服务非常常见上述规则块中已经预留了一条-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN来允许 DNS 数据包使用更大的接收端口范围。为什么选ufw-user-forward而不是ufw-user-input使用ufw-user-input优点命令简单、容易理解支持老版本 Ubuntu。例如放行容器端口8080只需ufw allow 8080缺点ufw allow 8080会同时暴露主机端口与容器端口。比如主机上恰好也运行了一个监听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端口服务仍然不会被公开如果还想单独公开主机上的8080端口则需另行执行ufw allow 8080缺点不支持老版本 Ubuntu且命令使用相对复杂一些——不过可以用项目提供的ufw-docker脚本简化操作。结论若使用较老版本的 Ubuntu可以使用ufw-user-input方案但务必小心避免把不该暴露的服务暴露出去。若使用支持ufw route子命令的新版本 Ubuntu推荐使用ufw-user-forward方案并用ufw route管理容器相关规则。IPv6 支持要让 Docker Engine 启用 IPv6 支持并让 UFW 的 IPv6 链接管容器流量需要在/etc/docker/daemon.json中启用相关设置并分配一个 ULA唯一本地地址RFC 4193地址段作为 IPv6 网络范围{ experimental: true, ipv6: true, ip6tables: true, fixed-cidr-v6: fd00:dead:beef::/48 }修改后重启 Dockersystemctl restart docker对应地UFW 的 IPv6 配置在/etc/ufw/after6.rules。ufw-docker脚本会视情况自动更新该文件生成的内容与 IPv4 版结构相同但使用 IPv6 专属链名ufw6-user-forward与ufw6-docker-logging-deny默认私有 IPv6 子网为fd00::/8可参见 ufw-docker#L480-L533 与 test/ufw-docker.test.sh#L1501-L1538。ufw-docker工具一键安装与日常管理以上所有操作都可以由仓库根目录下的 ufw-docker 脚本自动完成。该脚本是一个单文件 Bash 脚本1107 行同时支持 Docker Swarm 模式。安装下载脚本并赋予执行权限sudo wget -O /usr/local/bin/ufw-docker \ https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker sudo chmod x /usr/local/bin/ufw-docker然后执行ufw-docker installufw-docker install会完成两件事对应源码 ufw-docker#L585-L637备份文件/etc/ufw/after.rules备份名带~时间戳~后缀把 UFW 与 Docker 相关的规则块追加到after.rulesIPv6 时同步处理/etc/ufw/after6.rules末尾规则块严格包裹在# BEGIN UFW AND DOCKER与# END UFW AND DOCKER之间便于重复安装与卸载时精准定位。如果 UFW 配置有变更脚本会提示你手工执行sudo systemctl restart ufw无 systemd 时提示sudo service ufw restart。脚本启动时还有前置检查UFW 必须处于 active 状态、Docker 可执行文件必须存在见 ufw-docker#L1028-L1036否则直接报错退出。使用--docker-subnets选项自定义子网--docker-subnets选项用于自定义允许与 Docker 容器通信的子网同时适用于 IPv4 和 IPv6未指定该选项只使用标准的私有局域网子网IPv410.0.0.0/8、172.16.0.0/12、192.168.0.0/16IPv6fd00::/8。指定--docker-subnets但不带参数自动检测并使用所有 Docker 网络的子网实现见 ufw-docker#L406-L423通过docker network lsdocker network inspect读取各网络的 IPAM 子网。注意新增或删除 Docker 网络后需要重新运行ufw-docker install --docker-subnets才能根据最新网络配置更新防火墙规则。指定一个或多个子网CIDR 格式空格分隔只使用这些子网且可以包含 Docker 自身未管理的网络。示例# 使用默认私有局域网子网IPv410.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16IPv6fd00::/8 ufw-docker install # 自动检测并使用所有 Docker 网络子网同时支持 IPv4 和 IPv6 ufw-docker install --docker-subnets # 仅允许这些指定子网与 Docker 容器通信 ufw-docker install --docker-subnets 192.168.207.0/24 10.207.0.0/16 fd00:cf::/64同样的选项也可以与ufw-docker check搭配用于在应用变更前预览差异。使用--system选项安装到系统如果想连同脚本和 man page 一起安装到系统中ufw-docker install --system该命令会安装ufw-docker脚本到/usr/local/bin/ufw-docker安装 man page 到/usr/local/man/man8/ufw-docker.8man page 内容由脚本内置的man-page函数生成见 ufw-docker#L804-L1013同时安装 systemd 服务见下文。为 Docker Swarm 环境安装在 Swarm 模式下只能也只需要在**管理节点manager**上使用脚本管理防火墙规则在所有节点包括管理节点和工作节点上修改after.rules文件在管理节点上部署ufw-docker脚本。Swarm 模式下脚本会创建一个全局服务ufw-docker-agent镜像由本项目自动构建。其工作方式是ufw-docker service allow把服务名/发布端口/协议的规则写入 agent 服务的环境变量ufw_public_service_id多个规则用逗号分隔agent 容器入口见 docker-entrypoint.sh启动后读取这些环境变量在各自节点上执行ufw-docker add-service-rule完成实际放行。相关实现位于 ufw-docker#L220-L287且 test/ufw-docker-service.test.sh 中test-service-allow-requires-service-name-a-service-add-new-env-asserttest/ufw-docker-service.test.sh#L214-L231等用例验证了该环境变量传递机制。全部子命令速查命令作用ufw-docker help显示帮助信息ufw-docker man显示 man pageufw-docker check检查 UFW 配置中防火墙规则的安装情况预览变更不实际写入ufw-docker install更新 UFW 配置添加必要的防火墙规则ufw-docker install-service安装 ufw-docker systemd 服务用于自动重载规则仅支持 systemd--force覆盖已存在的服务文件ufw-docker reload重载所有防火墙规则容器重启导致 IP 变化时非常有用ufw-docker uninstall恢复 UFW 配置删除所有已安装的文件ufw-docker status显示当前防火墙允许的转发规则ufw-docker list httpd列出所有与容器httpd相关的防火墙规则ufw-docker allow httpd 80暴露容器httpd的80端口默认 TCPufw-docker allow httpd 443/tcp暴露容器httpd的443端口协议为 tcpufw-docker allow httpd 443/tcp foobar-external-network容器绑定多个网络时指定foobar-external-network网络上的443/tcp端口ufw-docker allow httpd暴露容器httpd的所有已发布端口ufw-docker delete allow httpd删除与容器httpd相关的所有规则ufw-docker delete allow httpd 443/tcp删除容器httpd的tcp端口443规则ufw-docker service allow web 80暴露 Swarm 服务web的80端口等价写法ufw-docker service allow web 80/tcpufw-docker service delete allow web删除与服务web相关的所有节点上的规则ufw-docker service delete allow web 80/tcp删除服务web的80/tcp规则allow命令的源码级实现ufw-docker allow 容器名 [端口[/tcp|/udp]] [网络]的内部流程对应 ufw-docker#L80-L121 的ufw-docker--allow通过docker inspect解析容器的网络信息每个网络NetworkSettings.Networks下的 IPv4 地址与全局 IPv6 地址GlobalIPv6Address以及所有已发布端口NetworkSettings.Ports若指定了端口/协议/网络则只匹配对应条目未指定端口时遍历全部已发布端口对每条IP × 端口/协议 × 网络组合调用ufw-docker--add-ruleufw-docker#L136-L166实际执行的命令形如ufw route allow proto tcp from any to 172.18.0.4 port 5000 comment allow webapp 5000/tcp即通过 UFW 的route子命令把规则写进ufw-user-forward链并带上# allow 名称 端口/协议 网络形式的 comment作为后续list/delete/reload的识别标记。IPv6 地址对应的规则会追加/v6后缀区分参见 test/ufw-docker.test.sh#L504-L516 等断言语料。如果目标规则已存在且无变化会通过ufw --dry-run检测到 Skipping 直接跳过若存在旧版过期规则则先删除再重新添加。reload与 systemd 服务ufw-docker reloadufw-docker#L535-L583会读取当前所有带# allow注释的规则逐一重新执行ufw-docker--allow容器 IP 变化时自动按新 IP 重建规则容器已不存在时删除失效规则——这正是容器重启后 IP 漂移场景下的关键维护命令。ufw-docker install-service会生成 systemd 服务文件/etc/systemd/system/ufw-docker.serviceufw-docker#L639-L680其内容为[Unit] DescriptionUFW Docker Firewall Rules Afterdocker.service Requiresdocker.service PartOfdocker.service [Service] Typeoneshot ExecStart/usr/local/bin/ufw-docker reload RemainAfterExityes [Install] WantedBymulti-user.target即 Docker 服务启动后自动执行一次ufw-docker reload让防火墙规则始终跟随容器网络的最新状态。卸载ufw-docker uninstallufw-docker#L682-L722会依次备份并删除after.rules/after6.rules中# BEGIN UFW AND DOCKER到# END UFW AND DOCKER之间的规则块、删除ufw-docker-agent全局服务若存在、删除/usr/local/bin/ufw-docker与 man page、停止并禁用 systemd 服务最后提示手工重启 UFW。用 Vagrant 与单元测试验证方案本地试验Vagrant项目使用 Vagrant 搭建本地测试环境配置见 Vagrantfile。创建 1 个 master 节点和 2 个 worker 节点vagrant up登录 master 节点vagrant ssh master创建web服务docker service create --name web --publish 8080:80 httpd:alpine此时从宿主机不应能访问该服务curl -v http://192.168.56.131:8080在 master 节点上放行web服务的80端口sudo ufw-docker service allow web 80现在宿主机即可访问所有节点上的该服务curl http://192.168.56.13{0,1,2}:8080运行测试项目的测试环境同样由 Vagrant 准备会启动 4 个节点1 个 master、2 个 worker以及 1 个用于模拟外部网络访问的节点Vagrantfile 中的 Ubuntu 和 Docker 版本是从 Dockerfile 读取的。单元测试基于 Bach Unit Testing Framework运行 test.sh要求 Bash 4.3即可执行或直接运行test目录下的测试用例文件./test.sh测试覆盖了 test/ufw-docker.test.sh 中的规则块生成IPv4/IPv6、默认子网/自定义子网、allow/list/delete参数解析与多网络/多协议组合、reload规则重建、systemd 服务安装与卸载的各种分支以及 test/ufw-docker-service.test.sh 中的 Swarm agent 环境变量传递逻辑。注意IPv6 默认是禁用的可通过env ENABLE_DOCKER_IPV6true vagrant up启用还可通过env DOCKER_REGISTRY_MIRRORhttp://192.168.1.100:5000 vagrant up指定本地 Docker registry 镜像源。遇到问题时可借助仓库提供的 print-iptables.sh / print-ip6tables.sh递归带缩进与颜色高亮地展示 iptables 规则和 trace-iptables.sh / trace-ip6tables.sh 辅助排查。小结Docker 直接操作 iptables 导致 UFW 无法拦截发布端口的流量这是公认的安全隐患在/etc/ufw/after.rules末尾追加DOCKER-USER链规则即可让 UFW 重新接管容器流量的进出控制无需禁用 Docker iptables也无需为每个新网络手工维护 NAT 规则放行容器端口使用ufw route allow系列命令端口参数以容器内部服务端口为准ufw-docker脚本把安装规则、按容器/端口/协议放行、重载、卸载、Swarm 支持全部封装为一条条子命令并配套 systemd 服务与单元测试可放心用于生产环境建议使用支持ufw route子命令的新版本 Ubuntu。赞分享网络安全运维【免费下载链接】ufw-dockerTo fix the Docker and UFW security flaw without disabling iptables项目地址https://gitcode.com/gh_mirrors/uf/ufw-docker点击查看免费下载相关推荐终极指南使用ufw-docker彻底解决Docker与UFW防火墙冲突终极指南使用ufw docker彻底解决Docker与UFW防火墙冲突 重要安全警报 如果你在Ubuntu服务器上同时使用Docker和UFW防火墙网络安全运维Docker防火墙安全漏洞终极解决方案为什么Docker会绕过UFW防火墙ufw-docker深度解析Docker防火墙安全漏洞终极解决方案为什么Docker会绕过UFW防火墙ufw docker深度解析 你是否曾经遇到过这样的情况明明在Ubuntu服务器网络安全运维Docker防火墙终极指南如何用ufw-docker解决安全漏洞Docker防火墙终极指南如何用ufw docker解决安全漏洞 如果你在Ubuntu服务器上同时使用Docker和UFW防火墙可能会遇到一个令人担忧的安全网络安全运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考