Your documentation about Bot Protection doesn't make sense. It says to add to whitelist click X and to remove from whitelist click the checkmark. Also, in the screens such as Traffic requests, every entry whether in Allowed or Blocked as a green arrow next to it. When hovering above the checkmark it says "Whitelist this IP". That seems backwards, and even more confusion is that these same rules apply for both Allowed and Blocked tabs. I am not even sure what actions to take and I don't want to block or allow an IP accidentally. What would make more sense if it just showed checkmark for allowed and X for not allowed, no matter what screen I am looking at. Can you please submit this to your development team for review?

Coming from different managed hosting, I just joined cloudways, only to be surprised that sufficient security for protecting passwords is not in place. I can see the passwords are visible to me but also to the support agents that have access to the same area and hence openly visible to them. They can see Wordpress password ( which is not issue, as they told me it is default one and if changed in wordpress admin, will not be reflected here). My biggest concern is the sensitive passwords for SQL database and application credentials. The eye icon placed next to passwords can reveal them to me but also to the support agents. I don't want to doubt anyone good intentions but the best practice is to keep them invisible even to me. If I forget the password, I will go to the same area to update them without being able to see them ( and a password change should notify me as well). The current way is not a fool proof security and can be a potential risk to the cloudways customers. I think the cloudways should take an immediate notice of this as being a security conscious company.....

If you have a .htaccess in the root of your application, that adds a htpasswd based auth password for the entire site, the Let's Encrypt autorenewal process fails. The process create a subdirectory, .well-known/ and uses it for the renewal process, deleting it at the end of the process.

There are two easy ways to get around this that I can think of:

1. do not delete the .well-known directory at the end of the process. so that us customers can add in the .htaccess file in there if we want to, to leave it readable

2. as a part of the process of creating the short-lived .well-known directory, add a .htaccess file in that folder with the content:

   Satisfy Any
   Order Allow,Deny
   Allow from all

And delete it all at the end of the process, as it does now. This will unlock that directory during the process automatically

In the advanced settings for nginx there is an option to set a WAF. This is needed fo nginx to grab the right headers in order to get the actual visitor's IP address.

Using a WAF one would certainly also want a WAF bypass prevention. For this SUCURI suggests adding the following lines to the nginx vhost:

location / {
allow 192.88.134.0/23;
allow 185.93.228.0/22;
allow 2a02:fe80::/29;
allow 66.248.200.0/22;
allow 208.109.0.0/22;
deny all;
....
}

There should be an option to do that when chosing sucuri as a WAF.

Also, if you contact support to add those rules for you (which they thankfully did), the WAF configuration box will be blank. DO NOT CHOSE SUCURI AGAIN as this will mess with the allow rules. I am not sure why. But if you set it to sucuri WAF again, the page will result in a 403 for all requests made by sucuri.

Also, for this to be a complete package, a meaningful WAF bypass should also prevent SSL information leakage. I created another suggestion for that (https://cloudways.uservoice.com/forums/203824-service-improvement/suggestions/42272272-stop-server-from-leaking-ssl-information)

If the application is served through a WAF, you don't want anyone to bypass the WAF by accessing the server using its IP address.

Cloudways gives us the option to disable access to the application using the IP address only (apache Access Application via IP). However, the web server is still responding to SSL requests, thus leaking the certificate information that would include the common name.

The SSL certificate should only be presented to the WAF/requests using the hostname/URL and not by accessing the IP address.

It seems that cloudways is using nginx as a reverse proxy in front of apache. Nginx ≥ 1.19.4 has an option to reject ssl handshakes (sslrejecthandshake). This could be used to stop infomation leakage.

Please offer an option to properly shield origin servers behind a WAF.