Powercli to lock down client access on firewall

[dmini]

I have to build a number of standalone ESXi 6.0 servers, that I configure as much as possible via Powercli - to avoid errors. Three could be up to 200 of these - all standalone servers - no vCenters involved

A recent pen test highlighted that I need to lock down the IP addresses accessing the hosts. All well and good, found a couple of command lines on the Altaro  website that seemed to do the job, and started running these against all services that were running.

The commands were :-

$ESXfw=(get-esxcli -vmhost 192.168.1.25).network.firewall

and then - for each firewall rule - eg snmp below

$ESXfw.ruleset.set($false,$true,"snmp")

$ESXfw.ruleset.allowedip.add("192.168.1.0/24"."snmp")

All worked really well - until I got to the vSphereClient rule - strangely enough the one they REALLY want me to get. At this point the first one of the two lines runs, I then lose access to the host so cannot enter the allowed ip address range!. I cannot reverse the order, that doesn't work. I really would like to automate this, as each server would have a different allowed range and the chance of these all being typed accurately is somewhere close to 0.

Has anyone got a solution?

Thanks in advance

[LucD]

Not really, as far as I can tell, you're sawing off the branch you are sitting on.

The vSphere Client and PowerCLI connect over the same https port.

The only solution I could see, is to use SSH (via plink.exe for example), and then do that specific esxcli command through SSH.

When done, you could stop and close SSH access through the DCUI (remember, you already closed PowerCLI)

But on a side note, how do you intend to manage those standalone ESXi servers?

Only through the DCUI?

[dmini]

Day to day management, such as is needed, is through the old vsphere client. The servers are virtually configured, all the vms required are loaded etc before they are handed over to the site.

[LucD]

That would mean you need to keep port 443 and 902 open if I'm not mistaken.

In that case PowerCLI would work as well (443).

So what exactly were you closing with the vSphereClient rule you mentioned earlier?

[dmini · Accepted solution]

I think I have just worked out how to do it  - just in case someone else is sad enough to want to try, I thought I would give the solution.

I concatenated the commands, with a ";" - this must upload both commands so they are queued to run, and the second command executes despite the temporary loss of communications. I even get back all shell messages, not that they are the most meaningful in this case.

$ESXfw.ruleset.set($false,$true,"vSphereClient"); $ESXfw.ruleset.allowedip.add("192.168.1.0/24","vSphereClient")

By the way, the target was to restrict access from the vsphere client (and powercli) to the local subnet only - in this example 192.168.1.0/24, without asking people to go into the client and type it - with the associated risk of mistypes. Any remote site management would be performed by hopping onto a workstation on that subnet and then managing from there.