当前位置： 首页 > news >正文

彩票网站开发与建设,中国包装设计网,三亚哪里做网站,全国工程建设行业优秀网站作者#xff1a;老 Z#xff0c;中电信数智科技有限公司山东分公司运维架构师#xff0c;云原生爱好者#xff0c;目前专注于云原生运维#xff0c;云原生领域技术栈涉及 Kubernetes、KubeSphere、DevOps、OpenStack、Ansible 等。 前言 测试服务器配置 主机名IPCPU内存系… 作者老 Z中电信数智科技有限公司山东分公司运维架构师云原生爱好者目前专注于云原生运维云原生领域技术栈涉及 Kubernetes、KubeSphere、DevOps、OpenStack、Ansible 等。 前言 测试服务器配置 主机名IPCPU内存系统盘数据盘用途zdeops-master192.168.9.92440200Ansible 运维控制节点ks-k8s-master-0192.168.9.9141640200200KubeSphere/k8s-master/k8s-workerks-k8s-master-1192.168.9.9241640200200KubeSphere/k8s-master/k8s-workerks-k8s-master-2192.168.9.9341640200200KubeSphere/k8s-master/k8s-workerstorage-node-0192.168.9.952840200200ElasticSearch/GlusterFSstorage-node-0192.168.9.962840200200ElasticSearch/GlusterFSstorage-node-0192.168.9.972840200200ElasticSearch/GlusterFSharbor192.168.9.892840200Harbor合计822843202800 测试环境涉及软件版本信息 操作系统CentOS-7.9-x86_64Ansible2.8.20KubeSphere3.3.0Kubernetesv1.24.1GlusterFS9.5.1ElasticSearch7.17.5Harbor2.5.1 简介 生产环境 KubeSphere 3.3.0 部署的 Kubernetes 集群在安全评估的时候发现安全漏洞其中一项漏洞提示 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)。 本文详细描述了漏洞产生原因、漏洞修复方案、漏洞修复的操作流程以及注意事项。 漏洞信息及修复方案 漏洞详细信息 漏洞报告中涉及漏洞 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183) 的具体信息如下 漏洞分析 分析漏洞报告信息我们发现漏洞涉及以下端口和服务 端口号服务2379/2380Etcd6443kube-apiserver10250kubelet10257kube-controller10259kube-scheduler 在漏洞节点 (任意 Master 节点) 查看、确认端口号对应的服务

ETCD

[rootks-k8s-master-0 ~]# ss -ntlup | grep Etcd | grep -v 127.0.0.1 tcp LISTEN 0 128 192.168.9.91:2379 : users:((Etcd,pid1341,fd7)) tcp LISTEN 0 128 192.168.9.91:2380 : users:((Etcd,pid1341,fd5))# kube-apiserver [rootks-k8s-master-0 ~]# ss -ntlup | grep 6443 tcp LISTEN 0 128 [::]:6443 [::]:* users:((kube-apiserver,pid1743,fd7))# kubelet [rootks-k8s-master-0 ~]# ss -ntlup | grep 10250 tcp LISTEN 0 128 [::]:10250 [::]:* users:((kubelet,pid1430,fd24))# kube-controller [rootks-k8s-master-0 ~]# ss -ntlup | grep 10257 tcp LISTEN 0 128 [::]:10257 [::]:* users:((kube-controller,pid19623,fd7))# kube-scheduler [rootks-k8s-master-0 ~]# ss -ntlup | grep 10259 tcp LISTEN 0 128 [::]:10259 [::]:* users:((kube-scheduler,pid1727,fd7)) 漏洞原因 相关服务配置文件里使用了 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 unknownNmap 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_GCMSHA384 (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | least strength: CNmap 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_GCMSHA384 (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | least strength: CNmap 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 (ecdhx25519) - A | cipher preference: server | least strength: CNmap done: 1 IP address (1 host up) scanned in 0.66 seconds 注意 扫描结果中重点关注 warnings64-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_SUITESTLS_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_SUITESTLS_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 漏洞修复 建议使用以下顺序修复漏洞 Etcdkube-apiserverkube-controllerkube-schedulerkubelet 上面的操作流程中重点是将 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_SUITESTLS_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,pid40160,fd7)) tcp LISTEN 0 128 127.0.0.1:2379 : users:((Etcd,pid40160,fd6)) tcp LISTEN 0 128 192.168.9.91:2380 : users:((Etcd,pid40160,fd5))# 持续观测 确保服务没有反复重启 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_GCMSHA384 (rsa 2048) - A | compressors: | NULL | cipher preference: client | least strength: ANmap 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-suitesTLS_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-suitesTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITHAES 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 (ecdhx25519) - A | cipher preference: server | least strength: ANmap 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-suitesTLS_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-credentialstrue 34 - –tls-cipher-suitesTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITHAES 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-suitesTLS_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-electtrue 20 - –tls-cipher-suitesTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITHAES 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_WITHAES 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, codeexited, status1/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_URLShttps://192.168.9.91:2379 Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated –loggercapnslog flag is set; use –loggerzap flag instead Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated –loggercapnslog flag is set; use –loggerzap flag instead Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_AUTO_COMPACTION_RETENTION8 …..省略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, codeexited, status1/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 发布