1.漏洞信息

2.漏洞说明

• 扫描结果显示，目标主机的 2379(etcd-client) 和 2380(etcd-server) 端口存在以下两个安全配置缺陷：
  1. SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)
  漏洞说明：该漏洞也被称为 Sweet32​ 漏洞。它主要是因为服务端的 TLS 配置中仍然启用了老旧的 64位块加密算法（例如 3DES/Triple DES）。
  潜在风险：根据密码学中的“生日悖论”，当攻击者通过中间人劫持并截获大量的加密流量（通常需要传输约 32GB 的数据）后，可以通过特定的碰撞攻击，逐步推导出部分明文的敏感信息（如用户的 Session Cookie、身份认证令牌等），从而导致敏感信息泄露。
  2. 目标主机支持 RSA 密钥交换
  漏洞说明：这是一个不安全的加密算法配置。当前的 TLS 握手过程允许使用 RSA 算法来进行密钥交换。
  潜在风险：使用传统的 RSA 密钥交换最大的问题在于缺乏“前向保密”能力。这意味着，如果攻击者通过某种手段（如入侵服务器、中间人攻击长期监听）获取了该服务器的私钥，那么他就可以利用这个私钥，将过去一段时间内所有经过该服务器加密的历史通信流量全部解密还原出来。

3.漏洞修复

3.1 下载etcdctl工具

# github下载
wget https://github.com/etcd-io/etcd/releases/download/v3.5.11/etcd-v3.5.11-linux-amd64.tar.gz
# 解压
tar -xzvf etcd-v3.5.11-linux-amd64.tar.gz -C /data/k8sfile/etcd

3.2 备份etcd数据

（1）给etcd数据打快照

ETCDCTL_API=3 /data/k8sfile/etcd/etcd-v3.5.11-linux-amd64/etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /data/k8sfile/etcd/etcd-snapshot-$(date +%Y%m%d).db

• 执行完上边快照备份命令会有如下显示

{"level":"info","ts":"2026-06-11T11:42:55.326033+0800","caller":"snapshot/v3_snapshot.go:65","msg":"created temporary db file","path":"/data/k8sfile/etcd/etcd-snapshot-20260611.db.part"}
{"level":"info","ts":"2026-06-11T11:42:55.336566+0800","logger":"client","caller":"v3@v3.5.11/maintenance.go:212","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":"2026-06-11T11:42:55.336598+0800","caller":"snapshot/v3_snapshot.go:73","msg":"fetching snapshot","endpoint":"https://127.0.0.1:2379"}
{"level":"info","ts":"2026-06-11T11:42:56.393299+0800","logger":"client","caller":"v3@v3.5.11/maintenance.go:220","msg":"completed snapshot read; closing"}
{"level":"info","ts":"2026-06-11T11:42:57.473436+0800","caller":"snapshot/v3_snapshot.go:88","msg":"fetched snapshot","endpoint":"https://127.0.0.1:2379","size":"134 MB","took":"2 seconds ago"}
{"level":"info","ts":"2026-06-11T11:42:57.473521+0800","caller":"snapshot/v3_snapshot.go:97","msg":"saved","path":"/data/k8sfile/etcd/etcd-snapshot-20260611.db"}
Snapshot saved at /data/k8sfile/etcd/etcd-snapshot-20260611.db

（2）快照db备份文件数据验证

ETCDCTL_API=3 /data/k8sfile/etcd/etcd-v3.5.11-linux-amd64/etcdctl \
  --write-out=table \
  snapshot status /data/k8sfile/etcd/etcd-snapshot-$(date +%Y%m%d).db

• 执行完输出

Deprecated: Use `etcdutl snapshot status` instead.

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| 1a633b7b | 71636350 |       1995 |     134 MB |
+----------+----------+------------+------------+

3.3 弱密码敲门测试

# 测试 1：拿中危的纯静态 RSA 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:2379 -cipher "AES256-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

# 测试 2：拿高危的 3DES 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:2379 -cipher "DES-CBC3-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

• 修复前测试
  

# 测试 1：拿中危的纯静态 RSA 弱算法去敲门
echo | openssl s_client -connect 172.xx.x.96:2380 \
  -cert /etc/kubernetes/pki/etcd/peer.crt \
  -key /etc/kubernetes/pki/etcd/peer.key \
  -CAfile /etc/kubernetes/pki/etcd/ca.crt \
  -cipher "AES256-SHA" 2>&1 | grep -iE "Cipher|error|handshake"
  
# 测试 2：拿高危的 3DES 弱算法去敲门
echo | openssl s_client -connect 172.xx.x.96:2380 \
  -cert /etc/kubernetes/pki/etcd/peer.crt \
  -key /etc/kubernetes/pki/etcd/peer.key \
  -CAfile /etc/kubernetes/pki/etcd/ca.crt \
  -cipher "DES-CBC3-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

• 修复前测试
  

3.4 备份etcd 配置文件

# 不要备份到同级目录下，一定要备份到其他目录下，可能备份文件或者目录影响原文件
mkdir /root/manifests_backup/
cp /etc/kubernetes/manifests/etcd.yaml /root/manifests_backup/etcd.yaml.bak

3.5 漏洞修复，添加强加密白名单

vi /etc/kubernetes/manifests/etcd.yaml

## 向下找到 spec.containers.command 这一段。在已有的参数（比如 - etcd 等）下方，加上这行白名单配置：

## ⚠️ 注意： 保持 YAML 的 -  缩进与其他参数完全对齐，且参数名是 --cipher-suites（没有 tls- 前缀）。

spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://172.16.x.x:2379 # 这是原来的配置行，不需要动，主要是固定添加位置
    # 👇 把下面这行精准插入到这里
    - --cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    # ... 保留后续原有参数 ...

3.6 等待etcd自己重启

• 上边etcd.yaml文件保存后，不需要做其他操作，等 60 秒左右 etcd 重启完，咱们再用 openssl 探针扫它一下

3.7 验证漏洞是否修复
（1）2379 端口（面向客户端）： 它默认同时监听 127.0.0.1（本机）和真实 IP，所以咱们刚才用 127.0.0.1 探 2379 一下就通了。

# 测试 1：拿中危的纯静态 RSA 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:2379 -cipher "AES256-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

# 测试 2：拿高危的 3DES 弱算法去敲门
echo | openssl s_client -connect 127.0.0.1:2379 -cipher "DES-CBC3-SHA" 2>&1 | grep -iE "Cipher|error|handshake"

• 修复后测试

（2）2380 端口（面向集群节点）： 它是专门给其他 Master 节点同步数据用的。为了安全和路由明确，etcd 默认只把 2380 端口绑定在真实的网卡 IP 上，压根就没有监听 127.0.0.1。咱们去敲 127.0.0.1:2380 的门，里面根本没人，所以 openssl 直接抓瞎了（连接被拒绝），返回了空白。

• 修复后测试

至此，漏洞修复完成！！！