Nessus Essentials on Tanzu Community Edition
Now that VMware has released vCenter 7.0U3c to resolve the Log4Shell vulnerabilities I thought it might be fun to run a security scan against the upgraded VCSA in my homelab to see how it looks. Of course, I don't actually have a security scanner in that environment so I'll need to deploy one.
I start off by heading to tenable.com/products/nessus/nessus-essentials to register for a (free!) license key which will let me scan up to 16 hosts. I'll receive the key and download link in an email, but I'm not actually going to use that link to download the Nessus binary. I've got this shiny-and-new Tanzu Community Edition Kubernetes cluster that could use some more real workloads so I'll instead opt for the Docker version.
Tenable provides an example
docker-compose.yml to make it easy to get started:
1version: '3.1' 2 3services: 4 5 nessus: 6 image: tenableofficial/nessus 7 restart: always 8 container_name: nessus 9 environment: 10 USERNAME: <user> 11 PASSWORD: <password> 12 ACTIVATION_CODE: <code> 13 ports: 14 - 8834:8834
I can use that knowledge to craft something I can deploy on Kubernetes:
1apiVersion: v1 2kind: Service 3metadata: 4 name: nessus 5 labels: 6 app: nessus 7spec: 8 type: LoadBalancer 9 ports: 10 - name: nessus-web 11 port: 443 12 protocol: TCP 13 targetPort: 8834 14 selector: 15 app: nessus 16--- 17apiVersion: apps/v1 18kind: Deployment 19metadata: 20 name: nessus 21spec: 22 selector: 23 matchLabels: 24 app: nessus 25 replicas: 1 26 template: 27 metadata: 28 labels: 29 app: nessus 30 spec: 31 containers: 32 - name: nessus 33 image: tenableofficial/nessus 34 env: 35 - name: ACTIVATION_CODE 36 value: "ABCD-1234-EFGH-5678-IJKL" 37 - name: USERNAME 38 value: "admin" 39 - name: PASSWORD 40 value: "VMware1!" 41 ports: 42 - name: nessus-web 43 containerPort: 8834
Note that I'm configuring the
LoadBalancer to listen on port
443 and route traffic to the pod on port
8834 so that I don't have to remember to enter an oddball port number when I want to connect to the web interface.
And now I can just apply the file:
1❯ kubectl apply -f nessus.yaml 2service/nessus created 3deployment.apps/nessus created
I'll give it a moment or two to deploy and then check on the service to figure out what IP I need to use to connect:
1❯ kubectl get svc/nessus 2NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 3nessus LoadBalancer 100.67.16.51 192.168.1.79 443:31260/TCP 57s
I point my browser to
https://192.168.1.79 and see that it's a great time for a quick coffee break since it will take a few minutes for Nessus to initialize itself:
Eventually that gets replaced with a login screen, where I can authenticate using the username and password specified earlier in the YAML.
After logging in, I get prompted to run a discovery scan to identify hosts on the network. There's a note that hosts revealed by the discovery scan will not count against my 16-host limit unless/until I select individual hosts for more detailed scans. That's good to know for future efforts, but for now I'm focused on just scanning my one vCenter server so I dismiss the prompt.
What I am interested in is scanning my vCenter for the Log4Shell vulnerability so I'll hit the friendly blue New Scan button at the top of the Scans page to create my scan. That shows me a list of Scan Templates:
I'll scroll down a bit and pick the first Log4Shell template:
I plug in a name for the scan and enter my vCenter IP (
192.168.1.12) as the lone scan target:
There's a note there that I'll also need to include credentials so that the Nessus scanner can log in to the target in order to conduct the scan, so I pop over to the aptly-named Credentials tab to add some SSH credentials. This is just my lab environment so I'll give it the
root credentials, but if I were running Nessus in a real environment I'd probably want to use a dedicated user account just for scans.
Now I can scroll to the bottom of the page, click the down-arrow next to the Save button and select the Launch option to kick off the scan:
That drops me back to the My Scans view where I can see the status of my scan. I'll grab another coffee while I stare at the little green spinny thing.
Okay, break's over - and so is the scan! Now I can click on the name of the scan to view the results:
And I can drill down into the vulnerability details:
This reveals a handful of findings related to old 1.x versions of Log4j (which went EOL in 2015 - yikes!) as well as CVE-2021-44832 Remote Code Execution vulnerability (which is resolved in Log4j 2.17.1), but the inclusion of Log4j 2.17.0 in vCenter 7.0U3c was sufficient to close the highly-publicized CVE-2021-44228 Log4Shell vulnerability. Hopefully VMware can get these other Log4j vulnerabilities taken care of in another upcoming vCenter release.
So there's that curiosity satisfied, and now I've got a handy new tool to play with in my lab.
- Tailscale on VMware Photon OS
- Upgrading a Standalone vSphere Host With esxcli
- Using the vSphere Diagnostic Tool Fling
- Removing and Recreating vCLS VMs
- Nessus Essentials on Tanzu Community Edition
- Logging in to a Tanzu Community Edition Kubernetes Cluster from a new device
- See all Tips