• The APS Catalog has been deprecated and removed from all Plesk Obsidian versions.
    Applications already installed from the APS Catalog will continue working. However, Plesk will no longer provide support for APS applications.
  • Please be aware: with the Plesk Obsidian 18.0.78 release, the support for the ngx_pagespeed.so module will be deprecated and removed from the sw-nginx package.

Question Change the Roundcube webmail URL or protect access to the URL with a password

macadia

Basic Pleskian
Server operating system version
AlmaLinux 9.7 (Moss Jungle Cat)
Plesk version and microupdate number
Plesk Obsidian v18.0.77
Hello,

I would like to ask whether it is possible to implement one of the following two options:
  1. On one hand, change the Roundcube URL (I have already voted here: https://features.plesk.com/tabs/24-under-consideration) so that it is not webmail.domain.tld, or
  2. Protect the webmail directory with an access password so that only the client can access it. Although Roundcube is useful, it has recently had some concerning vulnerabilities.
Thank you in advance for your response.

Best regards,
Martin
 
Protect the webmail directory with an access password so that only the client can access it. Although Roundcube is useful, it has recently had some concerning vulnerabilities.
What vulnerabilities are you exactly referring to?

I would actually consider Roundcube to be pretty safe. The Roundcube project has been around for ages and has been tried and tested, along with a large user based and active community contributing to the project. I've found that the project maintainers take vulnerabilities pretty serious and are often quick to publish security updates. Granted, it sometimes takes a few days for any released updates to get adopted by Plesk, but even those usually don't take that long to be released.

From what I can quickly gather, most recent vulnerabilities are related to content filtering, causing XSS vulnerabilities and a like. Changing the webmail URL won't help you much as that does not address any of those vulnerabilities.

If you are concerned with security related to user access, such a password loses or brute force attempts, you might be better of installing plugins that enhance security. Like a 2FA authentication for example.
 
@macadia

@Kaspar is fully right and I highlight the parts of his response that I hope to add value to :

I would actually consider Roundcube to be pretty safe. .....

If you are concerned with security related to user access, such a password loses or brute force attempts, you might be better of installing plugins that enhance security. Like a 2FA authentication for example.

In essence, Roundcube is safe and plugins might help.

Nevertheless, one could also consider a set of Nginx based rules that add to the default Nginx webmail config.


Brute force attacks, hack attempts ....... it can all be solved with

1 - a combination of Fail2Ban filters/jails + Nginx config (read: Nginx config denying access to bad IPs, flagged as bad by Fail2Ban filters), and/or

2 - Nginx config that aims - for instance - to throttle requests (brute forcing)

and the nice thing about this approach is that Nginx config can be added to the /etc/nginx directories and hence apply server-wide.

Obviously, some bad IPs should be banned permanently and this should take place in the firewall (not in Nginx config and/or with Fail2Ban).


I can strongly recommend that you (first) investigate what is already in place and (second) define some Nginx config that applies server-wide, with changes to the Nginx config being made by Fail2Ban or any other tool that has the same purpose.

Kind regards....
 
What vulnerabilities are you exactly referring to?

I would actually consider Roundcube to be pretty safe. The Roundcube project has been around for ages and has been tried and tested, along with a large user based and active community contributing to the project. I've found that the project maintainers take vulnerabilities pretty serious and are often quick to publish security updates. Granted, it sometimes takes a few days for any released updates to get adopted by Plesk, but even those usually don't take that long to be released.

From what I can quickly gather, most recent vulnerabilities are related to content filtering, causing XSS vulnerabilities and a like. Changing the webmail URL won't help you much as that does not address any of those vulnerabilities.

If you are concerned with security related to user access, such a password loses or brute force attempts, you might be better of installing plugins that enhance security. Like a 2FA authentication for example.

My comment was based on this INCIBE link with the list of Roundcube vulnerabilities.

Maybe I was a bit over the top :(

I’m going to look into 2FA for Roundcube—maybe that’s what I’m actually looking for. And yes, my main concern is password compromise: even though the passwords are strong (around 20 characters with symbols, etc.), an account was still breached. They created four forwarding rules in the filters, which is hard to detect until spam starts going out—and by then it’s already too late.

Thanks for your answers.
 
@macadia

Given this text

And yes, my main concern is password compromise: even though the passwords are strong (around 20 characters with symbols, etc.), an account was still breached.

I think that you have an entirely different issue : "human error" or "human intent".

It makes no sense for any hacker to attempt a hack on one account (as you describe it, "an account") and when being succesful, being satisfied with the hack of one account and the creation of a limited number (four) of forwarding rules.

Hackers will attempt to achieve "greater goals" by using automation and targeting plenty of mail accounts or the entire server.

Stated differently, you cannot really defend against phishing ("human error" ) or bad customers ("human intent") that create these kinds of spam accounts.

If my intuition is right (and there is "human error" or "human intent"), then 2FA would not help either.


As a final remark, please note the following.

For any forwarding rule to be succesful, the mail has to be delivered (from an external mail server) to the mail account (on your mail server).

That should also imply that you can simply block the IP (of the external mail server) to avoid the mails to be delivered to the mail account (on your mail server) and being forwarded afterwards (as a result of the forwarding rules).

I am using the word "should" on purpose ... it is not a guarantee, but it should : mails can only be forwarded when received, so stop the delivery of the mails.


Kind regards.....
 
I’m going to look into 2FA for Roundcube—maybe that’s what I’m actually looking for. And yes, my main concern is password compromise: even though the passwords are strong (around 20 characters with symbols, etc.), an account was still breached. They created four forwarding rules in the filters, which is hard to detect until spam starts going out—and by then it’s already too late.
If that has been the case, you might want also modify your Roundcube configuration to prohibit the creation of forwarding rules. See this thread about the same subject, including some suggestions.
 
Back
Top