Do we need the SLP Service on Port 427

[kri-2]

Hi,

our penetration test team criticizes a running SLP Service on Port 427 tcp/udp on all our ESXi hosts 5.0 (HP380G6-G8).

Does someone know if this Service is needed on a standard ESXi host connectet to a vCenter (maby for the hardware tab)?

We are NOT running any third party tools to monitor the hosts (HP agent e.g). But we have installed the CIM Provider for the vCenter integration.

Just closing "CIM SLP" via firewall rules did not bring up any problems promptly as far as I see, but I want to be really sure.

Any help would be appreciated.

Chris

[jrmunday]

Hi Chris,

As far as I understand, this CIM SLP service is used by the vSphere client to discover hardware inventory on your hosts ... so unless you are using any plugins to monitor hardware, I would just verify that you still see all the right data in the hardware tab (including, verifying that the sensors still work). There is nothing special mentioned in the VMware hardening guides about this port or UDP service, so not too sure why security are keen on closing it down?

Hope this helps?

Cheers,

Jon

[kri-2]

Hi Jon,

thanks for your answer!

This is what I thought too. It must be used for the vClient/vCenter to get the hardware informations from the hosts.

But when disabling it the hardware infos are still shown in vClient. But the hardware tab has often an odd behaviour (not current/real values) and I struggle to trust it.

So I hoped to find someone who can definitly say "you (don't) need it".

Chris

[jrmunday · Accepted solution]

Perhaps the best course of action would be to push back on the security recommendations and log a support call with VMware to confirm the impact of closing this down ... I'm always reluctant to make changes that I don't fully understand. In this case, security cant explain why they want this closed down and you don't know the impact to production if you do close it down.

Cheers,

Jon

[kri-2]

Thanks Jon,

this might be the best way.

Cheers, Chris

[kwg66]

You all realize that VMware support only accesses public documentation right?   and VMware has nothing published about what they are using SPL for and whether or not it should be disabled and what the impact would be if it was disabled..   I would not have marked this as the correct answer because it doesn't answer the question, it remains unanswered. 

Here is the VMware KB that talks about disabling SLP and you can see there is nothing in it describing the impact of disabling the service..  I made certain to leave a feedback comment on the KB stating the person who QAs these KBs needs to be fired.. 

VMware Knowledge Base

I encourage others who read this KB to make a similar comment and submit feedback to let VMware know this is unacceptable.   This is a complete lack of customer focus and it leaves customers scrambling around the web trying to find more info about this to make an informed decision..  Shall we send an invoice over to VMware for the time spent trying to dig up the true details of this issue so we know the proper actions to take in an informed manner?  

[sbr140]

Well Said

And here I am probably doing the same thing you are is researching the VMSA they released yesterday.

[Security-announce] VMSA-2019-0022 VMware ESXi and Horizon DaaS updates address OpenSLP remote code execution vulnerability (CVE-2019-5544)

I have opened a SR and will post what they tell me. Please do the same if you learn anything

[abugeja]

any further information from VMware on this?

[sbr140]

Hi All,

This is the text of the VMware SR I opened and their response is below:

This is a question about the vulnerability announcement sent today: [Security-announce] VMSA-2019-0022 VMware ESXi and Horizon DaaS updates address OpenSLP remote code execution vulnerability (CVE-2019-5544)

Due to constraints in our environment we are not able to update to the recommended build of:

Product:ESXi (Embedded and Installable) 6.7.0 -  ESXi670-201912001 - 12/05/2019 - 15160138

Prior to performing the workaround per KB76372 on our ESXi hosts we need to know if any vSphere applications will be affected by applying the workaround to include the vRealize Suite vRA, vCO, vRB, Loginsight, vRNI, vROPS, NSX, etc....

VMware response:

. When performing the workaround as described in https://kb.vmware.com/s/article/76372 we will lose access to hardware health monitoring at the vCenter level. However none of the other vSphere products you mentioned should be affected by performing this workaround.

In a second question I asked if Proactive HA would be affected. They said no.

It does not appear that ESXi or any apps use port 427 with the exception of Hardware Health. So if you're relying on hardware health you may have an issue.

I am waiting for a response to see if this wil affect Hardware Alerts like ‘host memory’, Host processor’, host hardware voltage’ etc….

Update from VMware support:

. In this case yes by disabling SLP and port 427 we will limit if not remove the ability to receive alerts for hardware health from the vCenter level.

If you have out of band management solutions like iDRAC, ILO, UCS, etc then you should still have some access to hardware health monitoring.

[abugeja]

We have decided to apply the workaround for this vulnerbility. We have other tools in place to monitor harward

[abugeja]

has anyone worked out a way to script the workaround via powercli?

[sbr140]

I'm going to work on a powershell script using Posh-SSH as I get time. I will  try topost once completed

[scott28tt]

PowerCLI - Workaround for OpenSLP security vulnerability in ESXi 6.x (CVE-2019-5544) / VMSA-2019-002...

[dpinol]

Hi all,

I applied the workaround, but the Last update field continues to report to vcenter hardware sensor activity.

Does anyone really know the impact of applying the workaround?

Thanks in advanced.

[sbr140]

I have not seen any negative impact of applying this change. NOTE I have only tested on one host for 5 hours or so.

This is a response to virtually the same question we asked VMware Support

"In relation to the SLP being disabled i researched on it and found the below mentioned information.

SLP isn’t used by the vCenter to discover which ports the CIM agents are using on the ESXi (it just knows)

o All the hardware monitoring we see in the vCenter will remain (disk issues, battery problems, thermals, etc.)

· external systems that might want to talk to the ESXi CIM agents could be relying on SLP to discover them and so might not work.

KB article to disable SLP - https://kb.vmware.com/s/article/76372 "

[sbr140]

Scott Thanks for posting.

Saved me some work, greatly appreciated.

[kwg66]

Wow even worse then I expected... a complete contradiction

[iremembercpm]

Would it not be possible to edit the CIM SLP service's allowed IP Addresses and manually enter our vcenter server ip?  Would this not be a more sane work-around?

[sbr140]

You could probably use esxcli to create firewall rules.

ESXi ESXCLI Firewall Commands

[rapidspider]

Did anyone experience any issues after enabling the workaround described in KB 76372 to fix the problem with SLP?

I would appreciate if anyone could share their experience.