Issues with new /server/scripts/letsencrypt code
I'm running Ubuntu v20 with v3.2 and just noticed this error when generating a cert in expert mode for a DNS:
Running post-hook command: letsencrypt_post_hook.sh
post-hook command "letsencrypt_post_hook.sh" returned error code 2
Error output from post-hook command letsencrypt_post_hook.sh:
/usr/local/bin/letsencrypt_post_hook.sh: line 31: syntax error near unexpected token `;'
/usr/local/bin/letsencrypt_post_hook.sh: line 31:
` else; if [ rpm -q ufw ]; then ufw --force enable && ufw deny http; fi'
That line is found in the commit here.
Point 1 : Apparently something is wrong with that line.
Note that line 31 is in the IF block for RHEL. So:
Point 2 : The wrong block is getting executed for Ubuntu.
Note that the new letsencrypt_pre_hook.sh has similar code. So:
Point 3 : Check the pre hook to see if the right block is being executed for Ubuntu.
The pre hook uses ufw allow http. The output from that is "Skipping adding existing rule", which is correct for a default installation. But it might not be correct if the site admin had changed it prior to installing ISPConfig. The post hook then uses deny http. The intention there seems to be to leave HTTP entirely denied when this process completes. But there are two issues with this.
Point 4 : When the ISPConfig installation completes, in my testing (might not be universal) UFW still has HTTP/80 enabled even though the code explicitly disables it. If the intent is truly to deny further HTTP traffic, that is not working.
Point 5 : Assuming the deny http is intentional : What if the server uses both HTTP and HTTPS? I don't think this installer should "close the door" on HTTP just because the admin gets a cert for HTTPS.
This code uses ufw --force enable. Whether we agree or disagree, in Ubuntu 20, SSH is denied by default in UFW. So prior to running the ISPConfig installer, I disable UFW and manage the firewall at the network level. Now the installer forces UFW to enable in both the pre- and post- cert routines. That leaves UFW enabled when it was previously disabled. This introduces a side effect where unexpected rules are left enabled after the ISPConfig installation. The result I've experienced in all recent installations is that my SSH connection randomly drops while I'm working, apparently when the UFW process reloads its config and closes the SSH port.
Note that if you SSH, and from shell execute ufw enable, it warns you:
Command may disrupt existing ssh connections. Proceed with operation (y|n)?
That warning doesn't display with the --force option. It does display even if SSH is enabled. This is confirmation that the UFW developers know that running processes can get killed in this scenario. So:
Point 6 : I think the state of UFW should be checked in the pre hook. If it is disabled it should not be enabled, and thus not processed in the post hook. This probably applies to the other firewalls that are supported.
Assume UFW is active, SSH is enabled, HTTP is enabled for the cert and then disabled in the post process. By default HTTPS is disabled. Why do we expect inbound HTTPS connections to be enabled when this process completes? Is there some other setting that modifies UFW to allow HTTPS?
Point 7 : Apparently HTTPS works but if this code leaves UFW running without HTTPS permissions then it seems it's not working for the right reasons. Is there a hole in UFW, or perhaps a hole for other open ports? I think this should have a solid answer.
Final note: If the intent is to leave HTTPS open, this installer needs to be careful about opening a security hole. The UFW rule table adds rules to the bottom of a list. If the admin already has this configured, for example to only allow HTTP+HTTPS from a specific subnet, I believe adding a rule at the bottom of the list will override that, essentially leaving HTTPS ALLOW IN From Anywhere.
Point 8 : While I appreciate what this code is doing I think it needs significant rethinking about how it works, pre-existing site conditions, and what it might do to open up a pre-configured environment. Maybe the better approach is to save the rule list, modify it, then restore the original. Again, this can apply to IPTables and any other firewall. If the response to this is "a server configured to the 'Perfect' specs" won't have a firewall configured, then at least tell the admin what's happening to the environment when it finishes.