SpiderFoot 是一款开源的 OSINT公开源情报自动化收集与关联分析工具项目托管在 GitHub 的smicallef/spiderfoot仓库。它解决的是安全测试和资产管理工作里最耗时的一环把分散在 DNS、WHOIS、证书透明日志、搜索引擎、社交平台和各类安全 API 中的信息逐个查询、去重、归类再通过关联规则找出实体之间的关系最后整理成一份可读的侦察结果。对于需要做授权渗透测试、攻防演练、攻击面梳理、钓鱼演练前信息收集和威胁情报溯源的安全工程师来说SpiderFoot 是把“手工收集”升级为“可重复扫描”的常用起点。本文会按“工具定位 - 安装启动 - 命令行扫描 - Web UI 使用 - 模块与数据源 - 数据存储 - 问题排查 - 合规落地”这条主线展开。读完以后你能独立完成一次针对测试域名的完整扫描理解扫描结果里的实体、事件、关联和数据表结构也知道遇到超时、限流、权限问题时该从哪个环节查起。1. SpiderFoot 是什么把 OSINT 手工收集变成可重复的自动化扫描1.1 它解决什么问题做安全评估时第一步通常是“信息收集”。这一步看着简单实际很繁琐要查域名的 DNS 解析记录要查 WHOIS 归属要翻证书透明日志要搜公开的信息泄露要判断 IP 是否属于云厂商要找关联的子域名和邮箱账号。一个稍微上规模的域名靠浏览器一个页面一个页面打开半小时只能完成很小一部分而且很难保证记录完整。SpiderFoot 把这些碎片化查询封装成一个个模块每个模块负责一类数据源查询。用户只需要指定目标比如一个域名、一个 IP 或一个邮箱工具就会自动调用模块把返回结果统一存储并记录“这条结果是从哪里来的、可信度如何、有没有风险标记”。这样收集过程就从“人工多个窗口切换”变成“配置一次扫描等结果落库”。1.2 核心概念目标、模块、事件与关联规则理解 SpiderFoot先抓住四个词。目标Seed Target扫描的起点。可以是域名、IP 地址、邮箱、用户名、电话号码、比特币地址等。工具会先识别目标类型再决定使用哪些模块。模块Module一个模块对应一类数据源或一种处理逻辑。模块名统一以sfp_开头比如sfp_dnsresolve做 DNS 解析sfp_whois查 WHOIS。模块分为两种模式被动模式只查公开数据源不直接触碰目标主动模式会向目标主机发起连接或请求速度更快但会产生流量。事件Event模块查询后产生的一条条结果就是事件。每个事件都有类型、数据、来源模块、可信度Confidence和风险值Risk。例如 DNS 解析得到一条IP_ADDRESS事件WHOIS 查询得到一条NETBLOCK_OWNER事件。关联规则Correlation Rule这是 SpiderFoot 比单纯“信息收集脚本”更高级的地方。工具会把看起来孤立的事件放在一起做交叉分析比如“域名解析出的 IP 同时出现在另一份泄露数据里”或“两个不同域名共用同一套 DNS 服务器”从而发现隐藏归属关系。1.3 典型使用场景与能力边界SpiderFoot 的典型使用场景包括在获得授权的前提下对目标域名做攻击面测绘快速列出子域名、IP、开放服务线索和邮箱账号。蓝队用来梳理自己公司暴露在互联网上的资产检查是否有未登记域名或遗留系统。红队在攻防演练前做信息收集缩小目标范围找到入口线索。威胁分析时根据一个邮箱或恶意 IP 反查关联域名、证书和其他上下文。它也有边界。SpiderFoot 本身不是漏洞扫描器它不直接验证漏洞也不对目标发起大规模爆破。它处理不了需要登录的站内数据也拿不到收费商业数据源没有授权的内容。把它定义成“侦察与整理平台”比定义成“漏洞扫描器”更准确。2. 安装与启动源码、Docker 两种主流路径2.1 环境要求与版本确认SpiderFoot 使用 Python 开发不同版本对 Python 版本要求不同。新版本建议使用 Python 3.9 或更高版本如果你使用的是历史版本要先看仓库 README 和requirements.txt确认依赖范围。安装前先检查基础环境检查项建议值说明操作系统Linux、macOS 或 WindowsLinux 服务器最省心Windows 建议用 WSLPython3.9 及以上版本过低会导致依赖安装失败磁盘空间至少预留 2GB大范围扫描会产生较多 SQLite 数据和日志内存推荐 4GB 以上扫描大量网段或域名时内存占用明显端口5001 未被占用Web UI 默认监听 50012.2 源码安装方式源码安装适合需要看模块实现、改代码或二次开发的情况。先从 GitHub 拉取代码git clone https://github.com/smicallef/spiderfoot.git cd spiderfoot然后安装依赖。建议先创建虚拟环境避免污染系统 Pythonpython3 -m venv venv source venv/bin/activate pip install -r requirements.txt安装完成后仓库根目录下会出现sf.py这个入口脚本。可以在启动前先确认版本python3 sf.py --help如果命令能正常打印参数帮助说明依赖安装基本成功。这里要注意部分模块依赖可选库比如处理某些格式或 SSL 相关能力时如果缺少对应库模块会在运行时显示错误而不是在安装时报错。初次运行时看到个别模块报错不要急着认为安装失败先看日志里是否提示缺库。2.3 Docker 安装方式Docker 方式最适合快速体验和服务器部署不关心本机 Python 环境。官方仓库 README 中提供了镜像启动命令常见写法如下docker run -d \ --name spiderfoot \ -p 5001:5001 \ ghcr.io/smicallef/spiderfoot:latest这个命令把容器内的 5001 端口映射到宿主机启动后直接访问http://127.0.0.1:5001就能打开界面。容器运行时扫描数据和日志默认写在容器内部。为了不因为容器重建而丢失结果推荐挂载数据目录docker run -d \ --name spiderfoot \ -p 5001:5001 \ -v spiderfoot-data:/var/lib/spiderfoot \ ghcr.io/smicallef/spiderfoot:latest具体数据目录路径以当前镜像说明为准。挂载的好处是升级镜像后历史扫描记录还能保留。2.4 首次启动与登录验证源码方式启动 Web UI 时命令行可以指定监听地址和登录账号python3 sf.py -l 127.0.0.1:5001 -u admin -p yourpassword如果只执行python3 sf.py -l 127.0.0.1:5001有些版本会在控制台随机生成管理密码并打印出来登录后建议立即修改。无论哪种方式第一次访问 Web UI 时浏览器会要求输入用户名密码这一步是访问控制入口不应该跳过。验证启动正常的标志控制台没有 Python 异常堆栈。浏览器能打开登录页。输入账号密码后能进入扫描管理界面。注意Web UI 默认监听 127.0.0.1 是为了安全。如果部署在服务器上给别人访问不要用0.0.0.0裸奔必须配合防火墙和反向代理否则任何人都可能发起扫描并读取你的数据。3. 命令行扫描先把最小流程跑通3.1 命令行基本用法Web UI 适合交互操作命令行适合脚本化和定时任务。最小命令需要三个信息入口脚本、目标、模块或扫描类型。先看一个最简单的例子对example.com做 DNS 解析和 WHOIS 查询python3 sf.py -s example.com -m sfp_dnsresolve,sfp_whois这条命令执行完毕后结果会写入 SQLite 数据库。命令行模式默认不会像 Web UI 那样展示图形但数据已经落库后续可以用导出参数查看。如果不想指定模块可以直接指定扫描类型让工具选择一组合适的模块python3 sf.py -s example.com -t PASV这里的-t表示扫描类型PASV是“仅被动查询”的缩写。扫描类型不同模块组合差异很大下面单独说明。3.2 选择扫描类型与模块组SpiderFoot 的扫描类型相当于预设模块组合。常见的有扫描类型含义适用场景ALL使用全部可用模块综合测绘耗时最长FOOTPRINT足迹测绘覆盖 DNS、WHOIS、证书等基础信息域名资产梳理PASSIVE只使用被动模块不直接触碰目标服务器合规要求严格时的信息收集ACTIVE加入主动探测模块可能直连目标授权渗透测试INVESTIGATE调查模式偏重实体关联分析威胁追踪、关系挖掘命令行执行时-t和-m二选一即可。如果同时指定-m的优先级更高因为模块列表是精确控制。3.3 导出与查看结果扫描完成后可以用导出参数把结果写进文件。导出格式通常支持 CSV、JSON 等python3 sf.py -s example.com -m sfp_dnsresolve,sfp_whois -x result.json导出文件里每条记录会包含事件类型、事件数据、来源模块、可信度和风险等级。人工阅读时CSV 更适合用 Excel 打开JSON 更适合程序处理。如果想在命令行里快速确认“这次扫描到底发现了什么”可以在导出后用jq或grep做简单过滤。比如统计所有 IP 地址事件cat result.json | jq .events[] | select(.type IP_ADDRESS) | .data3.4 常用参数速查命令行帮助信息会随版本变化但以下参数在大多数版本中通用参数作用示例-s指定扫描目标-s example.com-m指定模块列表逗号分隔-m sfp_dnsresolve,sfp_whois-t指定扫描类型-t PASV-lWeb UI 监听地址-l 127.0.0.1:5001-uWeb UI 用户名-u admin-pWeb UI 密码-p yourpassword-x导出结果文件-x result.json-q安静模式减少控制台输出-q注意实际使用前要执行python3 sf.py -h确认当前版本支持的参数尤其要确认-t的缩写含义不同小版本可能调整过。4. Web UI 操作创建扫描、查看关联图与导出报告4.1 创建扫描并选择模块Web UI 是 SpiderFoot 最直观的操作入口。登录后首页会有一个“New Scan”区域需要填三样东西Seed Target扫描目标例如域名、IP。Scan Type扫描类型选 ALL 或 FOOTPRINT 都可以。Use Correlation是否启用关联规则建议保持开启。创建扫描前界面会列出这次扫描将要使用的模块清单。这个清单很有价值它让你知道这次扫描会查哪些数据源、哪些模块需要 API Key。模块清单右侧通常有“Select modules”入口可以按需勾选。实际项目里不要无脑全选模块越多耗时越长限流概率越高。先按目标类型选出核心模块扫描一轮后再根据结果补扫。4.2 关联图与结果筛选扫描结束后点击对应扫描记录就能看到结果页。结果页一般包含几个主要区域实体图以目标为节点展示域名、IP、邮箱、证书等实体之间的关系。节点之间的连线代表“谁引出了谁”。事件列表全部原始事件按类型、来源、可信度排序。关联结果显示关联规则命中的结论例如“某域名解析的 IP 与另一个域名相同”。事件列表是排查问题的主战场。如果一个模块没产生结果要在这里确认它是否执行过、是否报错、是否因为缺少 API Key 被跳过。结果页里的筛选器建议多用按事件类型筛选可以快速找到IP_ADDRESS、EMAILADDR、NETBLOCK_OWNER按风险排序可以优先关注高风险事件。4.3 报告导出与执行历史扫描结果除了在界面查看也可以导出。常见格式包括 JSON、CSV、GEXF 等。GEXF 格式可以导入图分析工具做进一步可视化适合画资产关系图。Web UI 还保留每次扫描的执行历史包括扫描开始时间、耗时、扫描状态运行中、完成、失败。如果扫描中途失败这里能直接看到失败阶段比命令行日志更直观。对于定期要做的资产梳理可以配合 Cron 或 CI 定时触发 CLI 扫描再把结果推送回 Web UI 数据库统一查看。Web UI 本身也有调度入口但生产环境里更推荐用自己的调度平台统一管理方便对接告警和通知。4.4 一个典型操作顺序推荐新手按这个顺序操作先用PASSIVE类型跑一个域名确认登录、扫描、结果查看都正常。看事件列表熟悉INTERNET_NAME、IP_ADDRESS、EMAILADDR等最常见事件类型。第二次扫描切到FOOTPRINT观察模块数量增加后耗时的变化。导出 CSV用表格软件分类汇总确认数据可读取。这样每一步都有明确检查点不会一开始就被几十个模块的输出淹没。5. 数据源与模块配置扫描能力的上限取决于 API Key5.1 模块分类与依赖SpiderFoot 的 200 多个模块按数据源类型可以分成几类模块类别典型数据源是否需要 API KeyDNS 相关DNS 解析、TXT 记录、子域枚举通常不需要WHOIS 相关WHOIS 查询、网段归属通常不需要证书相关证书透明日志、SSL 证书信息部分需要搜索引擎搜索引擎结果、网页爬取部分需要威胁情报恶意 IP 库、威胁情报平台大多需要社交与账号用户名、邮箱、社交平台信息部分需要端口服务端口扫描、服务指纹部分需要没有 API Key 的模块不是不能用只是能查的数据有限。比如威胁情报平台如果没配置 Key模块可能返回“未配置”而跳过或者仅返回公开接口的信息。5.2 常见模块与用途实际扫描时下面这些模块出现频率最高sfp_dnsresolve解析域名到 IP是整个扫描图的基础。sfp_whois查询域名和 IP 的 WHOIS 信息获取注册商、注册邮箱、网段归属。sfp_sslcert抓取站点证书信息常用来反查同一证书下的其他域名。sfp_shodan通过 Shodan API 查询开放端口和服务信息需要 Key。sfp_virustotal通过威胁情报平台查询域名和 IP 的恶意标记需要 Key。sfp_googlesearch用搜索引擎结果做被动发现可能受搜索限制。模块名在不同版本可能有增加或改名判断某个模块是否存在可以在 Web UI 的模块列表里搜索或直接看modules目录下的文件。5.3 配置 API Key 的策略API Key 写在spiderfoot.cfg配置文件里。源码目录下通常有一个spiderfoot.cfg示例复制后去掉.example后缀再编辑cp spiderfoot.cfg.example spiderfoot.cfg配置项一般长这样# Shodan API Key shodan: api_key: your-shodan-api-key这只是一个示意实际结构以当前版本spiderfoot.cfg中的注释为准。配置时要注意几点Key 文件不要提交到 Git 仓库建议加入.gitignore。不同数据源对并发和频率要求不同配置多个 Key 后先小范围测试不要一次性全量启用。多个扫描任务并发时同一个免费 Key 很容易触发限流要控制并发扫描数量。免费 Key 能查的数据范围有限生产环境按实际需要购买必要数据源的授权。6. 扫描结果的数据结构与存储6.1 SQLite 数据库文件默认情况下扫描结果存储在 SQLite 数据库中。源码部署时文件通常生成在spiderfoot.dbWeb UI 扫描的结果也写入该库。这意味着即便浏览器关掉了扫描数据仍然在下次登录还能看到。主要的数据表通常包括表名存什么关键字段tbl_scan扫描任务目标、扫描类型、开始时间、状态tbl_scan_result扫描事件明细事件类型、数据、来源模块、可信度、风险tbl_scan_log扫描日志模块、日志级别、消息内容直接连数据库查结果时不推荐在 Web UI 运行期间写入只读查询是可以的SELECT type, data, risk, confidence FROM tbl_scan_result WHERE scan_id 1 ORDER BY risk DESC;6.2 事件类型与风险字段事件类型是理解结果的钥匙。常见事件类型包括事件类型含义典型来源INTERNET_NAME域名或主机名DNS、反查、页面提取IP_ADDRESSIP 地址DNS 解析、证书、日志EMAILADDR邮箱地址WHOIS、网页、泄露数据USERNAME用户名社交平台、论坛NETBLOCK_OWNER网段归属方WHOISDNS_TEXTDNS TXT 记录内容DNS 模块WEBSERVER_HTTP_HEADERSHTTP 响应头主动网页请求SSL_CERTIFICATE_ISSUED证书签发信息证书模块每条事件还有两个重要字段confidence表示这条数据可信度来源越权威置信度越高risk表示风险级别比如“邮箱账号在公开泄露数据中出现”会被标记为高风险。风险字段不代表漏洞已经确认它只是线索。是否构成真实风险需要人工验证或结合其他工具确认。6.3 通过 Web API 读取结果新版本 SpiderFoot 提供 REST API方便把扫描结果集成到自己的平台。接口的完整定义可以查看项目文档或在线接口说明。典型用法是用登录后的认证信息创建扫描或读取扫描状态再按扫描 ID 拉取事件列表。集成时建议把 API 调用封装在独立服务里不要让前端直接持有管理员凭据。读取结果后用 JSON 格式推给数据分析平台或资产管理系统能和其他安全数据一起做关联。7. 常见问题排查7.1 扫描卡住或长时间无结果现象任务一直显示运行中事件列表长时间没有新增。排查顺序先看扫描日志确认当前卡在哪个模块。Web UI 的扫描详情页能看到日志CLI 模式看控制台输出。判断是否是该数据源响应慢。很多公开数据源没有 SLA偶发超时是常态。看模块是否有“API Key 未配置”提示这类模块会等待或跳过。看网络环境是否能正常访问目标数据源。数据源超时需要检查防火墙和 DNS。如果卡在某个模块很久可以在扫描配置里去掉该模块重跑缩小范围。处理建议大范围扫描拆成多个小扫描避免一个任务包含几百个模块。给关键数据源模块配置 API Key能显著减少等待超时。7.2 数据源返回 403、429 或限流现象日志里出现 403 Forbidden、429 Too Many Requests对应模块没有产出事件。可能原因该数据源要求用户代理或 API Key。免费额度用完。多个扫描并发请求频率超过限制。检查方式先看日志里的完整错误信息再对照数据源文档确认调用限制。如果是 403检查模块配置中是否缺少认证信息如果是 429降低并发任务数或加长扫描间隔。解决后建议做限速同一时间只跑一个扫描或把高频模块拆到不同时间段执行。7.3 Docker 数据丢失与端口占用现象容器删掉重建后历史扫描记录全部消失。原因没有挂载数据卷数据写在了容器可写层。解决方式启动时挂载/var/lib/spiderfoot数据卷或者把宿主机目录映射进去。重建容器前确认数据卷还在docker volume ls | grep spiderfoot端口占用的表现是容器启动失败日志提示address already in use。处理方式改变-p映射的宿主端口或者停掉占用进程。7.4 资源占用过高大网段扫描或全模块扫描会吃掉大量内存和磁盘。常见表现扫描过程中内存持续上涨。SQLite 文件膨胀到几个 GB。服务器开始卡顿。处理建议严格控制目标范围不要对超大 IP 段一次性全扫。优先使用被动扫描类型减少主动请求带来的连接开销。定期清理过期扫描删除不用的数据。生产环境为 SpiderFoot 单独划分资源限制比如 Docker 的--memory和--cpus参数。8. 合规使用与生产落地的建议8.1 授权与合规边界SpiderFoot 是侦察工具工具本身没有好坏使用方式决定了合规边界。实际项目里必须守住几条底线只扫描自己拥有或有书面授权的目标。未授权扫描可能违反当地法律法规也可能触发对方安全设备告警并引发法律纠纷。每个数据源都有自己的服务条款。SpiderFoot 帮你调用它但“调用是否符合该数据源规则”由使用者负责。收集到的邮箱、用户名、手机号属于个人信息处理时要遵守个人信息保护相关法规不能随意存储、转卖或公开。渗透测试项目要提前确认授权范围包含“信息收集阶段”并保留授权文档。这部分不是形式要求。防守方用 SpiderFoot 梳理自身资产红队在授权范围内做预演这两类场景都符合工具的设计初衷。8.2 生产环境部署要点如果要把 SpiderFoot 长期跑在服务器上而不是本机实验至少要考虑这些维度建议访问控制前置反向代理启用 TLS配置强密码和登录限制数据隔离数据库和日志挂载到独立磁盘方便备份和迁移日志监控保留扫描日志接入日志平台关注异常扫描行为API Key 管理密钥统一管理定期轮换不进入代码仓库任务调度用 CI 或定时任务触发扫描避免人为漏跑资源限制为容器或进程设置 CPU、内存、磁盘上限反向代理示例Nginx 片段server { listen 443 ssl; server_name osint.example.internal; ssl_certificate /etc/nginx/certs/server.crt; ssl_certificate_key /etc/nginx/certs/server.key; location / { proxy_pass http://127.0.0.1:5001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这样外部访问只看到 443 端口SpiderFoot 本身仍监听在内网地址。8.3 与其他工具配合使用SpiderFoot 最常用的配合方式有三种与漏洞扫描器配合用 SpiderFoot 做资产发现把发现的域名和 IP 清单导入漏洞扫描器做深度检查。与资产管理系统配合把扫描结果导出成 JSON 或数据库读表方式定期同步到 CMDB形成资产台账。与威胁情报平台配合SpiderFoot 关联分析发现了恶意 IP 或泄露邮箱后把线索推到威胁情报平台做进一步研判。配合的关键是统一数据格式。建议先固定字段映射关系事件类型、数据、来源、风险、时间再推给下游避免下游解析不稳定。8.4 扩展方向与学习路径对 SpiderFoot 本身可以继续深入的方向有两个一是研究关联规则的写法理解工具是怎么把孤立事件串成线索的二是阅读自己常用模块的源码看它如何解析数据源返回结果这对自己编写自定义数据源集成很有帮助。如果你是想把 OSINT 做成体系建议按这条路径学熟练使用 CLI 和 Web UI能独立完成一个域名的全流程扫描。掌握事件类型和风险字段能读懂导出结果。学会配置 API Key理解不同数据源的能力差异。用 SQLite 查询或 API 方式把扫描结果集成到自己的平台。最后再研究关联规则和自定义模块。新人最容易犯的错误是拿到工具先把全部模块打开跑一遍结果数据量巨大、噪声很多反而不知道怎么用。更稳妥的做法是第一轮只跑被动模块和 DNS 模块把结果读一遍第二轮再逐步增加主动模块和需要 API Key 的数据源。SpiderFoot 的价值不在“跑出多少条数据”而在于把分散的公开信息整理成可追踪、可复现、可关联的结构化数据。把这个流程跑顺后续的资产梳理和授权渗透测试都会省下大量时间。