SpiderFoot 开源网络资产扫描与威胁情报自动化从部署到批量任务实战这次我们来看一个开源项目smicallef / spiderfoot。SpiderFoot 是一款自动化开源情报OSINT与攻击面测绘工具项目发布在 GitHub 上作者是 Steve Micallef。它的核心用途是针对一个域名、IP 地址、邮箱、人名或者一段关键词自动去上百个数据源里收集信息再把分散的线索关联成一张资产关系图。安全测试人员拿到一个授权范围内的目标时可以靠它快速完成信息收集蓝队排查自身暴露面时也可以用它持续监测哪些资产信息被泄露到了公开渠道。这个项目最值得关注的点有三个自动化程度高不需要手动一个个去查 whois、证书、DNS 记录、GitHub 仓库或者社交媒体SpiderFoot 会把查询任务编排成扫描模块自动跑完并汇总。自带 Web UI 和 API可以从浏览器里创建扫描、查看结果关系图也可以直接调用 REST API 做批量扫描适合写脚本二次集成。完全开源且可本地部署全部源代码在 GitHub 上支持 Docker、源码安装、源码运行等多种方式数据留存在自己手里适合企业内部做资产测绘和风险自查。接下来本文会用一套完整的实操顺序展开先说硬件和部署门槛再给环境准备与安装方式然后演示如何在 Web UI 里发起第一次扫描接着介绍 API 调用和批量扫描任务最后整理资源占用观察方法和常见排错清单。如果你正在找一款能本地跑的 OSINT 自动化工具或者想在自己的安全工具链里加一个信息收集模块这篇文章可以收藏备用。1. SpiderFoot 核心能力速览在动手之前先把项目的基本规格梳理清楚。下面的信息都基于 SpiderFoot 官方仓库文档和常规部署实践整理更精确的版本参数请以你实际拉取到的代码为准。能力项说明项目类型自动化 OSINT / 威胁情报 / 攻击面测绘工具开源情况GitHub 开源仓库地址smicallef/spiderfoot主要功能域名/IP/邮箱/人名等目标的自动化信息收集、数据关联分析、扫描结果可视化、报告导出支持的扫描目标类型IP 地址、域名、主机名、邮箱地址、姓名、用户名、比特币地址等数据源数量整合大量公开数据源具体数据源数量随版本更新动态变化启动方式Docker 启动、源码启动、命令行扫描、Web UI、REST APIWeb UI自带默认基于 TCP 端口 5001支持自定义 host/port 参数API 接口支持 REST API可调用扫描模块并获取结果批量任务支持通过命令行或 API 编排多个扫描目标适合脚本化处理数据存储使用 SQLite 存储扫描结果本地落盘推荐硬件常规 CPU 内存即可运行具体数据源请求耗时取决于网络环境和目标响应操作系统Linux、macOS、WindowsWSL/容器更省心适合场景授权渗透测试信息收集、企业暴露面自查、威胁情报线索富化、安全研究从能力表可以看出来SpiderFoot 不是一个重模型、重 GPU 的 AI 工具而是一个重任务编排、重数据源调度的情报收集平台。它对显卡没有要求内存和磁盘占用也比较可控普通虚拟机就能跑。2. 适用场景与使用边界2.1 适合谁用SpiderFoot 的典型使用人群包括以下几类。第一类是渗透测试和红队人员。拿到授权目标后先跑一轮 SpiderFoot 扫描把子域名、DNS 记录、开放端口关联的网页信息、邮箱泄露情况、关联的社交账号等线索自动收集起来后续渗透测试会省很多手工收集时间。第二类是企业的安全运营和蓝队人员。内部明确资产范围后可以定期对自有域名和公网 IP 做扫描检查是否有未知子域名、过期证书、泄露凭据、敏感信息暴露等风险。这里的核心价值是可重复、可留存每次扫描结果都写入本地数据库方便前后对比。第三类是威胁情报和应急响应人员。拿到一个可疑域名或钓鱼邮箱后可以用 SpiderFoot 快速查询这个目标的 whois、DNS、证书、历史解析信息、黑名单收录情况判断它是否值得继续跟进。第四类是安全工具链开发者。SpiderFoot 提供 REST API 和 Python 模块可以把它嵌入到自己的安全编排平台、漏洞管理流程或者资产测绘系统里形成自动化情报收集插件。2.2 不适合的场景SpiderFoot 不适合做实时在线攻击它本质是被动信息收集和公开数据聚合。它不会直接对目标系统发起漏洞探测或流量攻击扫描效果取决于公开数据源的丰富程度。如果目标是一个纯内网资产、没有对外暴露任何公网信息或者它使用的数据源全部被墙或不可用扫描结果会非常有限不要指望它能像端口扫描器那样直接看到目标开放端口。另外对单个超大规模目标做全量扫描时数据源请求数量会很多整个过程可能持续很久。如果只是临时查一个域名的基本信息用命令行单次查询可能比开启全量扫描更高效。2.3 合规与安全边界使用 SpiderFoot 时必须注意边界。只对你有权扫描的目标做测试。本文中所有扫描目标建议使用自己的测试域名、本地回环地址或公开的演示域名。涉及邮箱、姓名、用户名等个人信息的收集必须遵守当地法律法规和隐私保护要求不应批量采集无关个人的敏感信息。扫描结果中可能包含员工邮箱、内部域名、源代码片段等敏感数据本地部署时要注意数据库文件的访问权限避免未授权访问引起泄露。不要将 SpiderFoot 用于骚扰、人肉搜索、未授权资产测绘或任何侵犯他人权益的行为。生产环境使用前建议先用一个自己完全可控的测试目标验证数据源连通性和输出格式。3. SpiderFoot 本地部署环境准备3.1 环境需求从官方文档和常见部署实践来看SpiderFoot 对环境的要求并不高操作系统Linux 优先macOS 也可以Windows 建议使用 WSL 或 Docker 以减少依赖问题。内存扫描大量数据源时内存占用会上升建议至少 4GB 可用内存。磁盘源码加依赖约 1GB 左右数据库会随扫描量增长建议预留 10GB 以上空间。Python源码运行时需要 Python 3.x具体版本请以项目当前要求为准。网络需要能访问 SpiderFoot 的数据源服务。不同数据源在不同网络环境下的可用性不同如果某些数据源无法访问扫描结果会缺失对应的模块数据。端口默认 Web UI 使用 5001 端口如果端口被占用可以通过--listen-address和--port参数自定义。3.2 通过 Docker 部署Docker 是个人觉得最省事的方式不用在宿主机上装一堆 Python 依赖。SpiderFoot 官方仓库长期维护 Docker 镜像部署流程如下# 拉取镜像 docker pull ghcr.io/smicallef/spiderfoot:latest如果不确定镜像地址是否与最新文档一致可以先去仓库的docker/目录或 README 里确认。也可以直接看本地是否有导入的镜像文件docker images | grep spiderfoot创建并启动容器的通用模板docker run -d \ --name spiderfoot \ -p 5001:5001 \ -v $(pwd)/spiderfoot-data:/var/lib/spiderfoot \ ghcr.io/smicallef/spiderfoot:latest这里把容器内的数据目录挂载到宿主机的./spiderfoot-data这样即使容器删掉扫描数据也不会丢。-p 5001:5001把容器的 Web UI 端口映射到宿主机。启动后访问http://127.0.0.1:5001看到登录页面说明服务已经正常起来了。SpiderFoot 在 Web UI 里首次使用要求设置管理员账号密码后续扫描任务和配置都通过这个账号管理。3.3 通过源码安装如果不想用 Docker可以克隆源码手动运行。git clone https://github.com/smicallef/spiderfoot.git cd spiderfoot安装依赖时建议使用 Python 虚拟环境避免污染系统 Python。python3 -m venv venv source venv/bin/activate pip install -r requirements.txt启动 Web UIpython3 ./sf.py -l 127.0.0.1:5001也可以只做命令行扫描不启动 Web UI下面会专门讲。3.4 验证部署是否成功部署完成后可以用三个简单方法验证浏览器打开http://127.0.0.1:5001能显示登录页。检查进程和端口ss -tlnp | grep 5001查看容器日志或源码运行日志确认没有报错。如果页面打不开优先排查端口是否被占用、防火墙是否放行、容器是否真正启动成功。4. SpiderFoot 启动方式与 Web UI 操作4.1 Web UI 启动SpiderFoot 的老版本 Web UI 默认不需要登录直接打开页面就能用。新版本引入了管理员认证机制首次打开会提示设置admin账号的密码。设置完成登录后主页面提供几个核心入口New Scan创建新扫描。Scan Results查看扫描结果。Settings配置数据源、代理、日志级别等。Correlation Rules查看和调整关联规则。4.2 创建第一次扫描在 Web UI 中创建一个基础扫描建议从一个小型测试目标开始。例如使用自己的一个二级域名或者本地测试环境里可控的模拟域名不要一上来就跑超大范围目标。操作步骤点击 “New Scan” 或 “扫描” 入口。在 “Seed Target” 输入框中填写目标例如example.com或一个 IP 地址。在下面的扫描模块列表中选择需要启用的模块。如果不知道选什么可以使用默认的 “All” 或者官方推荐的 “Passive” 扫描模式。点击提交等待扫描启动。扫描创建后页面会跳转到扫描状态页。你可以实时看到哪些模块正在运行。每个模块查到了哪些事件。事件类型、数据源、来源目标、首次发现时间。第一次扫描可以先跑一小部分模块比如只启用 DNS 解析、whois、证书透明度日志、搜索引擎枚举这几个模块。这样既能验证数据源连通性又不会让扫描时间过长。4.3 查看扫描结果扫描结束后或扫描过程中结果页面会展示一个可视化的实体关系图。节点代表目标、IP、域名、邮箱、URL 等实体边代表实体之间的关系。关系图的放大缩小、节点拖拽都是基础交互。除了关系图结果列表还会按事件类型分类展示数据来源模块、事件类型名称、具体数据内容和关联的目标。你可以用过滤条件只查看某类事件比如只看子域名、只看邮箱地址、只看泄露凭据。4.4 导出报告SpiderFoot 支持把扫描结果导出为多种格式包括 HTML 报告、JSON、CSV 等。CSV 格式适合后续用 Excel 处理JSON 格式适合写脚本二次分析。在结果页面中选择对应导出格式即可。5. SpiderFoot 功能测试与效果验证部署起来之后一定要自己动手验证功能是否可用。这里给出一套通用验证流程读者可以照着在自己的环境里跑一遍。5.1 目标选择测试目标选择得好不好直接影响验证效率。建议使用自己拥有的测试域名例如your-test-domain.com。本地搭建的模拟 Web 服务对应的域名。一个你已经知道答案的小型目标方便和扫描结果对照。尽量不要直接扫一个大型网站也不要扫描你没有授权访问的目标。5.2 测试基础信息收集第一个测试目的是验证 SpiderFoot 能否正常调用常见数据源。测试目标使用一个你熟悉的域名启用以下模块sfp_dnsresolve解析域名 IP。sfp_whois查询 whois 信息。sfp_certspotter或sfp_crt查询证书透明度日志。sfp_search通用搜索引擎枚举。预期结果扫描结果中能看到该域名的 IP 地址。能看到注册人、注册商、更新日期等 whois 信息。能看到该域名关联的证书记录或子域名记录。判断成功标准事件类型中包含INTERNET_NAME、IP_ADDRESS、NETBLOCK_OWNER等类型。数据来源列能正确显示模块名称。常见失败原因数据源请求超时有些公开数据源对自动化查询有限流。网络环境无法访问某些数据源。域名本身没有任何公开记录。5.3 测试关联分析SpiderFoot 的强项是关联分析。测试时可以在扫描模块中选择多个不同维度的数据源扫描结束后查看关系图里是否能把“目标域名”和“关联邮箱”“子域名”“IP 地址”连成一条链路。具体操作创建一次新的扫描。目标填写测试域名。模块选择所有被动扫描模块。等待扫描结束。打开关系图点击某个节点查看它的邻居节点和边属性。如果关联分析生效你会看到同一个邮箱地址同时出现在 “Email address found in source code” 和 “Social media profile” 等不同事件里这些线索会被合并成同一个实体。5.4 测试 CSV 导出在扫描结果页面点击导出 CSV检查导出的字段是否完整。重点看是否有目标、事件类型、事件数据、来源模块这几个核心列。中文字符或特殊字符是否正常编码。文件是否可以正常用办公软件打开。CSV 导出能跑通后续做自动化报表就方便很多。5.5 测试命令行扫描不带 Web UI 直接命令行扫描适合已有明确目标的批处理场景。python3 ./sf.py -m sfp_dnsresolve,sfp_whois -s example.com -q-m指定模块列表多个模块用逗号隔开。-s指定扫描目标。-q开启安静模式减少日志输出。命令行扫描同样会把结果写入 SQLite 数据库后续可以通过 Web UI 查看该扫描的结果也可以用 API 读取。6. SpiderFoot 接口 API 与批量扫描任务SpiderFoot 的 API 能力是很多人选择它的重要原因。通过 REST API可以抛开 Web UI 手动点击直接在自己写好的安全工具链里动态创建扫描、获取扫描状态、拉取结果。6.1 API 启动要求使用 API 前需要先启动 Web 服务。无论用 Docker 还是源码方式只要 Web UI 能访问API 通常就同时在线了。可以通过浏览器访问http://127.0.0.1:5001/来确认服务状态。API 的请求地址与 Web UI 同源一般是http://127.0.0.1:5001/具体的 API 前缀和认证方式会随版本变化建议先到项目的/doc/路径或源码sfwebapi.py中查看当前版本支持的接口定义。6.2 通用 API 调用示例模板下面给出一个通用的 Python 请求模板实际使用时需要按你部署版本的接口路径、认证字段和请求体调整。import requests import json base_url http://127.0.0.1:5001 session requests.Session() # 如果启用了登录认证先登录获取会话 # login_data {username: admin, password: your_password} # session.post(f{base_url}/login, datalogin_data) # 创建扫描任务示例接口路径实际以项目文档为准 scan_payload { scanname: test-scan, scantarget: example.com, module_list: [sfp_dnsresolve, sfp_whois, sfp_certspotter], type: all } # 实际接口可能需要先创建 scan 再启动 scan create_resp session.post(f{base_url}/scan, jsonscan_payload, timeout30) print(create status:, create_resp.status_code) print(create_resp.json())继续获取扫描结果# 拉取扫描结果列表 scan_id your_scan_id result_resp session.get(f{base_url}/scanresult/{scan_id}, timeout30) if result_resp.status_code 200: data result_resp.json() for event in data.get(events, []): print(event.get(type), event.get(data))需要注意不同版本的 SpiderFoot API 路径有差异早期版本常用/scan、/scanresult/{id}这样的结构新版本可能增加认证 token 或改写路径。调用前一定要先看本机版本的接口源码或/openapi.json。6.3 批量任务设计思路批量扫描是 SpiderFoot 在实际工程中最常见的用法。比如你维护了一张资产清单包含 50 个域名希望每天自动扫一遍并把结果写入数据库。推荐的做法把域名清单保存为文本文件每行一个域名。用脚本循环读取清单逐个调用 API 创建扫描。每创建一个扫描后记录scan_id和当前时间。定期轮询扫描状态判断扫描是否结束。扫描结束后自动拉取结果导出 CSV 或写入自己的数据库。失败的任务记录原因并重试。伪代码示例import time import requests targets [example.com, example.net, example.org] base_url http://127.0.0.1:5001 def create_scan(target): # 伪接口需要按实际版本替换 resp requests.post( f{base_url}/scan, json{scantarget: target, module_list: [sfp_dnsresolve]}, timeout30 ) return resp.json().get(scan_id) for target in targets: try: scan_id create_scan(target) print(f{target} - {scan_id}) except Exception as exc: print(f{target} failed: {exc}) time.sleep(1)批量任务运行时要注意不要让所有扫描同时并发启动部分数据源有限流并发过高会大量超时。建议控制并发数量比如同时最多跑 3 到 5 个扫描。每个扫描之间留一点间隔避免瞬间请求风暴。定时任务可以放到 crontab 或 systemd timer 中周期性执行。6.4 获取批量扫描结果批量扫描完成后可以把所有扫描的 CSV 导出到统一目录再合并成一个总表。如果你用的是 JSON 接口也可以按scan_id逐个拉取 JSON 然后合并。7. SpiderFoot 资源占用与性能观察SpiderFoot 不是 GPU 密集型工具性能瓶颈主要在数据源请求的网络耗时和本地数据库写入速度上。7.1 观察内存占用用 Docker 启动时可以用以下命令观察容器资源docker stats spiderfoot用源码启动时可以用top -p $(pgrep -f sf.py)在扫描大量数据源时SpiderFoot 需要把事件数据写入 SQLite 数据库同时内存中会缓存一部分扫描状态。如果内存只有 2GB建议减少并发扫描数量或者减少单次扫描启用的模块数量。7.2 影响扫描速度的因素影响 SpiderFoot 扫描速度的因素主要有以下几点数据源数量模块越多请求越多耗时越长。数据源响应速度部分免费数据源响应慢超时时间长。目标资产规模目标下的子域名、关联邮箱越多后续扩展查询越多。网络环境到不同数据源的网络延迟和可达性差异很大。扫描类型被动扫描比主动扫描慢因为要等所有被动模块跑完。7.3 降低资源占用的技巧如果机器配置较低可以按下面这些方法降低资源占用单次扫描不要全选所有模块按需勾选。使用命令行扫描时只传递必要模块。限制关联事件的递归查询深度避免无限制扩展。定期清理旧扫描结果删除不再需要的数据库记录。如果使用 Docker限制容器内存上限docker run -d --memory2g \ --name spiderfoot \ -p 5001:5001 \ -v $(pwd)/spiderfoot-data:/var/lib/spiderfoot \ ghcr.io/smicallef/spiderfoot:latest7.4 端口与进程冲突处理如果 5001 端口被其他进程占用启动会失败。先检查端口占用ss -tlnp | grep 5001如果冲突可以换端口启动python3 ./sf.py -l 127.0.0.1:6001Docker 方式则修改宿主机映射端口docker run -d -p 6001:5001 \ --name spiderfoot \ -v $(pwd)/spiderfoot-data:/var/lib/spiderfoot \ ghcr.io/smicallef/spiderfoot:latest7.5 数据库文件位置使用默认配置时SpiderFoot 会在运行目录下生成 SQLite 数据库文件命名通常形如spiderfoot.db。Docker 挂载数据目录后数据库文件会存在挂载目录中。定期备份这个数据库文件相当于备份了所有历史扫描结果。8. SpiderFoot 常见问题与排查方法下面是部署和使用 SpiderFoot 时最容易遇到的一些问题。问题现象可能原因排查方式解决方案启动后页面打不开5001 端口被占用或服务未启动检查日志查看端口占用更换端口或重启服务依赖安装失败Python 版本不匹配或缺少系统库查看 pip 报错信息使用虚拟环境升级/降级 Python 版本某些数据源扫描无结果数据源不可达或限流查看该模块日志手动访问数据源更换可用数据源或调整超时时间扫描一直处于运行状态数据源请求等待超时查看具体等待中的模块等待完成或手动停止扫描后重跑数据库文件体积增长过快扫描目标过多事件数据量大查看数据库大小定期清理旧扫描记录登录页面提示密码不对密码设置后忘记或确认信息不一致重置管理员密码或重新初始化删除现有数据库后重新初始化注意备份API 请求返回 404接口路径与当前版本不一致查看接口源码或文档替换为当前版本的实际路径扫描结果中有大量重复事件多个数据源返回同一信息查看事件去重规则调整关联规则或过滤条件Windows 直接运行报编码错误Python 控制台编码问题查看报错信息使用 WSL 或容器运行浏览器页面样式缺失静态文件路径或 CDN 资源加载问题查看浏览器控制台报错确认网络可访问静态资源或换浏览器测试8.1 依赖安装失败的通用处理优先使用虚拟环境安装。如果pip install -r requirements.txt报错python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt如果某个包编译失败先看缺少哪个编译库例如libxml2、libxslt、build-essential再通过系统包管理器安装。8.2 数据源模块失效问题SpiderFoot 的数据源数量多有些公开数据源的接口会不定期调整或关闭。如果某个模块长期返回 0 条事件可能不是你的环境问题而是数据源本身不可用。可以先检查项目 GitHub 的 issue 中是否有人反馈再决定是否禁用该模块。8.3 扫描结果为空怎么办如果扫描跑完了但结果几乎为空按以下顺序排查确认目标格式是否正确。例如子域名目标不要带http://前缀。确认选择的模块是否和目标类型匹配。DNS 模块对邮箱目标没有意义。确认网络能访问数据源。可以临时在浏览器中打开数据源 URL 测试。查看该扫描的日志确认模块有没有报错。换一个更常见的公开域名测试排除目标本身数据量过少的问题。9. SpiderFoot 最佳实践与使用建议9.1 先用小目标验证流程无论你打算扫描多少资产第一次一定先用一个小目标把整条链路跑通。先确认 Web UI 能登录、扫描能创建、模块有结果、CSV 能导出。整条链路没问题后再去处理批量资产。9.2 保留最小可运行配置把一套最小可运行配置记录下来例如docker run -d \ --name spiderfoot \ -p 5001:5001 \ -v /data/spiderfoot:/var/lib/spiderfoot \ ghcr.io/smicallef/spiderfoot:latest每次重新部署时先按照最小配置启动再逐步增加模块和自定义配置。这样能节省大量排错时间。9.3 分目录管理扫描资产和输出建议建立规范的目录结构spiderfoot-project/ ├── targets/ │ ├── domains.txt │ └── ips.txt ├── outputs/ │ ├── csv/ │ └── json/ ├── logs/ └── scripts/脚本读取targets目录中的资产清单扫描结果写入outputs日志写入logs。后续做历史对比和报表导出都方便。9.4 批量任务加日志和失败重试批量扫描一定会遇到个别目标失败。在脚本里加入日志和重试机制每个目标记录开始时间、结束时间、扫描状态。失败的任务保留原始错误信息。设置最多重试 2 次。重试前等待 30 秒以上。9.5 接口服务限制访问范围如果 SpiderFoot API 被暴露在非本机网络一定要限制访问范围。建议监听地址使用127.0.0.1。需要远程访问时使用反向代理并启用认证。不要在公网直接暴露 5001 端口。定期更换登录密码。9.6 合规审计留痕企业环境中用 SpiderFoot 做资产测绘时建议记录扫描目标和时间范围保留授权文件并确保所有扫描行为都有合规依据。涉及第三方域名时务必先确认是否具备授权。9.7 定期更新代码和镜像SpiderFoot 更新比较活跃新版本可能增加数据源、修复模块 bug、更新关联规则。建议定期从 GitHub 拉取新代码或重新拉取 Docker 镜像。更新前备份数据库文件确保历史数据不丢失。10. 总结与下一步SpiderFoot 最值得尝试的点在于它把分散的 OSINT 查询和关联分析做成了一个开箱即用的平台有 Web UI、有 API、有命令行、有 Docker 镜像部署门槛低二次集成方便。拿到项目后最先应该验证的是 Web UI 能否正常启动然后创建一个针对自己测试域名的扫描查看 DNS、whois、证书日志这几个基础模块能否返回数据。这一步跑通说明项目本身没问题接下来就可以开始探索 API 和批量任务。最容易踩的坑有两个一是新版本 Web UI 登录认证逻辑和旧教程不一致导致按照旧文章操作时找不到入口二是部分公开数据源在当前网络环境下不可达导致扫描结果偏少。遇到这两种情况先看项目文档和日志不要急着判定工具不可用。后续可以继续扩展的方向包括把 SpiderFoot 接入企业 CMDB 资产库自动标记新增子域名用 API 定期对资产清单做巡检把 CSV 结果接入企业威胁情报平台做可视化大屏。如果你正在选型本地的资产测绘和开源情报收集工具SpiderFoot 值得花一个下午部署起来用一个测试域名跑一遍完整流程再决定是否要接入自己的安全体系。