Docker靶场如何限制网络可达范围?

在搭建漏洞靶场时，网络可达范围往往是最容易被忽视却最关键的安全边界。像 OWASP Juice Shop 这类靶场内置了大量真实可触发的漏洞，一旦其监听范围超出预期，就等于在实验者的网络中开放了一台"自带漏洞"的主机。因此，限制网络可达范围的本质，是确保这台脆弱服务只能被授权的实验者在受控路径上访问，而不是暴露给宿主机所在的整个局域网乃至公网。

值得注意的是，默认的端口映射会带来隐性暴露。使用常见的端口映射方式启动容器后，查看容器状态会看到映射显示为 0.0.0.0:3000->3000/tcp，其中的 0.0.0.0 意味着容器服务绑定到了宿主机的所有网络接口。这表示同一网段内的其他设备，只要能路由到宿主机，就有可能直接访问到这个靶场。对于一个刻意保留 SQL 注入、越权、XSS 等入口的环境来说，这种默认行为与"仅本机实验"的初衷并不一致。

收敛可达范围的第一道措施，是把服务绑定到回环地址，让映射只对本机生效，而非监听所有接口。这样访问入口被限制在 localhost 一侧，网段内其他主机无法直接触达。对于需要在容器之间联动的场景，更稳妥的做法是依托 Docker 的自定义网络进行隔离：把靶场放入独立的桥接网络，仅让需要互通的容器加入同一网络，而不是统一挂在默认网络上，从而把横向可达关系限定在明确声明的范围内。

分层控制访问路径

单纯依赖端口绑定仍不够完整，更可靠的思路是分层设防。宿主机层面的防火墙策略应作为兜底，确保即便映射配置出现疏漏，外部流量也无法进入靶场端口。若实验确实需要跨机访问，应优先通过受控的反向代理或跳板，而不是直接放开监听范围。这里要重申源环境中强调的授权边界：靶场只能用于自有或已获明确授权的实验环境，不应部署在公网服务器供人随意访问，也不应作为扫描真实站点的跳板。

把网络边界纳入实验流程

网络可达范围的控制不应是一次性动作，而应作为实验工作流的一部分固定下来。启动靶场后，可通过查看容器端口映射确认监听地址是否符合预期，再结合本机请求验证服务可用，形成一条"先确认暴露面、再开始验证漏洞"的基线检查。实验结束后及时停止并清理容器，避免脆弱服务长期驻留。官方镜像默认以非 root 用户运行已降低了容器内的权限风险，但网络暴露面仍需实验者主动约束。

当把监听范围、网络隔离与宿主机策略结合起来，靶场才真正成为一个可控、可回滚的实验沙箱，而不是一个潜伏在网络中的攻击面。