Add blocks to control firewall state and temporary disable it

[iisat]

If the firewall at ESXi limits connections to only certain IP addresses, then the script may not work as it will not be possible to validate the certificate. Therefore, I added a firewall control block to disable the firewall if it was not already turned off and re-enable it after certificate validation.

[adamgolebiowski]

As acme-tiny uses port 80, instead of completely disabling firewall (which seems wrong, even for a short period), maybe we should selectively enable/disable webAccess rule only when really needed?

So first part of your patch could start with:

# Get the webAccess rule status
esxcli network firewall ruleset list | grep webAccess | grep -vq true
is_webAccess_enabled=$?
esxcli network firewall ruleset allowedip list | grep webAccess | grep -q All
is_webAccess_restricted=$?

# Disable rule if it's enabled and restricted
(....)

[Churro]

@adamgolebiowski Great suggestion, very much appreciated.

I agree that opening only port 80 inbound is a more targeted approach and should be the preferred way. Although not likely, the renewal job could abort unexpectedly before re-enabling a disabled firewall, leaving the host in a rather undesired state.

[iisat]

It actually uses ports 80 and 443 (Requests to port 80 are forcibly redirected to port 443 on ESXi). If we implement control for ports 80 and 443, the script will become much more complex and less readable. The number of logical checks will increase from 1 to 5:

1. Check if the firewall is enabled in general.
2. Check if the webAccess rule is enabled or not.
3. Check if port access for webAccess is restricted or not.
4. Check if the vSphereClient rule is enabled or not.
5. Check if port access for vSphereClient is restricted or not.

By the way, I have never examined the risks of renewal job aborts unexpectedly. If this risk is significant, then implementing firewall control should be avoided. However, without firewall control, the script becomes useless for all secured ESXi installations, which I believe is the majority of installations with direct IP to the internet.

So, in general, we have three alternatives:

• Leave it as it is (no risks, but the script is not usable on most hypervisors with direct internet access and restricted port access).
• Use simple firewall control (tiny risks of attack during renewal and some unpredicted risks of leaving the firewall in an undesired state).
• Improve firewall control (huge impact on the script code, still some risks of attack during renewal, and still some unpredicted risks of leaving the firewall in an undesired state).