Saturday, 24 October 2020

Mitigating "SSL Medium Strength Cipher Suites Supported" warnings from Nessus scans

 It's been a while, but I'm back in the world of IBM Cloud Private (ICP), specifically mitigating a cipher warning message from a Nessus endpoint scan.

One of my z/Linux boxes, running Red Hat Enterprise Linux, threw up a warning: -

SSL Medium Strength Cipher Suites Supported 192.168.1.242:10259 / tcp

via a Nessus endpoint scan.

I used a simple piece of detective work to find out WHAT was listening on port 10259 : -

netstat -aonp|grep 10259

which returned: -

tcp6       0      0 :::10259                :::*                    LISTEN      45537/hyperkube      off (0.00/0/0)

and then used: -

ps auxw|grep 45537

to inspect the specific process ID ( PID ), which returned: -

root     45537  0.2  0.1 907488 61804 ?        Ssl  11:14   0:06 /hyperkube kube-scheduler --master=https://127.0.0.1:8001 --kubeconfig=/etc/cfc/conf/kube-scheduler-config.yaml --policy-config-file=/etc/cfc/conf/scheduler-policy-config.json --use-legacy-policy-config=true --v=2 --profiling=false --leader-elect=true

This confirmed that it was the kube-scheduler component of Kubernetes (K8s) - IBM Cloud Private is a distribution of K8s, as is Red Hat OpenShift Container Platform ( RHOCP ).

This K8s documentation: -

kube-scheduler

describes how the SSL/TLS ciphers for kube-scheduler can be modified using the --tls-cipher-suites switch.

This document: -

Modifying Cipher Suites used by Kubernetes in IBM Cloud Private

then describes the specifics for ICP, namely updating /etc/cfc/pods/master.json to include  --tls-cipher-suites for the scheduler Pod.

Once I backed up, and then edited, this file, the Pod was automatically restarted, and the Nessus scan ran cleanly.


No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...