VMware Cloud Community
serenity2011101
Contributor
Contributor

I Need An Expert. How to disable ping for remote networks on an ESXi hosts. Please help.

We have spent days on this and have gotten no where.  Here's the deal.  I need to disable ICMP, at a minimum ping/echo, responses from the management IP to all non-local subnets.  So in other words, lets say a random ESXi server's IP is 10.10.10.101/24.  I need all hosts on 10.10.10.x/24 to respond to pings, but all other hosts on other subnets need to be blocked, such as a host on 10.10.20.x/24.

You would think this is straight forward, but it does not behave how the documentation says it does.  I have tried adding rules for TCP/UDP port 7 manually to the host firewall, and only allowing the local subnet, but I'm still pinging away from other hosts on other subnets.  Even after refreshing, unloading, reloading, refreshing again, etc.  I realize adding manual entries to services.xml will not be persistent through a reboot unless I put a vib together, which I will if that's part of a solution that acutally works, but I'm unable to get ping blocked at all.  It seems like it's controlled by a mechanism at a higher level than the firewall, which makes no sense to me.

Any insight, ideas, or hep would be greatly appreciated.  In the end I need to lock down a lot more than ping to the local network, but that's the most important and a very good start.  One might suggest just removing the default gateway, or blocking it at the default gateway.  That's not an option here.  It must be done on the ESXi host.  One more thing, most of these hosts are currently running ESXi 6.0 Update 2, although a couple might still be at baseline 6.0

Thanks in advance,

Mike

A+, Network+, Security+, CEH, ECSA, CHFI, LPT, Sun Solaris Certified Network Administrator, (Expired) VCP-4.0 (hope to have it again when money grows on trees and I can afford an extortion class) =^)
0 Kudos
3 Replies
DavidPasek
Enthusiast
Enthusiast

Hi Mike,

first of all, standard ping is done over ICMP protocol which is not TCP nor UDP. See. Internet Control Message Protocol - Wikipedia

I did some research and it seems to me that esx firewall supports only TCP/UDP custom rules so I don't think you can block ICMP as it is enabled by default. And it makes perfect sense if you ask me. I personally believe ICMP should be enabled on all network devices for proper network management and diagnostic.

And as you already mentioned, even you would be able to do it you would need to create custom VIB to make it persistent and apply it to all ESXi hosts. This would have negative impact on manageability and also on security because you would need to change VIB acceptance level to support CommunitySupported VIBs. See. vSphere 6.0 Documentation Center

You did not shared with us the reason why you cannot block ICMP communication on your router/firewall (default gateway).

Can you share with us this particular constraint in your environment? I'm just curious why you cannot do firewall rules in router or ACL's in your switch. To be honest, custom ESXi firewall rules is the last resort for me personally. Anyway, I don't know about any possibility how to create custom ICMP rules on ESXi firewall so this is probably the main show stopper.

David.

-- The devil is in the detail.
0 Kudos
serenity2011101
Contributor
Contributor

Thank you for the clarification that "echo" isn't the same as ICMP ping, which is also referred to as echo.  That makes sense.

Because all management servers are on the same VLAN as the ESXi hosts, I don't see how it would affect manageability.  I've read conflicting posts online that ESXi's VMkernal iSCSI & NFS interface addresses do not reply to ICMP by default to any device other than those on the same subnet, starting with ESXi 6.0.  I'll try to dig up some of those links for reference.

As for why this has to be done this way, what I can say is it's for a very customized government application and it is a hard security requirement.  We might ask the customer if it's feasible to put ASA 550x's in between each hosts management NIC and the local network just to transparently block ICMP, which seems insane to me but it looks like the built-in firewall is too "dumb" to do what we need in this instance.

I do find it unacceptable, from a security perspective, that a listening service (or protocol in this case) can not be controlled, shut off, or protected in any way.  We have been able to do this successfully with XenServer, Hyper-V, and oVirt (as well as some less mainstream hypervisors like Proxmox and KVM) quite easily.  Depending on the customer's response we might end up moving the entire spec to another platform because of something as miniscule as a ping.  You've got to love the government!


Thanks,

Mike

A+, Network+, Security+, CEH, ECSA, CHFI, LPT, Sun Solaris Certified Network Administrator, (Expired) VCP-4.0 (hope to have it again when money grows on trees and I can afford an extortion class) =^)
0 Kudos
DavidPasek
Enthusiast
Enthusiast

Hi Mike.

Overall solution manageability is IMHO impacted because of the need to create, maintain and deploy custom VIB.

However, if it is needed to fulfill specific important security requirement then you would have proper justification and it make sense in such particular case.

Unfortunately, I don't think ESXi supports custom ICMP firewall rules. 

Don't get me wrong, I really understand your point. You want to have possibility to configure ESXi firewall to block ICMP from some IP subnets and it seems pretty logical to me.

I would ask and validate this request with @mikefoley (well known VMware's security expert). He can confirm if it is achievable or not in current ESXi. If not you can ask for feature request. And proper business justification can help to prioritize your feature request.

On the other hand, I still believe this requirement is relatively easily achievable with ACL's in ethernet switches and you don't need to invest into special security devices as CISCO ASA. I assume here that you use datacenter switches where ACL's are available.

-- The devil is in the detail.
0 Kudos