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.

I'd like the ability within the security tab of the server to block blacklisted IP's automatically from a list of know sources, that helps non-wordpress sites/applications as well as Wordpress sites. Most of the solutions provided seem to be aimed at Wordpress.

This would mean that all websites and web applications would have the same protection against malicious IP addresses, spamming websites and using up bandwidth, as Wordpress without having to build or find solutions that don't work as well or may not work on the Cloudways platform ( or are too time consuming to be practical, such as blocking IP's using .htaccess).