Restrict IP for location /admin/ with nginx

gorby · 8 Apr

Hello community,

I’m trying to use nginx to restrict the access of mailcow UI for /admin/ location.
I followed the docs ( Custom sites - mailcow: dockerized documentation

docs.mailcow.email

Custom sites - mailcow: dockerized documentation

None

) and I’ve created a extra.conf in data/conf/nginx with inside :

server {
   location /admin/ {
        allow 192.168.1.100;  # Allow this specific IP
        deny all;             # Deny all other IPs
   }
}

But /admin/ is still open to every IP after a compose down & up.
Someone has an idea ?

–
Léo.

esackbauer · 9 Apr

You have to do it outside of mailcow with e.g. a reverse proxy.

bogdanovser · 27 Apr

esackbauer
I have the same task for my server.
Why can’t we use nginx from mailcow-dockerized for it?

esackbauer · 27 Apr

bogdanovser Because you do not have full control over it. Its a special configuration, and your changes may be overwritten by a future update of mailcow.
So you technically could do it (e.g. fork mailcow to be in control over updates), but you need to support it on your own.

bogdanovser · 27 Apr

esackbauer
Is there a list of endpoints that definitely need to be published externally for users, for example:

/SOGo…,
/user…,
/.well-known/caldav,
/Microsoft-Server-ActiveSync….
etc….

And which ones are desirable to hide from the outside world:

/admin,
/rspamd,
etc.

Or at least a list of all endpoints - so that each admin can decide for himself what to publish and what to hide?

esackbauer · 28 Apr

There is no such list. I have not hidden any specific URL from Internet, but I guess hiding /admin and /domainadmin is a good idea.
I am using a Web Application Firewall and mandatory 2FA via Authentik, so this is not really important for me.

gorby · 29 Apr

Hi @esackbauer
I saw this question many times on GitHub or here also. Seems like many users would be interested in such an option to restrict the admin an domainadmin user interface in nginx simply. Putting a reverse proxy outside of mailcow is doable and rather simple for experienced users, but isn’t mailcow aiming for getting new users from every type, newbies and professionals ?

I managed to get it working, but that was quite a pain for an average user like me

esackbauer · 30 Apr

sorry if that sounds harsh, but an average user for whom a reverse proxy or WAF is too complex should not be concerned about additional security, if he even doesnt understand the built in security of mailcow.
Just use strong passwords and 2FA and you are safe, which should be the default for any web application these days…

gorby · 1 May

Hi @esackbauer

I’m sorry if this sounds a bit blunt, but the Mailcow project is aimed at people who are actively choosing to take back control of their data, to encourage the use of alternatives to the GAFAM companies that exploit personal information. It’s therefore an initiative that helps raise user awareness and responsibility when it comes to data security.

When several of these users are trying to play by the rules and express a need—especially within a community-driven open-source project—I don’t think they should be discouraged from joining the discussion or from wanting to improve an already solid system.

After all, the very existence of this request simply shows that it could be a (fairly inexpensive) evolution of the system that meets a real need, even if you personally believe it’s unnecessary.

Once again, I’ve worked around this need by setting up a reverse proxy as suggested by the help from this community, but adding the filtering module directly to the container’s Nginx and offering it as an option is not entirely useless for the broader user base of this project.

–
Léo.

Ddisgustipated · 1 May

gorby i understand your thought process here, however those users wanting to control their own data should also be security conscious, otherwise it will turn into someone else taking their data by other means. running a mail server is not for an average user.

it should be expected that if someone is trying to host a mail server they have some basic security protocols in place. you would also not want to run a mail server on the same ip as you are running everything else you might have open. separating out the mail server which has regularly exposed and attacked ports from the location you would access the web interface from is a very sound strategy. i have my mail server on a completely different ip from my web interface and on a different domain, which is where my proxy is running.

i do feel there could be some improvement to expose the nginx container a bit more to allow for some customization, how that is done is beyond me though, the developers for this project are much more skilled there so i hope some customization opens up. an example would be what I posted here about the x-real-ip being passed from my proxy to the web interface. IP from my proxy coming over to nginx container

mailcow communityDiscussion

IP from my proxy coming over to nginx container

D disgustipated

I have probably a bit of a unique setup. I’ll outline that first VPS hosted pfsense and a linux server in the vps i have the public ip of the vps setup for the pfsense server and mailcow on the linux server in the vps. ports all forwarded over for regular mail function. this all works as expected.

3 1 30 Mar

bogdanovser · 2 May

we can move it to a separate reverse proxy, but then we need to worry about certificates for both the proxy and the mailcow. which is also quite feasible.
But now we have two nginx and two certbot. IMHO - looks like not best design…
it seems that it would be easier to have the ability to enter ip/CIDR for admin endpoints into the mailcow config.
Trusted IP - classic feature for all enterprise products. It is not necessary, but very convenient

Ddisgustipated · 2 May

bogdanovser for managing my domain certificates i have one instance of certbot on a separate server that handles them. I then move them around to the different web services that need them with a script.

what do you have a second nginx for? or are you referring to the built in one in mailcow that you dont need to manage?

bogdanovser · 2 May

yes, i’m about built in one in mailcow, and second – for revers proxy.

I understand that all these problems can be solved. no difficulty.
But we also can install a separate mail-filter and separate web-interface for mail, but mailcow has combined all of this. That’s why I liked it. (I get a quick, production-ready solution… almost…)
Therefore, it is convenient to use it as a separate independent service that does not require anything third-party.

This is my suggestion. Well, for now we will install a proxy near mailcow

Aaegide · 1 Oct

While a reverse proxy has indeed other advantages and I’d recommend it (WAF/…), in a situation where this isn’t possible but still desirable, you can put sth like this:

location /admin {
    allow 1.2.3.4;
    allow 2.3.4.5;
    allow 3.4.5.6;
    deny all;
}

location /domainadmin {
    allow 1.2.3.4;
    allow 2.3.4.5;
    allow 3.4.5.6;
    deny all;
}

into data/conf/nginx/site.ip-restrictions.custom and it will be merged into the Nginx container config as shown via docker compose exec nginx-mailcow nginx -T after container restart.

The changes survive updates as data/conf/nginx/*.custom is in .gitignore. It’s also documented here

docs.mailcow.email

Custom sites - mailcow: dockerized documentation

None

.

Note that this isn’t trivial for other paths (e.g. /SOGo/so) afaik. Regex-matcher e.g. won’t work for already defined nginx instructions, top-level overrides will conflict with mailcow defaults etc. Not saying it can’t be done, but ymmv.

I’d also recommend 2FA and so on, but this is an additional security measure that’s worthwhile and easy to implement. Sth. to be monitored on updates nevertheless… Updated this thread as it was the last such issue and turns up high in search results.