SonarSearch安全与运维指南：API限流、数据合规与高可用部署

SonarSearch安全与运维指南：API限流、数据合规与高可用部署

【免费下载链接】SonarSearch A rapid API for the Project Sonar dataset 项目地址: https://gitcode.com/gh_mirrors/so/SonarSearch

SonarSearch 安全与运维是自建子域名枚举与反向 DNS 查询服务时必须面对的三大课题。SonarSearch 是一个基于 Go 语言构建的极速 API 服务，专门为 Rapid7 Project Sonar 数据集提供毫秒级查询能力，让你轻松完成子域名枚举（给定域名查询其全部子域名）与反向 DNS 查询（给定 IP 或 CIDR 网段查询对应域名）。本文是一份面向运维新手与安全工程师的完整指南，围绕 API 限流、数据合规、高可用部署 三条主线，手把手教你安全、合规、稳定地运行自己的 SonarSearch 实例。

---

一、先认识 SonarSearch：四个组件各司其职

在开始安全加固之前，先快速了解 SonarSearch 的整体架构。整个项目由四个组件构成，构建与安装方式非常简单：

组件	作用	对应模块
sonar2crobat	将 Project Sonar 原始数据集转换为 SonarSearch 内部格式	cmd/sonar2crobat
crobat2index	为域名、IP 生成快速查找索引	cmd/crobat2index/main.go
crobat-server	核心 API 服务器，同时提供 REST 与 gRPC 两套接口	cmd/crobat-server/main.go
crobat	官方命令行客户端，通过 gRPC 流式拉取结果	cmd/crobat/main.go

REST 服务默认监听 1998 端口，gRPC 服务默认监听 1997 端口，两者由 cmd/crobat-server/main.go 在一个进程内同时启动。REST 接口包含五个常用端点：

• /subdomains/{domain}：查询某个域名的全部子域名
• /tlds/{domain}：查询某域名出现的所有顶级域
• /all/{domain}：跨所有顶级域汇总结果
• /reverse/{ip}：对单个 IP 做反向 DNS 查询
• /reverse/{ip}/{mask}：对 CIDR 网段做反向 DNS 查询

gRPC 接口则在 proto/crobat.proto 中定义了 GetSubdomains、GetTLDs、ReverseDNS、ReverseDNSRange 四个流式方法，适合大批量查询，能显著降低服务器负载。📌 记住一点：官方公开实例已因数据源授权问题下线，自建实例才是可靠的选择。

---

二、为什么 SonarSearch 必须做安全加固？

这是很多人容易忽略的关键点：SonarSearch 的 API 默认没有任何认证机制。项目文档中明确写着 "No authentication is required"，意味着任何知道服务地址的人都能直接调用你的查询接口。这带来三重风险：

• ⚠️ 资源耗尽：反向 DNS 查询可指定任意 CIDR 网段，恶意请求可能瞬间拖垮服务器。
• ⚠️ 数据被批量爬取：子域名与 IP 对应关系属于敏感测绘数据，容易被批量抓走。
• ⚠️ 流量滥用：无认证的开放接口容易被他人当作免费代理工具使用。

此外，查询处理采用固定的 worker 池（见 pkg/search/domains.go 中的 NewDomainPool，默认只有 5 个 worker），并且单条记录扫描有 100ms 超时保护。当并发请求超过处理能力时，大量请求会排队甚至超时。因此，API 限流是 SonarSearch 自建部署的第一道安全防线。

---

三、如何为 SonarSearch API 配置限流

3.1 方案一：Nginx 反向代理限流（最推荐，零代码改动）

Nginx 是目前最简单、最稳妥的限流方案。在 SonarSearch 前面加一层 Nginx，通过 limit_req 模块控制请求速率。核心配置如下：

