mailcow admin panel landing page behind nginx

mefix

I’m running mailcow behind an nginx reverse proxy.
Everything works as expected.
mail.example.com proxy passes to mailcow ui and sogo.

I want to “obfuscate” what’s behind door number one, i.e. I want to return an empty page whenever someone accesses the base url (mail.example.com) in the browser.

So I added this to my nginx.conf:

  server {
    listen         443 ssl;
    server_name    mail.example.com;
    ssl_certificate ...
    ssl_certificate_key ...
    location = / {
      return 200;
    }
    location / { 
      ...
      proxy_pass http://172.17.0.1:8080/;
    }   
  }

So that whenever someone accesses just the base url, nginx will return 200 with an empty body.

This works, as long as I am logged into the admin UI.
If you’re logged in, all the follow up urls are mail.example.com/debug or mail.example.com/user etc.

However, if you’re logged out, the login page of the admin panel doesn’t have a sub-path in the url, it’s just the base url.

Is there any way to have the login page on a dedicated landing page like mail.example.com/login, for instance?

esackbauer

mefix However, if you’re logged out, the login page of the admin panel doesn’t have a sub-path in the url

If you have been logged in before you are a regular user and don’t need to “obfuscate”.
In general, security by obscurity is not really working. Keep your mailcow up to date is much more helping in running a secure mail server.
Or with the help of the nginx reverse proxy use an additional authentication for the landing page.

mefix Is there any way to have the login page on a dedicated landing page like mail.example.com/login, for instance?

No, not out of the box. You can however suggest this as feature request on github. I think it was also already asked many times here in forum.

mefix

esackbauer Yes, I agree on the fact that updating is a better security strategy than obfuscating. However, I also think that you don’t necessarily have to tell everybody what’s behind door number one.

Also, my point is that even if you are a registered user and you were logged out due to timeout, you won’t be able to login, because the login page is mail.example.com/ and not mail.example.com/login, unfortunately. So if you access say mail.example.com/debug and you’ve been logged out, the ui service will redirect you to mail.example.com/, which will return an empty page.

esackbauer

mefix have to tell everybody what’s behind door number one.

Where are you telling that? Even with that “broken” landing page, every script kiddy knows you are running mailcow quicker than you can think.

mefix

you’re telling it implicitly by the fact that accessing mail.example.com via http will immediately present the login page with the mailcow logo. Which is basically like putting up a welcome sign imo. Anyway, never mind, I’ll do it differently. Thanks anyway!

esackbauer

mefix
Sorry that is naive thinking, and that has nothing to do with security.
I am running webservers (wordpress) and mailcow for years, and you can harden your installation with a reverse proxy (URL Hardening, additional authorization)
A WAF also can do much more like preventing attacks, and I can tell you that so far I got 100% of the attacks towards WordPress and 0% towards mailcow.

And guess what, Outlook.com and Amazon.com have also a login page right on the base page…

ETNyx

Well Mailcow also have a webserver right? So you should be able to rewrite new address of your choosing to existing, if Im not mistaken,…

Edit: just for clarification I agree whit @esackbauer unnecessary obscurity,.. and if Mailcow comes whit same url, you are most likely, creating conflict that you will need to solve in future.