2026-11-09 19:05:08 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

第121篇 AI全栈 · 红队基础设施配置之AWS + 负载均衡 + 重定向器

原创

陈看山
陈看山

安全诸子

2026年11月8日 10:22
上海

去阅读

很多人第一次配红队基础设施，卡住的地方往往不是 C2 装不上，而是“马能上线，但一换域名就不通”。本地直连服务器没问题，套上负载均衡就 404，再接 CloudFront 就彻底没反应，于是开始怀疑 payload 写错了、端口封了、C2 挂了。其实多数时候问题出在链路上：安全组、目标组健康检查、回源策略三者没有对齐。这篇就把 AWS 上的“实例 + 负载均衡 + 重定向器”这条链路拆成可照做的步骤，讲清楚每一步的判断标准和失败后的修正方向。

这件事解决什么问题，适合谁要解决的问题很具体

让 C2 的监听端口不直接暴露在公网 IP 上，而是通过一个中间层接收连接，再转发到后端实例。这样做的直接收益是真实服务器地址不出现在外联记录里，同时多了一层可控的入口。适合的人：已经能在单台 VPS 上跑起 Mythic 或 CobaltStrike、理解基本的上线与监听概念、有合法授权环境或自建靶场可用的读者。不适合的人：还没搭过 C2、不清楚 payload 生成参数含义的读者，建议先把单机上线跑通再回来。需要提前说清楚边界：下面所有操作都应放在你自己的账号、你自己的靶场或明确授权的测试环境中进行。涉及跨境云服务注册和计费，账号与支付方式请自行按合规途径处理，本文不展开。

前置准备与环境条件先把输入列清楚，缺一项后面就会返工

一个可用的 AWS 账号，能创建 EC2、ELB、CloudFront。 - 一台本地机器，用于 SSH 连接和生成 payload。 - 你的公网出口 IP。查法很简单，搜索引擎搜“IP”即可看到。这个 IP 后面要写进安全组白名单。 - 一个已经能正常启动的 C2。本文以 Mythic 为例，安装过程不重复，假定你已经能在实例上启动它。 - 一把密钥对（.pem 文件）。创建实例时生成并下载，丢失只能重建。输出是什么：一条“payload 指向 CloudFront 域名 → CloudFront 回源到负载均衡 → 负载均衡转发到实例 80 端口 → C2 上线”的完整链路，以及配套的三层安全组规则。有一个容易忽略的前提：C2 监听在 80 端口且直接访问返回 404，这是后面健康检查能配通的关键，先记住这个事实。

第一步

起实例，先把直连跑通目标：在 AWS 上得到一台能 SSH 登录、能跑 C2 的实例。进控制台启动新实例，选好系统镜像，配置按 C2 的实际消耗给。Mythic 比较吃资源，2 核 8G 是常见起步配置，按小时计费，用完记得关。存储建议给到 64G，镜像和容器拉取会占不少空间。密钥对这一步选择“创建新密钥对”，命名后创建，浏览器会自动下载 .pem 文件。这个文件只在创建时给一次，妥善保存。网络设置就是安全组，本质是防火墙加白名单。这里把 SSH 来源限制为你自己的公网 IP，效果是只有你这台机器能连 22 端口，其他来源一律拒绝。这一步不要图省事开 0.0.0.0/0。成功标志：实例状态为运行中，你能用 SSH 客户端连上。命令行方式是用 -i 指定 pem 文件；不习惯命令行的可以用 FinalShell 之类工具导入私钥连接，效果一样。连上之后安装并启动 C2。启动后先做端口转发，把远端监听端口映射到本地，方便本地浏览器访问管理后台： ssh -L 7443:127.0.0.1:7443 -i \"your.pem\" ubuntu@<实例地址> 判断标准：本地能打开 C2 管理界面，说明隧道通了。

第二步

