After use Nessus scan HCI 1.8P1 and discover below vulnerability, but the "Remediation" did not mention fix the issue. Could HCI 1.9 fix below vulnerability? If did not patch fix, could management node setup firewall ACL allow dedicate hosts access?
Oftentimes such scans are just "security spam" and report all sorts of things. Many a time it's completely irrelevant to our use case because we don't run eCommerce portals but API services for admins and vCenter/K8s.
For example, let's take a look at the first two CVEs:
1) CVE-2019-11068 - libxslt - I don't see how any of that applies to NetApp HCI or SF environments. "xsltCheckRead can return -1 for a crafted URL that is not actually invalid and is subsequently loaded". Users are administrators. If someone could show me how one admin with limited permissions can become another admin, I'd be interested. Otherwise, I don't see how this matters.
2) CVE-2019-14287 - sudo vulnerability. First, there are no users on mNode (or SolidFire nodes) except admins, so there's no harm in a sudoer becoming root. Second, the vulnerability - as per example exploit in the CVE - doesn't do anything (see below). Third, you can become root by simply switching to root - the only user there is (admin) is supposed to be able to become root.
Yes, you can limit IP access and NetApp HCI at least recommends to put mNode on a Management VLAN when deploying, so that only admins can access mNode in the first place. If your Mgmt node was on own LAN, exposed only to selected admins and vCenter, for example, it wouldn't get scanned in the first place.
But many users don't do that because it's "inconvenient", so vCenter, SolidFire MIP(s) and mNode MIP are all made accessible to VM Network.
If you haven't done that, you can move mNode to another network, although that may not be possible without reinstalling it (or reconfiguring, but there are no KBs for that as far as I know), or use other approaches such as iptables on mNode.
Because of Docker, there's a lot of rules already configured, so you'd have to be careful to just add additional rules that drop access to HCC/mNode management IP/port to all, and allow it to IPs that need access (which could be a handful, depending who and what needs access to that IP). These rules may need to be redeployed after mNode VM is redeployed or upgraded.
Another way is to install a secure proxy and allow access to mNode only to that proxy IP, and deal with access control on the proxy.
mnode ~ # iptables -L Chain INPUT (policy DROP) target prot opt source destination ufw-before-logging-input all -- anywhere anywhere ufw-before-input all -- anywhere anywhere ufw-after-input all -- anywhere anywhere ufw-after-logging-input all -- anywhere anywhere ufw-reject-input all -- anywhere anywhere ufw-track-input all -- anywhere anywhere
Chain FORWARD (policy DROP) target prot opt source destination DOCKER-USER all -- anywhere anywhere DOCKER-INGRESS all -- anywhere anywhere DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere