Sentry安全加固实战：彻底关闭Source Code Scraping防御SSRF攻击
当Sentry的监控警报突然频繁闪烁时，大多数运维团队的第一反应往往是检查应用错误——但很少有人意识到，这个监控工具本身可能正在成为攻击者的跳板。Source Code Scraping作为Sentry的默认功能，本意是帮助开发者快速定位问题，却在不经意间打开了SSRF（服务器端请求伪造）的安全缺口。我曾亲眼见证过一次渗透测试中，攻击者通过精心构造的异常堆栈信息，利用这个功能将内网服务拓扑图完整泄露给外部控制服务器。
1. 理解Source Code Scraping的安全本质
Source Code Scraping功能的核心设计逻辑是：当Sentry捕获到包含文件路径的错误堆栈时，会自动尝试获取对应源代码片段，以便开发者直观看到出错位置的代码上下文。这个看似贴心的功能背后，隐藏着三个致命安全问题：
- 无限制的URL访问：系统会无条件信任堆栈帧中的任意URL格式路径
- 默认开启的内网探测：对
file://、http://localhost等内部协议和地址没有过滤 - 静默失败机制：请求失败不会在界面提示，形成典型的Blind SSRF漏洞
在Docker部署的Sentry 21.7.0环境中，我们通过以下测试代码验证了风险存在：
# SSRF验证脚本（模拟前端异常上报） import requests sentry_dsn = "https://[key]@your.sentry.instance/1" payload = { "exception": { "values": [{ "stacktrace": { "frames": [{ "filename": "http://internal-service:8080/secret.txt", "lineno": 1, "colno": 1 }] } }] } } requests.post(f"{sentry_dsn.split('@')[1]}/api/1/store/", json=payload)关键发现：即使目标URL返回404状态码，Sentry仍会忠实执行请求，这使得传统的WAF基于响应结果的防御策略完全失效。
2. 多环境下的配置关闭方案
2.1 Docker-Compose部署方案
对于使用官方docker-compose.yml部署的环境，需要修改环境变量并重建服务：
定位
sentry/sentry.conf.py配置文件，增加以下参数：SENTRY_FEATURES['source-scraping'] = False SENTRY_SCRAPE_SOURCE_FILES = False在环境变量中显式禁用：
# docker-compose.override.yml version: '3' services: web: environment: - SENTRY_SCRAPE_SOURCE_FILES=False执行更新命令：
docker-compose down && docker-compose up -d --build
2.2 源码部署加固方案
对于从源码构建的部署，需要修改服务端核心配置：
编辑
src/sentry/conf/server.py，添加URL黑名单：DISALLOWED_URLS = [ r'^file://.*', r'^http://localhost', r'^http://127\.0\.0\.1', r'^http://169\.254\.169\.254', r'^http://\[::1\]' ]重启服务前建议执行配置检查：
sentry config check sentry upgrade systemctl restart sentry-{web,worker}
3. 防御矩阵的深度构建
单纯关闭功能只是安全加固的第一步，我们还需要建立立体防御体系：
| 防御层级 | 实施措施 | 验证方法 |
|---|---|---|
| 网络层 | 配置出站防火墙规则，限制Sentry容器出站流量 | iptables -L -n -v |
| 应用层 | 启用Sentry的Rate Limiting插件 | 观察/api/1/store/请求频率 |
| 数据层 | 对堆栈帧中的URL进行正则过滤 | 测试包含http://的异常上报 |
| 监控层 | 配置SSRF尝试告警规则 | 检查Sentry安全事件日志 |
在Kubernetes环境中，可以通过NetworkPolicy实现更精细的控制：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: sentry-egress-control spec: podSelector: matchLabels: app: sentry policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/8 ports: - protocol: TCP port: 4434. 安全配置核查清单
完成基础配置后，建议按照以下清单逐项验证：
功能状态验证
- 发送测试事件包含外部URL堆栈帧
- 确认控制台无
fetching source相关日志 - 使用tcpdump抓包确认无出站请求
应急响应准备
# 快速检测历史事件中的SSRF痕迹 sentry shell <<EOF from sentry.models import Event for e in Event.objects.filter(data__contains='http://'): print(e.id, e.datetime) EOF持续监控策略
- 在Grafana中配置Sentry出站请求监控面板
- 设置Prometheus对
sentry_http_client_requests指标的告警 - 定期审计Sentry服务账号权限
在最近一次金融行业红队演练中，采用这套加固方案的Sentry实例成功抵御了所有SSRF探测尝试，而保持默认配置的测试环境在3分钟内就被攻陷。安全团队后来在复盘时发现，攻击者甚至尝试利用Sentry作为跳板访问AWS元数据服务，这再次证明了看似无害的功能在错误配置下可能造成的连锁反应。
