最近,我正在处理 RHEL 7.8 主机的 Tenable Nessus Plugin #51192 问题,即“SSL 证书无法信任”。
Tenable Nessus 报告称,该漏洞是由 TCP 端口 8443、8444 和 9100 的“www”服务引起的
因此,我从该主机获取了“netstat -tulnp”的输出,并发现以下程序利用了上述 TCP 端口:
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 25514/openshift
tcp 0 0 0.0.0.0:8444 0.0.0.0:* LISTEN 85402/openshift
tcp6 0 0 :::9100 :::* LISTEN 3028/kube-rbac-prox
此外,我通过“ps”命令检查了这些程序并获得了以下详细信息:
PID TTY STAT TIME COMMAND
25514 ? Ssl 47024:19 openshift start master api --config=/etc/origin/master/master-config.yaml --loglevel=2
85402 ? Ssl 752:23 openshift start master controllers --config=/etc/origin/master/master-config.yaml --listen=https://0.0.0.0:8444 --loglevel=2
3028 ? Ssl 10:14 /usr/bin/kube-rbac-proxy --secure-listen-address=:9100 --upstream=http://127.0.0.1:9101/ --tls-cert-file=/etc/tls/private/tls.crt --tls-private-key-fil
看起来这些 openshift 或 k8s 的东西正在使用具有不正确 SSL 证书的 Web 服务。
只是想澄清哪些目标是修复此插件 #51192 SSL 证书的正确目标。是否应该仅对 Web SSL 证书进行修复? (不太确定这会如何影响使用 openshift/k8s web 的生产服务。)