Control Web Panel
WebPanel => Information => Topic started by: Vinayak on July 28, 2023, 08:04:51 AM
-
How do we secure these logs
https://cpanel.domain.com/roundcube/logs/errors.log
https://cpanel.domain.com/webmail/logs/errors.log
And all other files withing the logs folder.
Any one visiting above URLs (replace domain.com with your actual domain) can download these log files and use them for exploitation.
I can see there is one .htaccess file, but it's not being honoured by the cwp webserver, in my case Apache.
-
Just checked a couple domains.
Got either a permission denied by cwpsrv or a 403.
Hop into the CLI via SSH or Terminal
cd /scripts
./mail_roundcube_update
exit
Then in CWP, goto User Accounts -> Fix Permissions
Select the user (domain)
Check -> Fix Permissions
Check -> Internal Server Error
-
yup confirm
-
Just checked a couple domains.
Got either a permission denied by cwpsrv or a 403.
Hop into the CLI via SSH or Terminal
cd /scripts
./mail_roundcube_update
exit
Then in CWP, goto User Accounts -> Fix Permissions
Select the user (domain)
Check -> Fix Permissions
Check -> Internal Server Error
Followed above suggestion to the letter, but no use.
Some additional info.
cd /scripts
./mail_roundcube_update
Last metadata expiration check: 0:13:24 ago on Sat Jul 29 01:45:42 2023.
Dependencies resolved.
Nothing to do.
Complete!
###############################
Roundcube is already up-to-date
###############################
AlmaLinux release 8.8
CWPpro version: 0.9.8.1160
-
Some additional information
This too is not secure
https://host.domain.com:2031/roundcube/logs/errors.log
And is this Owner/Group correct? Because whatever domain is used, same errors.log get downloaded.
Owner: cwpsvc
Group: cwpsvc
/usr/local/cwpsrv/var/services/roundcube/logs/errors.log
And this is happening in multiple servers, not just one.
-
cd /scripts
./mail_roundcube_update
Note that you don't want to do this if you've manually updated to roundcube 1.5.3 (http://"https://www.alphagnu.com/topic/33-update-cwp-roundcube-mail-version-153-%E2%80%93-control-web-panel/") per Sandeep's instructions. The "logic" of the roundcube update script does not take into account the currently installed version and will merrily blow away a newer 1.5.x install and install 1.4.11 instead.
-
cd /scripts
./mail_roundcube_update
Note that you don't want to do this if you've manually updated to roundcube 1.5.3 (http://"https://www.alphagnu.com/topic/33-update-cwp-roundcube-mail-version-153-%E2%80%93-control-web-panel/") per Sandeep's instructions. The "logic" of the roundcube update script does not take into account the currently installed version and will merrily blow away a newer 1.5.x install and install 1.4.11 instead.
Thanks for the heads up, but mine is default setup, webmail is running fine.
As per my earlier post result of
cd /scripts
./mail_roundcube_update
Was
Roundcube is already up-to-date
Current version is
Roundcube Webmail IMAP Client
Version 1.4.11
And these URLs are not secure, all servers are exposed.
https://cpanel.domain.com/roundcube/logs/errors.log
https://cpanel.domain.com/webmail/logs/errors.log
https://host.domain.com:2031/roundcube/logs/errors.log
https://webmail.domain.com//logs/errors.log
Entry in /usr/local/cwpsrv/var/services/roundcube/logs/.htaccess
# deny webserver access to this directory
<ifModule mod_authz_core.c>
Require all denied
</ifModule>
<ifModule mod_authz_core.c>
Deny from all
</ifModule>
Owner & group for /usr/local/cwpsrv/var/services/roundcube/logs/ and all files within.
Owner: cwpsvc
Group: cwpsvc
-
This issue still persists with CWPpro version: 0.9.8.1174 and no working solution to fix it.
-
Same issue on fresh install
CentOS Linux release 7.9.2009 (Core)
CWPpro version: 0.9.8.1174
-
Check out:
https://www.alphagnu.com/topic/33-update-cwp-roundcube-mail-version-156-%E2%80%93-control-web-panel/
That will get you RoundCube 1.5.6
And check out ELevate, that will get you away from the EOL CentOS 7.
-
I did a CentOS 7 install just to check if the issue is there too.
I understand that issue is with the version of RoundCube, but then other panels have not shown same behaviour.
Solution must come from CWP officially, else patch work may break things in future.
Any idea, how CWP future update will handle the scenario if update is applied today using Sandeep B's solution?
Also, any one tested this solution on AlmaLinux release 8.x and up ?
-
That link from AlphaGNU is about as 'official' as it gets.
It's not a patch that will get broken. I've gone thru multiple CWP updates, and it's still working.
I'm running RoundCube 1.5.6 using that method on AlmaLinux 8.x, and you can see my questions if you scroll down on that page about 1.6.x.
I think @overseer is as well, but he'll have to chime in to say if he is or not.
-
Yes, Roundcube 1.5.6 (updated from Sandeep's 1.5.3 instructions, linked above). You can't get to the 1.6 branch with our current CWP kit; hopefully when EL9 support rolls out.
-
So, I applied the Roundcube 1.5.6 update on my CentOS 7 test server as per Sandeep's instructions, update was seamless and without errors, but the issue of exposed log files is still there.
These URLs are still not secure, they are still exposed to public.
https://cpanel.domain.com/roundcube/logs/errors.log
https://cpanel.domain.com/webmail/logs/errors.log
https://host.domain.com:2031/roundcube/logs/errors.log
https://webmail.domain.com//logs/errors.log
-
Weird. I can't duplicate what you are seeing, and I'm accessing the server from a Whitelisted IP.
When I try those URL's using our domain, I get 404 Not Found errors or Forbidden.
BTW, https://webmail.domain.com//logs/errors.log
Has 2 // after the domain name. I know it's just a type-o.
But by default those are not accessible, at least not on a AlmaLinux 8.x install with CWPpro.
-
My production versions where I found this issue initially were
AlmaLinux release 8.8
CWPpro version: 0.9.8.1160
Current versions
Distro Name: AlmaLinux release 8.9 (Midnight Oncilla)
CWPpro version: 0.9.8.1174
I will apply update on one of these server, let's see if the issue is fixed or not.
-
Let us know.
I'm testing on AL 8.9 with CWPpro 0.9.8.1174
-
@Vinayak If you haven't updated your AlmaLinux servers in awhile, you had mentioned 8.8.
You will need to install the new AlmaLinux GPG Keys first: https://almalinux.org/blog/2023-12-20-almalinux-8-key-update/
-
As I mentioned in my previous post, on my production servers AlmaLinux is updated to release 8.9 (Midnight Oncilla)
& CWPpro version to 0.9.8.1174. I update my servers on regular basis.
For AlmaLinux GPG Keys, below is the result of command "rpm -q gpg-pubkey-ced7258b-6525146f"
gpg-pubkey-ced7258b-6525146f
This shows latest GPG Keys are installed & trusted.
-
As I am still trying to fix this, I am wondering whether cwpsrv/nginx is blocking access to these log and other crucial files or not.
Any idea where to check the configuration/directives for cwpsrv/nginx to make sure on this issue?
Or some other mechanism is in use to secure such files and path?
-
Yes, ModSecurity.
I have Como rules installed with ModSecurity, and it is blocking these access.
Regards,
Netino
-
We are running ModSecurity with Comodo ruleset 1.241 with no problems.
Not a ModSecurity and/or Comodo issue.
-
I have the same problem? Have you found a solution yet?
-
No official solution yet.
-
nano /usr/local/cwpsrv/conf/cwp_services.conf
find location /roundcube {
Add:
location /roundcube/logs/ {
deny all;
}
Example:
location /roundcube {
root /usr/local/cwpsrv/var/services;
index index.html index.htm index.php;
location /roundcube/logs/ {
deny all;
}
location ~ \.php$ {
-
Won't this get overwritten on CWP updates?
-
Won't this get overwritten on CWP updates?
Most likely. But it's a solution that the coders can implement when they see it on the forum ;)
-
All of our CWP installation didn't have this issue.
Logs where not accessible, the screen up up with the generic permission denied screen.
But a working ModSecurity properly configured seems to block it, along with updating to RoundCube 1.5.9, which is a LTS version.
-
The extra step is necessary to close the breach. In other case the logs can be accessed over the URLs like:
https://webmail.DOMAIN.COM/logs/errors.log
https://webmail.DOMAIN.COM:2096/logs/errors.log
Add the following "location":
location ~ \.log$ {
deny all;
}
into the both "server" sections of the file /usr/local/cwpsrv/conf.d/webmail.conf.
Example:
location ~ \.log$ {
deny all;
}
location / {
then restart cwpsrv:
service cwpsrv restart
-
So neither fix did anything on a system without the Comodo ruleset.
Interesting.
Followed what @rcschaff, and @cyberspace posted.
Both /usr/local/cwpsrv/conf/cwp_services.conf & /usr/local/cwpsrv/conf.d/webmail.conf where updated.
https://webmail.DOMAIN.COM/logs/errors.log still allowed the error log to be downloaded.
Port 2095 & 2096 have to be public also.
The team who builds Roundcube is blaming this on a deleted .htaccess file, which are confirmed there with proper permissions like @Vinayak posted.
So the webserver should be looking at those rule denying access as well.
-
.htaccess is server by the webservers Apache and Litespeed. CWP panel uses nginx to handle all requests coming to the panel and included services (webmail, phpmyadmin, etc). That is why .htaccess is ignored by CWP.
Anyway, if I remove the rule from:
/usr/local/cwpsrv/conf.d/webmail.conf
then I can access the logs using:
https://webmail.domain.com/logs/errors.log
same is applied for the rule from @rcschaff.
Do you have some test system and can you provide me with access to it ?
-
Sent you a DM.
Just out of curiosity I deleted the /usr/local/cwpsrv/var/services/roundcube/logs/errors.log, and it's still trying to download it form somewhere.
Not sure how I got sucked into this blackhole, it's 0113...
-
Thanks :)
It now presents '403 Forbidden'.