生成 payload，验证直连上线目标：确认不走任何中间层时，payload 能上线。在 C2 里生成一个 exe，监听地址填实例的公网 IP，端口 80，协议用 http。生成后运行，大概率上不了线。原因不是 payload 错了，而是安全组没放行 80 端口。去实例的安全组，编辑入站规则，添加一条允许 80 端口的规则。保存后再跑一次 payload。成功标志：C2 里出现会话，同时在实例上查看连接，能看到一条从你本地出口 IP 到实例公网 IP 的 80 端口外联。这一步是整个链路的地基，直连不通就不要往下走。关键检查点：如果放行后仍不上线，先确认 C2 监听确实在 80 端口、payload 里的 IP 没有写错、本地网络没有拦截出站。别急着怀疑云厂商。

第三步

创建负载均衡，把入口从 IP 换成域名目标：让 payload 指向一个负载均衡的 DNS 名称，而不是实例 IP。在控制台创建负载均衡器，选应用型（Application Load Balancer）。填名称，VPC 里把可用区的子网勾上，至少两个，这是应用型负载均衡的硬性要求。安全组先用默认的，后面再收紧。接下来是整条链路最容易出错的地方：目标组。创建目标组时，健康检查的“成功代码”必须改成 404。原因很直接，C2 的 80 端口直接访问返回的就是 404，如果你保持默认的 200，健康检查会一直判失败，目标组里的实例会显示不健康，流量根本不会转发过去。目标组建好后，把实例勾选加入，创建目标组，再回到负载均衡的监听规则里，把默认转发指向这个目标组，最后创建负载均衡器。成功标志：等待约三分钟，负载均衡器状态变为活跃，拿到一个 DNS 名称。用 ping 测一下能解析。直接用浏览器访问这个域名，看到 404 是正常的，恰恰说明回源通了。然后生成新的 payload，地址填这个 DNS 名称，端口 80。运行后看外联，真实地址应该变成负载均衡的地址，而不是实例 IP。

第四步

安全组怎么配才不返工三层结构对应三套安全组，配错任何一层都会表现为“前面都通，最后一跳断了”

实例的安全组：出站保持默认放行。入站除了你自己的 IP 访问 SSH，还要放行 80 端口，并且来源要指向负载均衡所用的安全组，而不是 0.0.0.0/0。这样只有负载均衡能把流量打到实例的 80 端口。负载均衡的安全组：入站和出站都用默认放行即可，它需要能接收外部流量，也需要能回源到实例。 CloudFront 这一层不挂传统安全组，但要注意它回源时走的是 AWS 的边缘网络，所以负载均衡侧不需要为它单独加白名单，保持默认放行就能通。判断标准：直连实例的 80 端口如果从公网仍然可达，说明实例安全组收得不够紧，建议把来源收敛到负载均衡安全组。

常见错误与排查顺序按出现频率排，遇到问题从上往下查

第一，payload 不上线但端口看着是通的。先确认安全组放行的是正确的端口和协议，再确认 C2 监听地址不是只绑了 127.0.0.1。第二，目标组显示不健康。九成是健康检查成功代码没改成 404。改完等一个检查周期再看。第三，负载均衡域名访问超时而不是 404。检查子网是否覆盖了实例所在可用区、目标组是否真的注册了实例。第四，CloudFront 域名访问失败。先看分配状态是否已部署，再看查看器请求方法是否放得太窄，最后确认源站协议和端口与负载均衡监听一致。第五，全链路配完但外联地址仍是实例 IP。说明 payload 里填的还是旧地址，重新用 CloudFront 域名生成一次。排查原则：从后往前，先保证直连通，再加负载均衡，最后加重定向器。每加一层就验证一次 404 和外联地址，不要三层一起配完再测，否则故障点无法定位。

风险点与使用边界这类配置本身是基础设施工程，风险主要在使用场景和运维习惯上

一是账号与计费风险。云资源按小时计费，实例、负载均衡、CloudFront 都会产生费用，测试完及时释放，避免长期挂着。二是暴露面管理。安全组白名单是基础，SSH 只对自己的 IP 开放，80 端口只对负载均衡安全组开放，不要为了省事全开。三是合规边界。整套链路只应部署在你拥有或获得明确授权的环境中，用于授权的对抗演练、自建靶场或防御验证。把它用在未授权目标上，性质和后果都不在技术讨论范围内。四是日志与痕迹。CloudFront 和负载均衡都会留下访问日志，正式演练前想清楚日志保留策略，这也是防御方复盘时会看的地方。