1. 项目概述为什么我们需要自己的漏洞挖掘框架在安全测试的日常工作中无论是做渗透测试、红队评估还是代码审计我们总会遇到一些重复性的、机械化的任务。比如面对一个新的Web应用我们得手动去收集子域名、探测端口、识别指纹、扫描常见漏洞然后再把结果整理到报告里。这个过程不仅耗时而且容易因为疲劳或疏忽遗漏关键信息。市面上的商业扫描器功能强大但往往价格不菲且扫描逻辑和规则是黑盒的难以根据特定目标进行深度定制而开源工具虽然灵活但工具链分散需要自己写脚本粘合数据流转和结果聚合又是个大问题。这就是“Bug-Hunter”项目诞生的初衷。它不是一个单一的工具而是一个自动化漏洞挖掘框架。你可以把它理解为一个高度可定制、模块化的工作流引擎。它的核心目标是把安全工程师从繁琐的重复劳动中解放出来让我们能把精力集中在更有价值的逻辑漏洞挖掘、业务逻辑分析和攻击面深度探索上。通过将信息收集、漏洞探测、结果验证等环节串联并自动化它能够实现7x24小时不间断的“轻量级监控”和“批量资产梳理”特别适合在SRC众测、企业内部常态化安全巡检、红蓝对抗的资产梳理阶段使用。我最初搭建这个框架是因为在一次大型攻防演练中面对上千个域名和IP资产传统的手工加半自动方式几乎让我崩溃。自那以后我就决定必须有一个属于自己团队的“自动化侦察兵”。接下来我将从设计思路、核心模块、实战部署到问题排查完整拆解如何从零构建这样一个框架。你会发现它并不需要多高深的技术更多的是对现有优秀工具的巧妙整合与流程设计。2. 框架整体设计与核心思路拆解2.1 核心架构管道与插件模式一个健壮的自动化框架其核心在于灵活和可扩展。Bug-Hunter采用了经典的“管道Pipeline”与“插件Plugin”模式。整个漏洞挖掘流程被抽象为一条流水线资产如一个域名或IP是流水线上的工件每个处理环节如子域名收集、端口扫描都是一个独立的插件。为什么选择这种模式首先它解耦了功能。每个插件只负责一件明确的事情比如SubdomainEnum插件只负责枚举子域名PortScan插件只负责探测端口。这样单个插件的逻辑变得简单易于开发和调试。其次它赋予了框架强大的可扩展性。当你需要增加一个新的探测能力比如专门检测某个新型CMS的漏洞你只需要按照接口规范编写一个新的插件然后将其“插入”到流水线的合适位置即可无需改动框架核心代码。最后这种模式便于控制流程。你可以根据目标资产的特点动态决定启用哪些插件或者调整插件的执行顺序。整个框架的数据流可以这样概括输入接收一个初始目标例如example.com。资产扩展通过子域名枚举、IP解析等插件将初始目标扩展成一个丰富的资产集合。信息收集对扩展后的资产进行端口扫描、服务指纹识别、目录爆破、关键信息提取如标题、证书、WAF等。漏洞探测基于收集到的信息如服务类型、框架版本调用对应的漏洞检测插件进行扫描。结果处理将漏洞验证结果、资产信息进行格式化输出到数据库、报告或消息通知平台。2.2 技术栈选型平衡效率与生态框架本身是“胶水”它的价值在于整合。因此技术栈的选择首要考虑的是与现有安全工具生态的兼容性和执行效率。编程语言Python 3.x。这是毫无疑问的选择。Python在安全领域拥有最庞大的工具库和社区支持如requests,beautifulsoup4,scapy等极大降低了插件开发门槛。其简洁的语法也适合快速原型开发和脚本编写。虽然执行效率不是最高但对于以网络I/O和外部工具调用为主的自动化任务来说完全够用。任务调度与并发Celery Redis。对于批量扫描任务异步和并发是必须的。Celery是一个强大、灵活的分布式任务队列它允许我们将每个插件的任务异步化。Redis作为Celery的Broker消息代理和Result Backend结果存储性能出色且部署简单。这套组合能轻松管理成千上万个扫描任务并实现任务的失败重试、优先级调度等高级功能。数据存储SQLite Elasticsearch。这里采用了分层存储策略。SQLite用于存储任务元数据、配置和简单的关联关系因为它轻量、无需单独服务适合框架自身管理。而扫描产生的海量资产数据、漏洞详情等则存入Elasticsearch。ES强大的全文检索和聚合分析能力让我们能快速地从数百万条记录中定位到“所有开放了8080端口且标题包含Jenkins的资产”。外部工具集成。框架不强求重复造轮子而是拥抱优秀的开源工具。例如子域名枚举集成subfinder,amass,assetfinder。端口扫描集成masscan全端口快速扫描和nmap服务深度识别。目录爆破集成dirsearch,ffuf。漏洞扫描集成nuclei基于模板的漏洞检测神器。 框架通过命令行调用或API方式与这些工具交互并解析其输出结果转化为结构化的数据。注意技术栈没有银弹。对于小型团队或个人使用你可能觉得CeleryRedis太重完全可以用Python的multiprocessing或concurrent.futures模块实现简单的多进程/线程池。关键在于先跑通核心流程再根据实际压力和复杂度进行架构升级。3. 核心模块解析与实操要点3.1 资产发现模块构建攻击面地图漏洞挖掘的第一步是搞清楚“打哪里”。资产发现模块的目标是从一个种子目标主域名、公司名称出发尽可能全面地找出所有关联的互联网资产。1. 子域名枚举Subdomain Enumeration这是资产扩展的核心。我们采用多源聚合的方式以提高覆盖率被动收集调用各类公开的API和数据集如VirusTotal, SecurityTrails, Censys, Cert.sh证书透明度日志等。这部分速度快不会对目标产生直接流量。主动爆破使用强大的字典如subdomains-top1million-5000.txt进行DNS暴力破解。这里可以集成altdns这样的工具通过排列组合生成可能的子域名如dev,test,staging等。递归枚举对发现的新子域名再次进行枚举可能发现更深层的资产如api.dev.example.com。实操要点字典质量主动爆破的效果严重依赖字典。建议维护一个自定义字典包含目标行业常见的词汇、缩写、以及从历史扫描中积累的特定目标关键词。速率控制在调用第三方API时务必遵守其速率限制避免IP被拉黑。可以在框架中为每个数据源插件配置独立的请求间隔。结果去重与验证从不同来源获取的子域名会有大量重复且可能存在无法解析的“死域名”。需要在存入数据库前进行去重和DNS解析验证只保留存活且可解析的记录。2. 端口与服务探测Port Service Detection获取域名列表后需要解析为IP并进行端口扫描。这里采用经典的“两步法”Masscan快速扫描使用masscan对所有IP资产进行全端口1-65535的快速扫描。它基于无状态扫描速度极快能在几分钟内扫完一个C段。Nmap服务识别将masscan发现的开放端口列表交给nmap进行二次扫描。nmap的-sV参数可以识别服务类型和版本号-sC参数可以运行默认的脚本检测获取更多信息如HTTP标题、SSL证书等。实操要点带宽与性能权衡masscan的扫描速度可以通过--rate参数控制。在云服务器上可以设置较高速率如10000包/秒但在家庭网络或对敏感目标扫描时应大幅降低速率避免触发对方的流量异常告警。Nmap脚本的妙用nmap的NSE脚本库是个宝藏。例如http-title.nse可以获取网站标题ssl-cert.nse可以提取证书信息其中可能包含其他域名http-headers.nse可以查看服务器头和WAF信息。合理选择脚本能极大丰富资产画像。3.2 信息收集与指纹识别模块给资产贴标签仅仅知道IP和端口还不够我们需要知道上面运行的是什么。这个模块负责给资产打上丰富的标签。Web指纹识别通过访问HTTP/HTTPS服务获取favicon、特定路径下的文件如/robots.txt,/wp-admin/、HTML特征、HTTP响应头等与指纹库如Wappalyzer的规则、FingerprintHub进行匹配识别Web框架Spring Boot, Django、CMSWordPress, Joomla、中间件Nginx, Apache Tomcat、前端库等及其版本。非Web服务识别对于非80/443端口通过nmap的-sV结果、服务banner信息识别数据库Redis, MySQL、缓存服务、远程管理服务SSH, RDP等。关键信息提取标题与证书从Web响应中提取页面标题从SSL证书中提取颁发者、有效期、SAN主题备用名称域名列表。目录与文件对Web服务进行轻量级的目录爆破寻找后台登录入口、配置文件如.git/config,.env、备份文件等。关联信息尝试通过https://crt.sh等接口根据当前域名查找同一张证书签发的其他域名进一步扩大资产范围。实操心得 指纹识别的准确性至关重要。一个误判可能导致后续漏洞扫描方向完全错误。建议采用“多特征加权判断”的策略。例如识别WordPress不能仅凭/wp-admin/目录存在就下定论还要结合/wp-includes/、/wp-content/、页面生成器标签meta namegenerator contentWordPress x.x等多个特征进行综合判断并给出置信度分数。3.3 漏洞检测模块智能调度与精准打击这是框架的“矛头”。我们不建议自己编写大量的漏洞检测POC而是集成和调度专业的扫描器。集成NucleiNuclei是目前社区最活跃的漏洞模板引擎。Bug-Hunter框架的核心策略是将信息收集模块产出的资产信息URL、指纹、标题等作为输入动态选择最相关的Nuclei模板进行扫描。工作流框架从ES中读取一批资产如果资产指纹包含“WordPress 5.0”则自动将资产URL加入待扫描队列并调用nuclei -t /path/to/wordpress-templates/进行扫描。模板管理需要定期如每天通过nuclei -update-templates更新社区模板。同时可以建立自己的私有模板库用于检测内部系统或特定业务的漏洞。自定义POC插件对于Nuclei模板覆盖不到的、或是非常业务逻辑化的漏洞可以编写自定义的Python插件。例如检测一个内部OA系统的特定接口是否存在未授权访问。被动式漏洞检测除了主动扫描还可以集成类似xray这样的被动扫描器作为代理。将所有框架发出的HTTP流量比如目录爆破、指纹识别时的请求通过xray代理xray会实时分析流量并检测漏洞。这种方式互补性很强能发现一些主动扫描难以触发的漏洞。注意事项 漏洞扫描是一把双刃剑极易对目标业务造成影响。速率限制必须在框架层面全局控制请求频率对单个目标设置req/s上限。扫描深度控制对于目录爆破、参数Fuzz等操作要设置合理的字典大小和递归深度避免无限循环或海量请求。敏感路径规避在字典中排除/admin/deleteUser、/api/resetPassword等可能造成数据破坏的路径。永远记住安全测试的原则是“只读不写”除非在获得明确授权的情况下进行验证性测试。4. 实战部署与核心环节实现4.1 环境搭建与框架初始化假设我们在一台Ubuntu 22.04的云服务器上部署。以下是精简步骤系统与依赖安装# 更新系统并安装基础编译环境 sudo apt update sudo apt upgrade -y sudo apt install -y python3-pip python3-venv git build-essential # 安装Redis sudo apt install -y redis-server sudo systemctl enable redis-server sudo systemctl start redis-server # 安装Elasticsearch (以7.x版本为例) wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - echo deb https://artifacts.elastic.co/packages/7.x/apt stable main | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list sudo apt update sudo apt install -y elasticsearch sudo systemctl enable elasticsearch sudo systemctl start elasticsearch框架代码与虚拟环境git clone https://your-git-repo.com/bug-hunter.git cd bug-hunter python3 -m venv venv source venv/bin/activate pip install -r requirements.txt # 这里包含celery, redis, elasticsearch, requests等外部工具安装将框架依赖的工具安装到tools/目录下并确保它们在系统PATH中或框架能通过绝对路径调用。mkdir tools cd tools # 安装subfinder go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinderlatest cp ~/go/bin/subfinder . # 安装masscan (需从源码编译) git clone https://github.com/robertdavidgraham/masscan cd masscan make cp bin/masscan .. cd .. # 类似方式安装nmap, nuclei, dirsearch等4.2 核心流水线代码解析框架的核心是一个Scanner类它定义了流水线。以下是一个高度简化的示例展示核心逻辑# scanner.py import json from celery import Celery from plugins.subdomain import SubdomainPlugin from plugins.portscan import PortscanPlugin from plugins.fingerprint import FingerprintPlugin from plugins.vulnscan import VulnscanPlugin app Celery(bug_hunter, brokerredis://localhost:6379/0) class Asset: 资产数据模型 def __init__(self, target): self.original_target target self.subdomains [] self.ips [] self.open_ports {} # ip: [port1, port2] self.services [] # 每个服务包含 ip, port, protocol, banner, fingerprint等 class Pipeline: def __init__(self, target): self.asset Asset(target) self.plugins [ SubdomainPlugin(), PortscanPlugin(), FingerprintPlugin(), VulnscanPlugin() ] def run(self): 顺序执行插件流水线 for plugin in self.plugins: print(f[*] 执行插件: {plugin.name}) # 每个插件处理asset并更新asset内容 self.asset plugin.execute(self.asset) # 将中间结果保存到ES便于调试和监控 self._save_asset_snapshot() return self.asset def _save_asset_snapshot(self): # 将asset对象转换为JSON存入Elasticsearch pass # 定义Celery任务 app.task def scan_task(target_domain): print(f[] 开始扫描任务: {target_domain}) pipeline Pipeline(target_domain) result_asset pipeline.run() # 触发结果处理任务如生成报告 process_result.delay(result_asset) return f扫描完成: {target_domain} app.task def process_result(asset): # 生成HTML报告、发送通知等 pass在实际中每个Plugin都是一个独立的类有标准的execute(asset)接口。PortscanPlugin可能会调用masscan和nmap解析它们的XML或JSON输出然后填充asset.open_ports和asset.services。4.3 任务调度与结果可视化启动Celery Worker# 在项目根目录下启动worker进程并发处理扫描任务 celery -A scanner.app worker --loglevelinfo --concurrency4可以启动多个worker在不同机器上实现分布式扫描。提交任务# 在一个Flask/Django管理后台或简单的脚本中提交任务 from scanner import scan_task task scan_task.delay(example.com) print(f任务ID: {task.id})结果可视化Elasticsearch配合Kibana是绝配。将资产和漏洞数据索引到ES后可以在Kibana中创建仪表盘。资产总览看板显示资产数量、服务类型分布、TOP开放端口。漏洞态势看板按漏洞等级高危、中危、低危、漏洞类型SQL注入、XSS、信息泄露、目标部门进行统计。时间线视图展示新发现资产、新出现漏洞随时间的变化趋势。 这能让安全团队对整体攻击面一目了然。5. 常见问题与排查技巧实录在开发和运行这类自动化框架的过程中我踩过不少坑。这里分享一些典型问题和解决思路。5.1 性能与稳定性问题问题扫描速度慢队列堆积严重。排查首先查看Celery Worker的日志看是哪个插件耗时最长。通常瓶颈在端口扫描masscan/nmap和Web请求指纹识别、目录爆破上。解决分级扫描不是所有资产都需要深度扫描。可以对资产打标签如“核心业务”、“边缘系统”。对核心业务进行慢速、全面的扫描对边缘系统则进行快速、基础的扫描。优化扫描策略端口扫描时先用masscan快速扫全端口但只对masscan发现的开放端口进行nmap服务识别而不是对所有IP的常用端口都做nmap。增加并发适当增加Celery Worker的并发数--concurrency并确保服务器CPU和网络带宽跟得上。设置超时与重试为每个插件的网络请求设置合理的超时时间并配置Celery任务的失败重试机制避免因单个请求卡死导致整个任务停滞。问题误报率太高特别是漏洞扫描部分。排查检查Nuclei扫描结果分析误报的模板。很多模板是基于正则匹配响应内容可能匹配到其他无关页面。解决模板过滤定期审查和更新Nuclei模板禁用已知误报率高的社区模板。建立自己的“白名单”或“低置信度”模板分类。二次验证框架不应直接将Nuclei的结果标记为确认漏洞。可以设计一个“验证插件”对于中高危漏洞用更精确的POC或手动请求进行二次验证。例如对于一个“疑似SQL注入”的报告验证插件可以尝试发送一个带有sleep(5)函数的Payload通过响应时间延迟来确认。上下文关联结合资产指纹。如果一个报告说某目标存在“Apache Struts2漏洞”但指纹识别显示该站点是Nginx PHP那么这个报告很可能是误报可以直接降权或忽略。5.2 数据与流程问题问题资产数据混乱同一个服务被多次重复记录。原因从不同插件、不同路径发现的同一服务如通过IP直接访问和通过域名访问的同一个Web服务如果没有很好的去重逻辑会被当作两个资产。解决设计一个唯一的资产标识符。通常使用协议://主机:端口作为唯一键如http://192.168.1.1:8080和https://example.com:443。在数据入库前先检查ES中是否已存在相同标识符的记录如果存在则进行信息合并更新指纹、标题等而不是新建。问题扫描过程中被目标封禁IP。预防代理池集成代理池服务让扫描请求通过不同的出口IP发出。可以购买付费代理或维护一个自建的代理池。请求随机化在请求头中随机切换User-Agent在请求间添加随机延迟模拟人类浏览行为。遵守robots.txt对于Web扫描可以增加一个插件先获取并解析目标的robots.txt避免扫描被明确禁止的目录。应对一旦发现大量请求超时或返回403/429状态码框架应能自动暂停对该目标的扫描并记录告警通知管理员可能需要更换扫描节点或代理。5.3 部署与维护技巧配置分离将所有可变参数如API密钥、扫描速率、目标白名单/黑名单、通知Webhook地址写入配置文件如config.yaml或环境变量不要硬编码在代码中。这便于在不同环境测试、生产间切换。日志与监控为框架接入详细的日志系统如structlog或loguru记录每个插件执行的开始、结束、关键发现和错误信息。同时监控Celery队列长度、服务器资源使用情况便于提前发现瓶颈。定期更新建立一个定时任务Cron Job每周自动更新nuclei模板、subfinder等外部工具的字典和规则。安全工具的生命力在于其知识库的时效性。构建自动化漏洞挖掘框架是一个迭代的过程没有一步到位的完美方案。我的建议是从小做起先自动化一个你最痛的点比如子域名收集然后逐步扩展流水线。在每次攻防演练或众测项目后根据新遇到的需求和问题回头来优化和增加框架的功能。最终你会拥有一个高度贴合自己工作习惯和业务场景的“数字员工”它能不知疲倦地执行重复任务而你则可以专注于更高级别的战术思考和深度突破。