演讲人：马赵杰
01
02
Contents
实战IaC部署方案实现
实际项目中遇到的痛点
从工具化支撑视角
从红队视角
1.github上的代理池项目都是这么设计的，fofa现成的语句不用白不用。2.cs部署脚本都写好了，三天两头改profile，改webhook地址，部署完调试半天。3.vultr太卡了，阿里云太贵了，每次项目前购买机器都花费不少时间。4.dnslog配置都得手动上cf去改解析，一般配置完就不动了。
1.防守方IP封禁太狠，扫描速度一快，waf就封IP了，要一直切。2.自建的代理池抓的ip大部分都用不了，访问速度太慢。3.C2/dnslog才开3天就被威胁情报标记了。4.买的vps上面跑了无数个服务，又是frp又是jndi，时不时nuclei扫描，还得起cs/vshell，还得开文件服务。
现有部署方案有哪些
单机环境部署脚本- f8x
技术社区的设施建设观点
B/S架构场景配置管理-LuWu
1.停止更新2.仅支持Vultr和DigitalOcean
着重于单机加固、隐蔽性的投入对于快速部署、多云集成等效能类研究较少
仅仅是VPS上的“装机工具”，非真正的基础设施自动部署
IaC:让基础设施可编程
# Terraform代码片段provider "aws" {region ="ap-east-1"}resource "aws_instance""node"{count ="${var.node_count}"launch_template {id ="模板ID"}instance_type ="t3.micro"user_data= </root/frps.inisudofrps-c /root/frps.ini&EOF
user_data= <config.tomlsudoecho "domains = [ \"${var.domain}\"]" >>config.tomlsudosystemctlstopsystemd-resolvedsudotmuxnew-session -sdn-d;tmuxsend-keys -t dn:0 './dnslog' EnterEOF
DNSLog场景
场景模板化设计
resource "alicloud_instance" "instance" {count= "${var.node_count}"security_groups=alicloud_security_group.group.*.idinstance_type= "ecs.n1.tiny"image_id="debian_11_7_x64_20G_alibase_20230907.vhd"instance_name= "proxy-node-bj"vswitch_id=alicloud_vswitch.vswitch.idsystem_disk_size= 20internet_max_bandwidth_out= 100spot_strategy= "SpotWithPriceLimit"user_data<config.jsonsudoecho '"method":"chacha20-ietf-poly1305",' >>config.jsonsudoecho "\"server_port\":${var.proxy_port}," >>config.jsonsudoecho "\"password\":\"${var.proxy_pass}\"," >>config.jsonsudoservice ss-proxy restartEOF}
复杂场景–代理池
代理池场景设计兼容了多可用区部署，在部署完成后自动生成clash兼容配置，并将配置传至存储桶在线订阅
start_zone_ecs_proxy(){按各区域数量拉起对应代理机器}gen_zone_clash_config(){从terraform.tfstate取所有的ecsip按clash配置模板生成对应的clash兼容配置文件}upload_to_oss(){配置传至存储桶并生成长期限的订阅链接}
场景模板化设计
复杂场景–C2前置
C2前置场景涉及多机器配置，及大量脚本化适配工作。
抢占式实例/Spot实例
什么是抢占式实例？
价格实时浮动，相比按量付费可显著降低成本（最高可达90%）
库存不足或出价低于市场价时会被中断回收
适合短期、可中断、容错性高的业务,不适用于数据库、长时间稳定
而我们的代理池场景、和扫描节点场景刚好适合这种实例
R2存储全球回源
大量场景需要静态文件的依赖，例如jdk、c2服务端、前端编译打包等。
累计存储1.94GB近一年累计下载约0.35TB。使用R2:实际账单$0
利用Cloudflare R2无出口费用的对象存储解决方案，将大文件存储在R2，通过rclone实时更新维护，实现静态资源流量费降至0
IMDSv2/密钥
强制启用IMDSv2，要求获取元数据时必须携带Token，有效防御SSRF攻击导致的AK/SK泄露。
所有机器均不使用默认密码，除部分机器需ssh登录使用通过Terraform生成的随机密码外，其余均采用ssh密钥配置
旧版(IMDSv1): curl 169.254.169.254直接访问metadata。
新版(IMDSv2):需先PUT获取TOKEN，再携带Header访问，显著降低泄露风险。
在user_data初始化完毕后，会通过配置iptables规则禁止访问metadata，彻底杜绝ssrf风险。
统一代理出口
代理池节点全部采用抢占式实例/Spot实例，支持阿里云/腾讯云/aws和混合云节点
IP独享、连接稳定无丢包、无并发数上限定时任务配置+前置clash可以实现固定时间IP池切换
实战中开启50台代理节点场景仅需1分钟通过clash配置的负载均衡可实现1次请求换一个IP
按50台x8小时，机器成本仅需9元实际一场演练在代理池上投入不超过500，但使用IP量远超10000
代理效果对比
传统自建代理池方案，往往采用fofa查询来获取ip源，通过本地脚本进行轮训，切换麻烦，维护麻烦，并发速度和可用性难以满足需求。
最关键的，在使用过程中的传输安全性安全无法保证。
低成本快速扫描方案
基于消费队列的设计模式，设计的一套扫描平台，其服务端+扫描节点全部采用自动化部署，节点采用spot实例类型，成本极低，部署后自动向mq队列获取执行任务，执行完毕后将结果发送给result队列并ack这个消息。
满足分布式、随意扩容需求，原生支持ipv6资产。
主动扫描方案对比
传统打点扫描往往使用代理或单机vps进行扫描，在vps上会部署ARL、nemo等平台进行自动化信息收集。但随着近年来演练目标逐渐增多，单机扫描在速度和封禁对抗上都严重拖慢打点的步伐，往往是扫出结果，一进主机就看到其他队留下的痕迹。
通过自动化部署拉起的扫描平台，即平衡成本，又大大提高扫描的速度和结果的时效性，在实际项目中相比单机扫描平均快30-40倍，并且由于节点ip分散，指纹和探活触发ip封禁显著降低，扫描结果更多。
参考xray实现的平台化的，团队协同的saas被动扫描平台
服务端+扫描节点全部采用redc自动化部署，节点采用spot实例类型，成本极低。解决痛点：
1.实现流量卸载，本地正常过站，数据包镜像到云端处理，不会因上级代理造成流量瓶颈。2.支持多级子路径+高危组件指纹发现，实现OneScan、RouteVulScan的功能。3.支持敏感数据包匹配的功能，实现hae、Keydd规则，从此不再担心巨型js文件导致bp卡顿。4.多人过站url自动去重，不必担心漏点、payload不齐等情况，拉齐外网打点能力。5.本地、云端两套代理池，被动流量统一走被动代理池出口，不会因为扫描导致本地客户端访问ip被封禁。
实际项目应用效果
未来发展方向
saas化基础设施调度平台
RedC核心引擎已在wgpsec内部开源，我们计划将其贡献给社区，结束重复造轮子的时代。
-场景开启、关闭主动权交由团队成员灵活处理-统计场景占比、使用费用，节约成本
mcp能力支持
-大模型自动调起红队场景，赋能自动化攻击
开源与社区计划
-开源核心引擎，提供场景模板，支持多云。-共建社区生态，让基建自动化成为红队必备。
谢谢观看
2025-11-15
