欢迎来到我的博客

��.⚖ 负载均衡 vs 普通部署 vs 反向代理：你的 Shell 到底落谁家？ 💡 一句话破防： 你以为拿下一台服务器就赢了？在负载均衡面前，那可能只是“群演”之一！ 🔍 一、三种架构快速认脸 表格 架构类型 核心目的 典型表现 渗透视⻆关键词 普通单机部署 简单直接 1个IP = 1个网站 “打下即控全” 反向代理（如Nginx） 隐藏后端 / 统一入口 域名 → 转发到某台服 “真假难辨” 务器 负载均衡（如Nginx 分流请求 / 高可用 1个域名 → 多台服务器 “打一不算赢” upstream） 轮流响应 🧩 二、负载均衡：渗透测试的“多面陷阱” ✅ 它怎么工作？（来自你的实操） nginx 编辑 343

1 upstream fzjh { 2 server 47.94.236.117:80 weight=2; # 更常被访问 3 server 47.122.22.195:80 weight=1; # 较少被访问 4 } 5 location / { 6 proxy_pass http://fzjh; 7 } ● 用户访问 target.example.com → 请求被分发到两台不同服务器。 刷新几次，⻚面内容可能突然变了（因为切到了另一台机器）！ ● ⚠ 对渗透测试者的三大冲击：

1. 权限碎片化 拿下 A 服务器 ≠ 控制整个业务。 ○ 后台、数据库、配置文件可能只在 B 或 C 上！ ○
2. 漏洞复现不稳定 你在 A 上传了 Webshell，但下次请求被分到 B → Shell 404！ ○ 扫描结果忽有忽无，像“薛定谔的漏洞”。 ○
3. 真实资产难摸清 你只知道入口 IP，但背后有 3 台？5 台？10 台？ ○ 每台配置可能不同（有的打补丁，有的没打）。 ○ 🆚 三、全景对氏：打哪种架构最头疼？ 表格 维度 普通单机 反向代理 负载均衡 服务器数量 1 台 1（代理）+ 1～N（后 ≥2 台（同业务） 端） 拿下一台 = 全控？ ✅ 是 ❌ 否（要看后端） ❌ 否（只是集群一 员） Webshell 稳定性 高 中（依赖转发规则） 极低（可能下次就没 了） 344

测试策略重点 直接打漏洞 识别真实后端 测绘所有节点 + 找共 性弱点 典型防御价值 无 隐藏源站、WAF 高可用、防单点故障、 抗压 💡 小知识：负载均衡常和反向代理一起用！ Nginx 既能做反代（隐藏后端），也能做负载（分发流量）——双重迷惑！ 🧭 四、渗透测试实战建议 🔎 1. 如何判断用了负载均衡？ 多次刷新⻚面，返回内容/响应头/JS 版本不一致。 ● 相同请求，有时快有时慢（不同服务器性能差异）。 ● Cookie 或 Session 无法保持（各节点未共享会话）。 ● 🕵 2. 如何应对？ 持续请求 + 记录响应特征：用 Burp Intruder 或脚本抓取多次响应，聚类分析有多少“面孔”。 ● ● 尝试固定节点：某些 LB 支持 sticky session （基于 Cookie/IP），可锁定某台测试。 ● 横向移动优先：一旦拿下一台，立刻找内网其他节点（如 192.168.x.x 、同网段扫描）。 关注共享组件：数据库、Redis、NFS —— 这些才是“命⻔”，而非单台 Web 服务器。 ● 💥 3. 高阶思路：利用权重配置 ● 如果某台权重高（如 weight=10 ），它承担更多流量 → 更可能是主业务节点，优先打！ 权重低的可能是备用机，但安全更新滞后 → 反而更容易突破！ ● 📜 五、渗透口诀（背下来少踩坑！） 345

单机部署好下手，一⻢平川拿到手； 反向代理藏真身，拨开迷雾⻅后端； 负载均衡最狡猾，打下一城不算赢； 多点测绘⻬发力，共享组件是命⻔！ ✅ 总结：别让“集群”骗了你 负载均衡 ≠ 安全增强，但它显著提升攻击成本。 ● 渗透目标要从 “单点突破” 升级为 “集群测绘 + 关键路径打击”。 ● 真正的胜利，不是拿下一台服务器，而是控制整个业务链。 ● 346

��.🔄 反向代理 vs 正向代理 vs 普通直连：渗透 测试中的�真假服务器�迷局 💡 一句话破题： 正向代理是你找别人帮忙上网，反向代理是服务器替你“藏”了真实后台——你以为在打 A，其实 B 才 是真目标！ 🔍 一、三种架构快速识别 表格 类型 谁发起代理？ 代理为谁服务？ 渗透视⻆下的关键特征 普通直连 无代理 — 客户端 ↔ 真实服务器 （IP = 真实应用） 正向代理 客户端主动配置 为客户端隐藏身份或绕 常⻅于翻墙、内网出口 过限制 代理；测试时你控制代 理入口 反向代理 服务器端配置 为服务端隐藏后端、负 你访问的是“前台”，实 载均衡或伪装 际流量被转到“幕后”； IP ≠ 真实应用 🎭 二、反向代理：渗透测试者的“幻觉制造机” ✅ 典型表现（来自你的实操）： ● 访问 target.example.com → 显示 百度首⻚ 347

● 访问 target.example.com/admin → 可能跳转到任意后台系统（如 WordPress、Jenkins） 但！这和原网站毫无关系！ ● 🚨 这就是反向代理的“魔法”： 它能把你的请求悄悄转发到任何你能想到（或想不到）的服务上！ ⚠ 对渗透测试的影响： 表格 ⻛险点 说明 目标误判 你以为在测一个 CMS，其实背后是数据库管理界 面 路径混淆 /api/ 可能指向内网微服 务， /backup/ 可能映射到 NAS IP 隐藏 真实服务器 IP 被 Nginx/Apache/Tengine 隐藏 WAF 绕过干扰 反代层可能自带规则，导致漏洞探测结果失真 🆚 三、全景对氏：三种模式怎么打？ 表格 场景 普通直连 正向代理 反向代理 你能看到什么？ 真实 Web 应用 代理服务器（如 代理服务器（如 Squid） Nginx） 真实服务在哪？ 就在当前 IP 在代理之后（你可控） 在代理之后（你不可 控） 典型工具链 Burp + Nmap + ProxyChains + 内网扫 Host 头注入、路径爆 Dirsearch 描 破、源站探测 渗透突破口 直接打 Web 漏洞 利用代理访问内网 探测后端真实服务 （如 /xxx → 转发 到 192.168.1.100） 348

防御目的 — 控制出站流量 隐藏架构、负载均衡、 安全隔离 🧭 四、渗透测试实战建议 🔎 1. 如何判断用了反向代理？ ● 响应头含 Server: nginx ，但⻚面内容像 Apache/Java 应用 ● 不同路径返回完全无关的技术栈（如 / 是 PHP， /app 是 Spring Boot） ● 修改 Host 头可触发不同响应（Host 头攻击试探） 🕵 2. 如何“看穿”反向代理？ ● 路径爆破：尝试 /admin 、 /console 、 /metrics 等，看是否映射到内部系统 ● Host 头注入： Host: internal.app.local → 观察是否回源到内网服务 IP 直连对氏：用真实 IP 访问 vs 域名访问，内容差异大？→ 极可能反代 ● 查看 TLS 证书：证书绑定多个域名？可能为多后端服务统一入口 ● 💥 3. 高阶利用：反向代理变“跳板” ● 若反代配置不当（如未校验 X-Forwarded-Host ），可： SSRF 到内网 ○ 劫持其他租户流量（多租户 SaaS 场景） ○ 伪造后端服务响应（配合缓存投毒） ○ 📜 五、口诀助记（背下来不吃亏！） 正向是你找代理，翻墙上网靠它行； 反向是它藏后台，你打前台它转场； 普通直连最老实，IP 应用是一家； 渗透若不识代理，白打三天全是假！ 349

✅ 总结：反向代理不是终点，而是新起点 别被表面迷惑：一个域名背后可能是 10 个系统。 ● 转变思路：从“打漏洞”转向“探架构”。 ● 善用信息差：反向代理配置错误 = 送你一张内网地图。 ● 350