内网服务被Agent SSRF访问

知识分享

2026-08-31 16:01

49 阅读

当服务器上的某个 Agent 被利用发起 SSRF 请求，内网服务就可能被未授权访问。
网络层 ACL（访问控制列表）能从源头限制谁可以访问内网资源，是成本最低、见效最快的隔离手段。
本文适合零基础运维，按步骤配置就能阻断这类访问。

先搞清楚 SSRF 为什么能打到内网

SSRF（Server-Side Request Forgery）是服务端请求伪造。
攻击者通过控制 Agent 的请求参数，让服务器去访问本该受保护的内部地址。
很多内网服务只依赖应用层验证，没在网络层限制来源，导致 Agent 一旦被利用就能直接访问数据库、Redis 或内部管理后台。

网络层 ACL 的作用就是在数据包进来之前先做一次筛选：只有符合规则的请求才允许到达内网服务。
对于绝大多数 SSRF 攻击，只要把不受信任的 Agent 请求挡在网络入口，就能大幅降低风险。

配置前先确认三件事，避免误伤正常业务：

如果内网服务既有正常业务，又有 Agent 调用，建议先给正常调用方单独规划白名单，不要把整个内网全部放开。

如果你是云服务器，优先在安全组里配置规则，因为安全组是前置在网络入口的，即使服务器被攻破，规则也依然生效。
操作路径一般如下：

添加后，安全组会在网络层直接丢弃来自 Agent 的对应访问包。
如果有多个内网服务，建议分别建规则，而不是一股脑拒绝整个网段，避免影响正常业务。

服务器自带防火墙也能完成类似隔离，适合没有安全组或需要更细粒度控制的场景。
在服务器上执行以下命令：

iptables -I INPUT -s 172.16.1.5/32 -d 10.0.0.0/24 -p tcp --dport 6379 -j DROP

这条规则的含义是：丢弃来自源 IP 172.16.1.5、目标地址为 10.0.0.0/24 网段、端口为 6379 的 TCP 包。

为了让规则永久生效，需要额外保存：

# CentOS / RHEL
iptables-save > /etc/sysconfig/iptables

# 使用 firewalld 的环境也可以先保存再 reload

注意：iptables 规则是顺序匹配的，-I 会插入到头部，确保在允许规则之前执行。
如果内网服务本身有放行规则，请确认拒绝规则排在前面。

配置完成后，从 Agent 上发起一次访问测试：

# 从 Agent 上尝试连接内网 Redis
redis-cli -h 10.0.0.10 -p 6379 ping

预期结果是连接超时或直接被拒绝。
如果仍然能连通，说明规则没生效，按这个顺序排查：

同时可以在服务器上看日志：

tail -f /var/log/redis/redis.log

正常隔离后，日志里不会出现来自 Agent 的连接记录。

只拒绝 Agent IP 够吗？ 不够。
Agent 可能被换掉或迁移，出口 IP 会变。
建议把 Agent 来源按网段管理，同时限制内网服务只监听内网网卡，不要绑定 0.0.0.0。

拒绝规则会不会影响 Agent 正常业务？ 会。
如果 Agent 本身有合法业务需要访问该内网服务，先放行白名单，再拒绝其余来源。
网络层 ACL 做的是一刀切隔离，精细控制还需要配合应用层鉴权。

ACL 能完全防住 SSRF 吗？ 不能。
ACL 只能阻断网络层访问，如果内网服务本身有 SSRF 或未授权漏洞，依然可能被绕过。
建议在应用层给内网接口加上 Token 或签名校验，ACL 作为第一道防线。

iptables 规则被清空了怎么办？ 很多系统重启后 iptables 规则会丢失。
除了保存规则文件，也可以用 firewalld 或云安全组双保险，避免单点失效。

如果你正在处理内网服务被 Agent SSRF 访问的问题，建议先按本文步骤完整执行，再根据自己环境做微调。
遇到异常时优先回看避坑和高频问题部分，先把网络层缺口补上，再逐步加强应用层安全。