香港服务器安全加固方案：Debian 12部署Docker后如何限制端口并防止异常访问

Debian 12部署Docker后，限制端口不能只检查主机的INPUT规则。容器发布端口通常经过转发链，可能出现“主机防火墙已经拒绝，容器仍能访问”的情况；反过来，服务器端口不通也可能来自上游访问控制、端口映射或应用监听错误。

排查香港服务器上的此类问题，应按“外部访问路径 → 宿主机 → Docker映射 → 容器应用”的顺序定位。确认故障层级后，再选择取消公网暴露或限制来源地址，不要通过关闭防火墙来试错。

先排除外部访问路径问题

以下以宿主机TCP端口8080映射容器端口80为例。测试前记录客户端公网出口IP、访问目标、时间及返回结果，修复后使用相同条件复测。

从外部客户端执行：

curl -v --connect-timeout 5 http://服务器公网IP:8080/

不同结果对应不同检查方向：

• 连接超时：可能是上游过滤、主机丢弃规则或回程异常，不能直接归因于Docker。
• 连接被拒绝：常见于没有服务监听，也可能是防火墙主动拒绝。
• 返回HTTP状态码：说明TCP与HTTP链路已经可达；401、403应继续查认证和应用策略。
• IP可访问、域名不可访问：检查DNS解析，尤其是域名是否存在指向其他地址的AAAA记录。

若服务商控制台提供安全组或ACL，同时核对TCP端口和来源范围。不要为了排障临时开放全部端口。

需要确认请求是否抵达服务器时，可短时间观察报文摘要：

sudo tcpdump -ni any 'tcp port 8080' -c 20

工具未安装时，可通过Debian的apt安装tcpdump。外部请求期间完全没有对应报文，优先查目标地址、上游策略和客户端网络；看到SYN但连接不完成，再检查本机规则与回程路径。

定位宿主机、映射与应用

先核对环境和运行状态。下面的web均指示例容器名，应替换为实际名称。

cat /etc/os-release
docker version
sudo iptables --version
sudo iptables -S DOCKER-USER
docker ps --format 'table {{.Names}}\t{{.Ports}}\t{{.Status}}'
docker port web
docker logs --tail 100 web
sudo journalctl -u docker --since "30 minutes ago" --no-pager
sudo ss -lntp

重点区分三类情况：

1. 没有发布端口：Dockerfile中的EXPOSE只是声明，不等于配置-p或Compose的ports。
2. 发布为127.0.0.1:8080：只允许通过宿主机回环地址访问，公网不通是预期结果。
3. 发布为0.0.0.0:8080：端口绑定全部IPv4地址；如果来源不限，公网访问范围可能超出预期。

ss未显示docker-proxy，不能单独证明端口没有发布。Docker可能直接通过NAT处理映射，应结合docker port和防火墙规则判断。

然后从宿主机访问：

curl -v --connect-timeout 5 http://127.0.0.1:8080/

此命令适用于绑定全部IPv4地址或回环地址的映射；若绑定指定宿主机IP，应改用该地址。

• 本机成功、外部失败：重点查上游ACL、转发规则和来源限制。
• 本机也失败：先查容器状态、映射和应用日志，不要继续增加放行规则。
• 应用仅监听容器内的127.0.0.1:80：桥接网络映射通常无法连接，应按应用配置改为监听容器接口，例如0.0.0.0:80。

若容器自带ss，可执行docker exec web ss -lntp检查。精简镜像没有该工具并不代表应用异常，应查应用启动日志或使用受控调试环境。

优先缩小暴露面，再加来源限制

不需要公网直连：绑定回环地址

如果容器只供宿主机上的Nginx反向代理使用，可将现有Compose服务的ports改为：

ports:
  - "127.0.0.1:8080:80"

这是服务配置片段，不是完整Compose文件。修改前备份原文件，先执行docker compose config -q校验，再于维护窗口执行：

docker compose up -d --no-deps web

端口映射改变通常需要重建容器，可能造成短暂中断。若反向代理也在容器内，优先使用共享Docker网络，通过服务名访问后端；代理容器中的127.0.0.1不是宿主机。

回环绑定也不能替代认证和版本维护。Docker官方文档提示，28.0.0之前的版本存在同二层网络访问回环发布端口的已知限制，旧环境应先核对并升级。

必须远程访问：在正确链路限制来源

以下规则仅适用于rootful Docker、桥接网络、iptables防火墙后端且存在DOCKER-USER链的环境。Debian 12常见的iptables-nft兼容前端不等于Docker原生nftables后端。若链不存在，先核对Docker配置，不要自行创建同名链冒充接入点。

操作前保留SSH会话和控制台入口，并备份规则：

sudo sh -c 'umask 077; iptables-save > /root/iptables-before-docker.rules'
sudo sh -c 'umask 077; nft list ruleset > /root/nft-before-docker.rules'
ip route get 1.1.1.1

从路由输出核对公网接口。假设接口为ens3，仅允许203.0.113.10访问发布端口8080：

sudo iptables -I DOCKER-USER 1 \
  -i ens3 -p tcp ! -s 203.0.113.10/32 \
  -m conntrack --ctorigdstport 8080 \
  -m comment --comment "limit-docker-8080" \
  -j DROP

203.0.113.10是文档示例地址，必须替换为真实可信出口IP。此规则限制该接口进入、原始目标端口为8080的转发流量，包括已有连接；其他规则仍可能拒绝可信来源。

为什么不能直接匹配容器端口？ 流量进入DOCKER-USER时通常已完成DNAT，目标端口可能变成80。--ctorigdstport匹配连接原始目的端口，才能对应宿主机发布的8080。

该规则仅覆盖IPv4和TCP，不涵盖IPv6、UDP、host网络或rootless模式。若同时提供IPv6访问，必须同步设计对应策略，否则可能留下另一条入口。

复测、观察与回滚

分别从可信和非可信出口执行同一条curl命令，并查看规则计数：

sudo iptables -vnL DOCKER-USER --line-numbers

预期是可信来源正常访问，非可信来源连接失败，拒绝规则计数随测试增加。若端口仍可访问且计数不变，应检查是否走了IPv6、其他网卡、代理入口或不同发布端口。

来源白名单只能缩小访问范围，不能阻止可信来源中的恶意请求。公网业务仍需认证、应用层限速和日志告警；不要把TCP连接数直接当作每秒请求数设置阈值。

出现误拦截时，删除刚添加的精确规则即可：

sudo iptables -D DOCKER-USER \
  -i ens3 -p tcp ! -s 203.0.113.10/32 \
  -m conntrack --ctorigdstport 8080 \
  -m comment --comment "limit-docker-8080" \
  -j DROP

回滚命令必须使用添加时的真实参数。Compose修改则恢复备份并重新部署对应服务，不要清空整套防火墙。

手工规则不等于持久化方案。验证通过后，应纳入现有防火墙管理流程，确保Docker启动后幂等加载，并在维护窗口检查重启后的效果；不要直接恢复包含旧容器地址的整套Docker动态规则。后端差异可核对Docker官方防火墙文档。