修复 K8s SSL/TLS 漏洞（CVE-2016-2183）指南
前言
测试服务器配置
| 主机名 | IP | CPU | 内存 | 系统盘 | 数据盘 | 用途 |
|---|---|---|---|---|---|---|
| zdeops-master | 192.168.9.9 | 2 | 4 | 40 | 200 | Ansible 运维控制节点 |
| ks-k8s-master-0 | 192.168.9.91 | 4 | 16 | 40 | 200+200 | KubeSphere/k8s-master/k8s-worker |
| ks-k8s-master-1 | 192.168.9.92 | 4 | 16 | 40 | 200+200 | KubeSphere/k8s-master/k8s-worker |
| ks-k8s-master-2 | 192.168.9.93 | 4 | 16 | 40 | 200+200 | KubeSphere/k8s-master/k8s-worker |
| storage-node-0 | 192.168.9.95 | 2 | 8 | 40 | 200+200 | ElasticSearch/GlusterFS |
| storage-node-0 | 192.168.9.96 | 2 | 8 | 40 | 200+200 | ElasticSearch/GlusterFS |
| storage-node-0 | 192.168.9.97 | 2 | 8 | 40 | 200+200 | ElasticSearch/GlusterFS |
| harbor | 192.168.9.89 | 2 | 8 | 40 | 200 | Harbor |
| 合计 | 8 | 22 | 84 | 320 | 2800 |
测试环境涉及软件版本信息
- 操作系统：CentOS-7.9-x86_64
- Ansible：2.8.20
- KubeSphere：3.3.0
- Kubernetes：v1.24.1
- GlusterFS：9.5.1
- ElasticSearch：7.17.5
- Harbor：2.5.1
简介
生产环境 KubeSphere 3.3.0 部署的 Kubernetes 集群在安全评估的时候发现安全漏洞，其中一项漏洞提示 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)。
本文详细描述了漏洞产生原因、漏洞修复方案、漏洞修复的操作流程以及注意事项。
漏洞信息及修复方案
漏洞详细信息
漏洞报告中涉及漏洞 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183) 的具体信息如下：
漏洞分析
- 分析漏洞报告信息，我们发现漏洞涉及以下端口和服务：
| 端口号 | 服务 |
|---|---|
| 2379/2380 | Etcd |
| 6443 | kube-apiserver |
| 10250 | kubelet |
| 10257 | kube-controller |
| 10259 | kube-scheduler |
- 在漏洞节点 (任意 Master 节点) 查看、确认端口号对应的服务：
# ETCD
[root@ks-k8s-master-0 ~]# ss -ntlup | grep Etcd | grep -v "127.0.0.1"
tcp LISTEN 0 128 192.168.9.91:2379 *:* users:(("Etcd",pid=1341,fd=7))
tcp LISTEN 0 128 192.168.9.91:2380 *:* users:(("Etcd",pid=1341,fd=5))
# kube-apiserver
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 6443
tcp LISTEN 0 128 [::]:6443 [::]:* users:(("kube-apiserver",pid=1743,fd=7))
# kubelet
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10250
tcp LISTEN 0 128 [::]:10250 [::]:* users:(("kubelet",pid=1430,fd=24))
# kube-controller
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10257
tcp LISTEN 0 128 [::]:10257 [::]:* users:(("kube-controller",pid=19623,fd=7))
# kube-scheduler
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10259
tcp LISTEN 0 128 [::]:10259 [::]:* users:(("kube-scheduler",pid=1727,fd=7))
- 漏洞原因：
相关服务配置文件里使用了 IDEA、DES 和 3DES 等算法。
- 利用测试工具验证漏洞：
可以使用 Nmap 或是 openssl 进行验证，本文重点介绍 Nmap 的验证方式。
注意：openssl 的方式输出太多且不好直观判断，有兴趣的可以参考命令
openssl s_client -connect 192.168.9.91:10257 -cipher "DES:3DES"。
在任意节点安装测试工具 Nmap ，并执行测试命令。
错误的姿势，仅用于说明选择 Nmap 版本很重要，实际操作中不要执行。
# 用 CentOS 默认源安装 nmap
yum install nmap
# 执行针对 2379 端口的 ssl-enum-ciphers 检测
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91
# 结果输出如下
Starting Nmap 6.40 ( http://nmap.org ) at 2023-02-13 14:14 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00013s latency).
PORT STATE SERVICE
2379/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
注意： 分析输出的结果发现并没有任何警告信息。原因是 Nmap 版本过低，需要 7.x 以上才可以。
正确的姿势，实际执行的操作：
# 从 Nmap 官网，下载安装新版软件包
rpm -Uvh https://nmap.org/dist/nmap-7.93-1.x86_64.rpm
# 执行针对 2379 端口的 ssl-enum-ciphers 检测
# nmap -sV --script ssl-enum-ciphers -p 2379 192.168.9.91 (该命令输出更为详细也更加耗时，为节省篇幅使用下面简单输出的模式)
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91
# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:28 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00013s latency).
PORT STATE SERVICE
2379/tcp open Etcd-client
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ecdh_x25519) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds
# 执行针对 2380 端口的 ssl-enum-ciphers 检测
nmap --script ssl-enum-ciphers -p 2380 192.168.9.91
# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:28 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00014s latency).
PORT STATE SERVICE
2380/tcp open Etcd-server
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ecdh_x25519) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds
# 执行针对 6443 端口的 ssl-enum-ciphers 检测（10250/10257/10259 端口扫描结果相同）
nmap --script ssl-enum-ciphers -p 6443 192.168.9.91
# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:29 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00014s latency).
PORT STATE SERVICE
6443/tcp open sun-sr-https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.3:
| ciphers:
| TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| cipher preference: server
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds
注意： 扫描结果中重点关注
warnings，64-bit block cipher 3DES vulnerable to SWEET32 attack。
漏洞修复方案
漏洞扫描报告中提到的修复方案并不适用于 Etcd、Kubernetes 相关服务。
针对于 Etcd、Kubernetes 等服务有效的修复手段是修改服务配置文件，禁用 3DES 相关的加密配置。
Cipher Suites 配置参数的选择，可以参考 ETCD 官方文档或是 IBM 私有云文档，网上搜到的很多配置都是参考的 IBM 的文档，想省事的可以拿来即用。
对于配置参数的最终选择，我采用了最笨的方法，即把扫描结果列出的 Cipher 值拼接起来。由于不清楚影响范围，所以保守的采用了在原有配置基础上删除 3DES 相关的配置。
下面的内容整理了 Cipher Suites 配置参数的可参考配置。
- 原始扫描结果中的 Cipher Suites 配置：
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- 原始扫描结果去掉 3DES 的 Cipher Suites 配置：
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
使用该方案时必须严格按照以下顺序配置，我在测试时发现顺序不一致会导致 Etcd 服务反复重启。
ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
虽然 CIPHER 配置一样，但是在使用下面的顺序时，Etcd 服务反复重启，我排查了好久也没确定根因。也可能是我写的有问题，但是比对多次也没发现异常，只能暂时是认为是顺序造成的。
ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
注意： 只有 Etcd 服务受到顺序的影响，kube 相关组件顺序不同也没发现异常。
- IBM 相关文档中的 Cipher Suites 配置：
网上搜到的参考文档使用率最高的配置。实际测试也确实好用，服务都能正常启动，没有发现 Etcd 不断重启的现象。如果没有特殊需求，可以采用该方案，毕竟选择越少出安全漏洞的几率也越小。
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
漏洞修复
建议使用以下顺序修复漏洞：
- Etcd
- kube-apiserver
- kube-controller
- kube-scheduler
- kubelet
上面的操作流程中，重点是将 Etcd 的修复重启放在最前面执行。因为 kube 等组件的运行依赖于 Etcd，我在验证时最后升级的 Etcd，当 Etcd 启动失败后（反复重启），其他服务由于无法连接 Etcd，造成服务异常停止。所以先确保 Etcd 运行正常再去修复其他组件。
本文所有操作仅演示了一个节点的操作方法，多节点存在漏洞时请按组件依次执行，先修复完成一个组件，确认无误后再去修复另一个组件。
以下操作是我实战验证过的经验，仅供参考，生产环境请一定要充分验证、测试后再执行！
修复 Etcd
- 编辑 Etcd 配置文件 /etc/Etcd.env：
KubeSpere 3.3.0 采用二进制的方式部署的 Etcd，相关配置文件包含 /etc/systemd/system/Etcd.service 和 /etc/Etcd.env，参数配置保存在 /etc/Etcd.env。
# 在文件最后增加配置(用 cat 命令自动配置)
cat >> /etc/Etcd.env << "EOF"
# TLS CIPHER SUITES settings
ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
EOF
- 重启 Etcd 服务：
# 重启服务
systemctl restart Etcd
# 验证服务已启动
ss -ntlup | grep Etcd
# 正确的结果如下
tcp LISTEN 129 128 192.168.9.91:2379 *:* users:(("Etcd",pid=40160,fd=7))
tcp LISTEN 0 128 127.0.0.1:2379 *:* users:(("Etcd",pid=40160,fd=6))
tcp LISTEN 0 128 192.168.9.91:2380 *:* users:(("Etcd",pid=40160,fd=5))
# 持续观测 确保服务没有反复重启
watch -n 1 -d 'ss -ntlup | grep Etcd'
注意： 如果是多节点模式，一定要所有节点都修改完配置文件，然后，所有节点同时重启 Etcd 服务。重启过程中会造成 Etcd 服务中断，生产环境谨慎操作。
- 验证漏洞是否修复：
# 执行扫描命令
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91
# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 17:48 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00015s latency).
PORT STATE SERVICE
2379/tcp open Etcd-client
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds
# 为了节省篇幅，2380 端口扫描完整输出结果略,实际结果与 2379 端口一致
# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 2380 192.168.9.91 | grep SWEET32
修复 kube-apiserver
- 编辑 kube-apiserver 配置文件
/etc/kubernetes/manifests/kube-apiserver.yaml：
# 新增配置(在原文件 47 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
# 新增后的效果如下（不截图了，增加了行号显示用来区分）
46 - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
47 - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
48 - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_ 256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
- 重启 kube-apiserver：
不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。
- 验证漏洞：
# 执行扫描命令
nmap --script ssl-enum-ciphers -p 6443 192.168.9.91
# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 09:22 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00015s latency).
PORT STATE SERVICE
6443/tcp open sun-sr-https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.3:
| ciphers:
| TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| cipher preference: server
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds
注意：对比之前的漏洞告警信息，扫描结果中已经不存在
64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。
修复 kube-controller
- 编辑 kube-controller 配置文件
/etc/kubernetes/manifests/kube-controller-manager.yaml：
# 新增配置(在原文件 33 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
# 新增后的效果如下（不截图了，增加了行号显示用来区分）
33 - --use-service-account-credentials=true
34 - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_ 256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
- 重启 kube-controller：
不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。
- 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10257 192.168.9.91
# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致
# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10257 192.168.9.91 | grep SWEET32
注意：对比之前的漏洞告警信息，扫描结果中已经不存在
64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。
修复 kube-scheduler
- 编辑 kube-scheduler 配置文件
/etc/kubernetes/manifests/kube-scheduler.yaml：
# 新增配置(在原文件 19 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
# 新增后的效果如下（不截图了，增加了行号显示用来区分）
19 - --leader-elect=true
20 - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_ 256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
- 重启 kube-scheduler：
不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。
- 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10259 192.168.9.91
# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致
# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10259 192.168.9.91 | grep SWEET32
注意：对比之前的漏洞告警信息，扫描结果中已经不存在
64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。
修复 kubelet
- 编辑 kubelet 配置文件
/var/lib/kubelet/config.yaml：
# 在配置文件最后添加
tlsCipherSuites: [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
提示： 更多的 cipher suites 配置，请参考 Kubernetes 官方文档。
- 重启 kubelet：
systemctl restart kubelet
重启有风险，操作需谨慎！
- 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10250 192.168.9.91
# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致
# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10250 192.168.9.91 | grep SWEET32
注意： 对比之前的漏洞告警信息，扫描结果中已经不存在
64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。
常见问题
Etcd 启动失败
报错信息：
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Etcd Version: 3.4.13
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Git SHA: ae9734ed2
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Go Version: go1.12.17
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Go OS/Arch: linux/amd64
Feb 13 16:17:41 ks-k8s-master-0 Etcd: setting maximum number of CPUs to 4, total number of available CPUs is 4
Feb 13 16:17:41 ks-k8s-master-0 Etcd: the server is already initialized as member before, starting as Etcd member...
Feb 13 16:17:41 ks-k8s-master-0 Etcd: unexpected TLS cipher suite "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
Feb 13 16:17:42 ks-k8s-master-0 systemd: Etcd.service: main process exited, code=exited, status=1/FAILURE
Feb 13 16:17:42 ks-k8s-master-0 systemd: Failed to start Etcd.
Feb 13 16:17:42 ks-k8s-master-0 systemd: Unit Etcd.service entered failed state.
Feb 13 16:17:42 ks-k8s-master-0 systemd: Etcd.service failed.
解决方案：
删除配置文件中的 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 字段，至于原因没有深入研究。
Etcd 服务不断重启
报错信息 (省略掉了一部分)：
修改配置文件后，重新启动 Etcd，启动的时候命令执行没有报错。但是，启动后查看 status 有异常，且 /var/log/messages 中有如下信息
Feb 13 16:25:55 ks-k8s-master-0 systemd: Etcd.service holdoff time over, scheduling restart.
Feb 13 16:25:55 ks-k8s-master-0 systemd: Stopped Etcd.
Feb 13 16:25:55 ks-k8s-master-0 systemd: Starting Etcd...
Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=https://192.168.9.91:2379
Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_AUTO_COMPACTION_RETENTION=8
.....（省略）
Feb 13 16:25:58 ks-k8s-master-0 systemd: Started Etcd.
Feb 13 16:25:58 ks-k8s-master-0 Etcd: serving client requests on 192.168.9.91:2379
Feb 13 16:25:58 ks-k8s-master-0 Etcd: serving client requests on 127.0.0.1:2379
Feb 13 16:25:58 ks-k8s-master-0 Etcd: accept tcp 127.0.0.1:2379: use of closed network connection
Feb 13 16:25:58 ks-k8s-master-0 systemd: Etcd.service: main process exited, code=exited, status=1/FAILURE
Feb 13 16:25:58 ks-k8s-master-0 systemd: Unit Etcd.service entered failed state.
Feb 13 16:25:58 ks-k8s-master-0 systemd: Etcd.service failed.
解决方案：
在实际测试中遇到了两种场景都产生了类似上面的报错信息：
第一种，在多节点 Etcd 环境中，需要先修改所有节点的 Etcd 配置文件，然后，同时重启所有节点的 Etcd 服务。
第二种，Etc Cipher 参数顺序问题，不断尝试确认了最终顺序后（具体配置参考正文），反复重启的问题没有再现。
本文由博客一文多发平台 OpenWrite 发布！
修复 K8s SSL/TLS 漏洞（CVE-2016-2183）指南的更多相关文章
- (转)SSL/TLS 漏洞“受戒礼”,RC4算法关闭
原文:https://blog.csdn.net/Nedved_L/article/details/81110603 SSL/TLS 漏洞“受戒礼” 一.漏洞分析事件起因2015年3月26日,国外数据 ...
- SSL/TLS 漏洞“受戒礼”,RC4算法关闭
SSL/TLS 漏洞"受戒礼" 一.漏洞分析 事件起因 2015年3月26日,国外数据安全公司Imperva的研究员Itsik Mantin在BLACK HAT ASIA 2015 ...
- CVE-2016-2183(SSL/TLS)漏洞的办法
运行gpedit.msc,打开"本地组策略编辑器" 启用"SSL密码套件顺序" TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_ ...
- SSL/TLS 受诫礼(BAR-MITZVAH)攻击漏洞(CVE-2015-2808)
最近发现SSL/TLS漏洞已经修改过,但是绿盟扫描器还可以扫描出来,网上看了很多文章,但是能用的比较少,今天刚好有空,就自己写一下. 方法一: 控制面板--->系统和安全--->管理工具- ...
- CVE-2013-2566 SSL/TLS RC4 信息泄露漏洞 修复方案
详细描述 安全套接层(Secure Sockets Layer,SSL),一种安全协议,是网景公司(Netscape)在推出Web浏览器首版的同时提出的,目的是为网络通信提供安全及数据完整性.SSL在 ...
- Nginx升级加固SSL/TLS协议信息泄露漏洞(CVE-2016-2183)
Nginx升级加固SSL/TLS协议信息泄露漏洞(CVE-2016-2183) 漏洞说明 // 基于Nginx的https网站被扫描出SSL/TLS协议信息泄露漏洞(CVE-2016-2183),该漏 ...
- 使用openSSL开源工具进行SSL/TLS 安全测试
本文介绍了使用半自动化工具执行SSL&TLS安全性评估的过程,以及如何使用手动及工具的测试方法验证并发现问题.目的是优化TLS和SSL安全测试流程,帮助信息安全顾问在渗透测试时在TLS / S ...
- SSL/TLS 安全测试
本文介绍了使用半自动化工具执行SSL&TLS安全性评估的过程,以及如何使用手动及工具的测试方法验证并发现问题.目的是优化TLS和SSL安全测试流程,帮助信息安全顾问在渗透测试时在TLS / S ...
- SSL&TLS渗透测试
什么是TLS&SSL? 安全套接字层(SSL)和传输层安全(TLS)加密通过提供通信安全(传输加密)和为应用程序如网络.邮件.即时消息和某些虚拟私有网络(VPN)提供隐私的方式来确保互联网和网 ...
- [译]SSL/TLS真的被BEAST攻击攻破了吗？真实情况是怎样的？我应该做什么？
原文链接:https://luxsci.com/blog/is-ssltls-really-broken-by-the-beast-attack-what-is-the-real-story-what ...
随机推荐
- 神州笔记本 win11 节能模式 供电不足 自动关机
刚刚买了一个神州笔记本没几天,用着用着就出现问题了. 本人使用电脑有个极为不好的习惯,那就是会一次性打开特别多的应用,然后不关,一直留着,这个习惯虽然不好但也是一直没有啥问题的,不过最近换了个新的笔记 ...
- git警告信息：Encountered 1 file(s) that may not have been copied correctly on Windows: —— See: `git lfs help smudge` for more details.
git报警信息: 官方讨论的帖子: https://github.com/git-lfs/git-lfs/issues/2434 说下个人的理解: 在git管理中,对于大文件(一般为压缩后的二进制文件 ...
- 《最新出炉》系列初窥篇-Python+Playwright自动化测试-63 - Canvas和SVG元素定位
1.简介 今天宏哥分享的在实际测试工作中很少遇到,比较生僻,如果突然遇到我们可能会脑大.懵逼,一时之间不知道怎么办?所以宏哥这里提供一种思路供大家学习和参考. 2.SVG简介 svg也是html5新增 ...
- [USACO09JAN] Safe Travel G 题解
UPDATE on 2024.5.10 删去左偏树代码中令人误解的 fa 数组. 前话 题目链接:洛谷. 貌似别人都是使用并查集维护的方法,然而由于排序.最短路等算法瓶颈,以下令 \(n\) 和 \( ...
- JVM指令大全之不太全系列
一.未归类系列A 此系列暂未归类. 指令码 助记符 说明0x00 nop ...
- Python开发中，SQLAlchemy 的同步操作和异步操作封装，以及常规CRUD的处理。
在我们使用Python来和数据库打交道中,SQLAlchemy是一个非常不错的ORM工具,通过它我们可以很好的实现多种数据库的统一模型接入,而且它提供了非常多的特性,通过结合不同的数据库驱动,我们可以 ...
- 玄机蓝队靶场_应急响应_02:apache日志分析
日志分析这块,感觉都是对grep.awk.sort.wc.uniq,这几个命令的使用. 一:靶场 (1)直接cd到linux日志, cd /var/log 发现apache2目录, cd ./apac ...
- C# Winform 使用 BarTender打印条码
目录 - 1. 使用软件BarTender 设计打印模板 - 2. Winfrom集成打印 - 3.最终效果 - 1. 使用软件BarTender 设计打印模板 贴一个入门级使用教程:https:// ...
- Docker 优化NUXT镜像体积
FROM node:xxx-alpine # 环境变量赋值 ENV 参数名 参数值 RUN mkdir -p /app COPY ./app/package.json /app/package.jso ...
- 如何高效的阅读paper--三遍阅读法
第一遍 1.阅读文章的标题.摘要和介绍 2.阅读每一节的标题和副标题 3.阅读总结 4.浏览参考文献,看看是否有曾经读过的文章 在完成第一遍后,应该做到: 1.能够说出该篇论文的类型 2.能够说出文章 ...