企业官网建设流程全解析

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确认依赖范围。

安装前先检查基础环境：

2.2 源码安装方式

源码安装适合需要看模块实现、改代码或二次开发的情况。先从 GitHub 拉取代码：

git clone https://github.com/smicallef/spiderfoot.git cd spiderfoot

然后安装依赖。建议先创建虚拟环境，避免污染系统 Python：

python3 -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 的扫描类型相当于预设模块组合。常见的有：

命令行执行时，-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") | .data'

3.4 常用参数速查

命令行帮助信息会随版本变化，但以下参数在大多数版本中通用：

注意：实际使用前要执行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 一个典型操作顺序

推荐新手按这个顺序操作：

1. 先用PASSIVE类型跑一个域名，确认登录、扫描、结果查看都正常。
2. 看事件列表，熟悉INTERNET_NAME、IP_ADDRESS、EMAILADDR等最常见事件类型。
3. 第二次扫描切到FOOTPRINT，观察模块数量增加后耗时的变化。
4. 导出 CSV，用表格软件分类汇总，确认数据可读取。

这样每一步都有明确检查点，不会一开始就被几十个模块的输出淹没。

5. 数据源与模块配置：扫描能力的上限取决于 API Key

5.1 模块分类与依赖

SpiderFoot 的 200 多个模块按数据源类型可以分成几类：

没有 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.db；Web UI 扫描的结果也写入该库。这意味着，即便浏览器关掉了，扫描数据仍然在，下次登录还能看到。

主要的数据表通常包括：

直接连数据库查结果时不推荐在 Web UI 运行期间写入，只读查询是可以的：

SELECT type, data, risk, confidence FROM tbl_scan_result WHERE scan_id = 1 ORDER BY risk DESC;

6.2 事件类型与风险字段

事件类型是理解结果的钥匙。常见事件类型包括：

每条事件还有两个重要字段：confidence表示这条数据可信度，来源越权威，置信度越高；risk表示风险级别，比如“邮箱账号在公开泄露数据中出现”会被标记为高风险。

风险字段不代表漏洞已经确认，它只是线索。是否构成真实风险，需要人工验证或结合其他工具确认。

6.3 通过 Web API 读取结果

新版本 SpiderFoot 提供 REST API，方便把扫描结果集成到自己的平台。接口的完整定义可以查看项目文档或在线接口说明。典型用法是：用登录后的认证信息创建扫描或读取扫描状态，再按扫描 ID 拉取事件列表。

集成时建议把 API 调用封装在独立服务里，不要让前端直接持有管理员凭据。读取结果后用 JSON 格式推给数据分析平台或资产管理系统，能和其他安全数据一起做关联。

7. 常见问题排查

7.1 扫描卡住或长时间无结果

现象：任务一直显示运行中，事件列表长时间没有新增。

排查顺序：

1. 先看扫描日志，确认当前卡在哪个模块。Web UI 的扫描详情页能看到日志，CLI 模式看控制台输出。
2. 判断是否是该数据源响应慢。很多公开数据源没有 SLA，偶发超时是常态。
3. 看模块是否有“API Key 未配置”提示，这类模块会等待或跳过。
4. 看网络环境是否能正常访问目标数据源。数据源超时需要检查防火墙和 DNS。
5. 如果卡在某个模块很久，可以在扫描配置里去掉该模块重跑，缩小范围。

处理建议：大范围扫描拆成多个小扫描，避免一个任务包含几百个模块。给关键数据源模块配置 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 长期跑在服务器上，而不是本机实验，至少要考虑这些：

反向代理示例（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 做成体系，建议按这条路径学：

1. 熟练使用 CLI 和 Web UI，能独立完成一个域名的全流程扫描。
2. 掌握事件类型和风险字段，能读懂导出结果。
3. 学会配置 API Key，理解不同数据源的能力差异。
4. 用 SQLite 查询或 API 方式把扫描结果集成到自己的平台。
5. 最后再研究关联规则和自定义模块。

新人最容易犯的错误是拿到工具先把全部模块打开跑一遍，结果数据量巨大、噪声很多，反而不知道怎么用。更稳妥的做法是：第一轮只跑被动模块和 DNS 模块，把结果读一遍，第二轮再逐步增加主动模块和需要 API Key 的数据源。

SpiderFoot 的价值不在“跑出多少条数据”，而在于把分散的公开信息整理成可追踪、可复现、可关联的结构化数据。把这个流程跑顺，后续的资产梳理和授权渗透测试都会省下大量时间。