AFF, NVMe, EF-Series, and SolidFire Discussions

HCI vulnerability




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?













Best regards,




Re: HCI vulnerability




Mitigations (fixes or workarounds) are expected for all affected Full Support products. Advisories are updated with first fixed releases when they become available for use.


I am unsure if it is possible to configure the firewall on the management node - I'd recommend a support case to confirm.


View solution in original post

Re: HCI vulnerability


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


Earn Rewards for Your Review!
GPI Review Banner
All Community Forums