http {
    # 定义限流区域：按 IP 维度，每秒 10 个请求，突发 20 个
    limit_req_zone $binary_remote_addr zone=sonar:10m rate=10r/s;

    server {
        listen 80;
        # REST 接口代理到 SonarSearch 的 1998 端口
        location / {
            limit_req zone=sonar burst=20 nodelay;
            proxy_pass http://127.0.0.1:1998;
            proxy_set_header Host $host;
        }
    }
}

💡 将 rate=10r/s 按你的实际业务量调整。反向 DNS 的 CIDR 查询开销较大，可以单独为 /reverse/ 路径配置更严格的速率限制。

3.2 方案二：应用层限流（适合需要精细化控制的场景）

如果希望限流逻辑内置于服务本身，可以扩展 cmd/crobat-server/rest/server.go，在 NewRouter() 中为路由挂载中间件。例如使用 Go 的 golang.org/x/time/rate 实现基于令牌桶的限流，按用户 IP 或 API Key 分别计数，超限时直接返回 429 Too Many Requests。

3.3 限流参数推荐表

接口类型	建议速率	说明
子域名查询 /subdomains/	20 QPS	查询开销小，可适当放宽
反向 DNS /reverse/{ip}	10 QPS	单 IP 查询，中等开销
CIDR 查询 /reverse/{ip}/{mask}	2 QPS	网段越大开销越高，务必收紧
gRPC 流式接口	按连接数限制	建议配合连接数上限

---

四、SonarSearch 数据合规要点

4.1 数据集本身的合规风险

SonarSearch 的数据来源是 Rapid7 的 Project Sonar 数据集。这是一个必须重视的合规事实：Rapid7 已撤销该数据集的公开访问权限，且数据许可条款也发生了变更，官方托管的 omnisint API 因此下线。这意味着：

• ❌ 不能继续使用历史遗留的公开下载渠道获取数据集。
• ✅ 必须通过合法授权渠道获取 Project Sonar 数据，例如与 Rapid7 签订数据使用协议。
• ✅ 自行部署时，应留存数据来源与授权证明，以备合规审计。

4.2 数据使用合规 checklist

子域名、IP 与域名对应关系属于网络测绘类数据，在部分司法辖区受个人信息与网络安全法规约束。建议遵循以下清单：

•  确认数据集的授权许可范围，禁止转售或对外提供原始数据下载
•  仅向经过认证的内部用户开放 API，避免公开暴露
•  在服务条款中明确数据用途限制，禁止用于未授权扫描或攻击行为
•  定期评估数据合规风险，关注 Project Sonar 数据政策变化
•  记录查询日志，便于发生问题时追溯数据流向

⚠️ 合规是安全运维的地基：即使技术上限流做得再完美，数据来源不合法也可能带来法律风险。

---

五、SonarSearch 高可用部署实战

5.1 部署前硬件规划

SonarSearch 对资源有明确要求，至少需要 150~200GB 磁盘空间 存放数据集与索引文件。内存需求取决于索引后端的选择：

索引后端	内存需求	索引加载速度	查询速度	适用场景
Redis	约 20GB RAM	快	快	高并发、海量查询
Postgres	2~4GB 左右	慢	较慢	低内存、查询量适中

💡 如果预期查询量极大，选 Redis；追求低成本与低内存占用，选 Postgres。项目目前对 Postgres 的支持标记为 experimental，生产环境建议先用 Redis 验证稳定性。

5.2 快速搭建步骤

第一步：编译安装工具

git clone https://gitcode.com/gh_mirrors/so/SonarSearch
cd SonarSearch
make
make install

第二步：启动 Postgres 容器（如选 Postgres 作为索引后端）

docker run --name sonarsearch_postgres --expose 5432 -p 5432:5432 \
  -v /var/lib/sonar_search:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=postgres -d postgres

第三步：创建索引表

psql -U postgres -h 127.0.0.1 -d postgres -c "CREATE TABLE crobat_index (id serial PRIMARY KEY, key text, value text)"

第四步：转换并排序数据集

gunzip < fdns_a.json.gz | sonar2crobat -i - -o crobat_unsorted
sort -k1,1 -k2,2 -t, crobat_unsorted_domains > crobat_sorted_domains
sort -k1,1 -t, -n crobat_unsorted_reverse > crobat_sorted_reverse

第五步：生成并导入索引

crobat2index -i crobat_sorted_domains -f domain -backend postgres | \
  psql -U postgres -h 127.0.0.1 -d postgres -c "COPY crobat_index(key, value) from stdin (Delimiter ',')"
crobat2index -i crobat_sorted_reverse -f reverse -backend postgres | \
  psql -U postgres -h 127.0.0.1 -d postgres -c "COPY crobat_index(key, value) from stdin (Delimiter ',')"

第六步：启动服务器

CROBAT_POSTGRES_URL=postgres://postgres:postgres@localhost:5432/postgres \
CROBAT_CACHE_BACKEND=postgres \
CROBAT_DOMAIN_FILE=/path/to/crobat_sorted_domains \
CROBAT_REVERSE_FILE=/path/to/crobat_sorted_reverse \
crobat-server

建议把环境变量写入独立的配置文件再 source，便于统一管理。配置项通过 viper 读取，前缀为 CROBAT（见 cmd/crobat-server/main.go）。

5.3 多实例水平扩展与负载均衡

SonarSearch 的服务器本身不持有索引数据，查询时通过 Redis/Postgres 获取文件偏移量，再直接扫描数据集文件（见 pkg/search/reverse.go 的 NewReverseSearch）。这种"索引在后端、文件只读"的设计让服务器天然无状态，非常适合水平扩展：

• 将数据集文件同步到多台服务器（如共享存储或 rsync）
• 每台服务器都运行 crobat-server
• 前端用 Nginx 做负载均衡，将请求分发到多个实例

upstream sonar_backend {
    server 10.0.0.1:1998;
    server 10.0.0.2:1998;
    server 10.0.0.3:1998;
}
server {
    listen 80;
    location / {
        proxy_pass http://sonar_backend;
    }
}

5.4 监控、日志与故障排查

部署完成后，务必建立基本监控。以下是常见故障速查表：

症状	可能原因	排查建议
查询返回超时	数据集文件被并发扫描、IO 瓶颈	查看日志中的 TIMEOUT ON 提示，增加 worker 数
gRPC 连接失败	1997 端口未开放或防火墙拦截	检查端口监听状态
索引找不到	Redis 中 key 缺失或未正确导入	检查 crobat2index 导入是否成功
数据全部为空	数据集过期或文件路径错误	核对 CROBAT_DOMAIN_FILE / CROBAT_REVERSE_FILE 配置

日志方面，查询超时信息会直接输出到服务器 stdout（格式为 TIMEOUT ON {query}），建议接入日志收集系统集中告警。监控重点指标包括：QPS、查询耗时、worker 队列长度、磁盘 IO 与内存占用。

---

六、安全运维三件事，缺一不可

回顾全文，SonarSearch 的自建运维可以浓缩为三句话：

1. 限流先行：用 Nginx 或应用层中间件为 API 加装限流，守住资源不被恶意请求耗尽。
2. 合规为基：通过合法渠道获取 Project Sonar 数据集，明确数据用途边界，留存授权证明。
3. 高可用兜底：合理选择 Redis/Postgres 索引后端，利用无状态架构水平扩展，配合监控日志保障服务稳定。

SonarSearch 本身是一款设计精良的高性能工具，但安全与运维能力才是它能否长期稳定服务的关键。按照本文的指南完成加固后，你就可以放心地把它投入生产环境，享受毫秒级子域名枚举与反向 DNS 查询带来的效率提升。🚀

【免费下载链接】SonarSearch A rapid API for the Project Sonar dataset 项目地址: https://gitcode.com/gh_mirrors/so/SonarSearch