2004 是什么
2004 是 Graphite 监控体系中 carbon 组件接收序列化数据的端口：客户端把一批指标一次性序列化后提交，比逐行文本发送效率更高，适合高频、大批量的指标上报。它是文本接收端口之外的高吞吐选项，两者在配置中分别开关。
风险不在数据本身
风险来自反序列化过程：在 Python 生态中，这类数据可以触发任意代码执行，而接收端默认不做来源认证。因此暴露这个端口不只是数据泄露问题，而是给攻击者提供了一条代码执行通道，风险等级高于多数数据库端口。
基本信息
| 服务 | carbon 的高吞吐数据接收端口 |
|---|---|
| 协议 | TCP 2004 |
| 用途 | 批量指标上报 |
| 数据形态 | Python pickle 序列化 |
| 安全等级 | 严禁暴露，建议关闭接收端 |
典型使用场景
- 高频监控场景下批量提交指标，降低连接开销
- 排查指标缺失时确认接收端口与上报客户端是否匹配
- 梳理监控链路时确认还有哪些组件在用这条通道
- 安全核查时确认该端口是否仅对采集网段开放
- 替换为更安全协议过程中的过渡期评估
检查监听与配置
检查监听与配置
ss -lntp | grep 2004 # 确认监听地址
# carbon.conf 中控制该接收端口
grep -n 'PICKLE_RECEIVER_PORT' /opt/graphite/conf/carbon.conf收紧措施
收紧措施
# 如无必要，直接关闭该接收端
# PICKLE_RECEIVER_PORT = 0 # 置零表示不监听
# 或限制监听地址
# PICKLE_RECEIVER_HOST = 127.0.0.1
# 修改后重启 carbon 服务接收形态对照
| 接收形态 | 端口 | 说明 |
|---|---|---|
| 序列化批量提交 | 2004 | 吞吐更高，风险也更高 |
| 逐行文本提交 | 2003 | 兼容性好，可读性强 |
| 查询与绘图 | 由 Web 组件承担 | 与数据接收端口相互独立 |
这条通道暴露出去不是数据泄露级别的问题，而是远程代码执行级别的问题：在没有来源认证的前提下，任何可达主机都可以尝试投递恶意构造的数据。
新部署建议优先使用文本或结构化协议上报，只在确有吞吐压力且能限定来源网段时保留该通道，并在配置里把接收地址限制为本机或采集网段。