Restrict IP for location /admin/ with nginx

gorby

Hello community,

I’m trying to use nginx to restrict the access of mailcow UI for /admin/ location.
I followed the docs (https://docs.mailcow.email/manual-guides/Nginx/u_e-nginx_custom/#new-site) 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

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

bogdanovser

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

esackbauer

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

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

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

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

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

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.

disgustipated

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. https://community.mailcow.email/d/4749-ip-from-my-proxy-coming-over-to-nginx-container

bogdanovser

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 😉

disgustipated

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

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 🙂

aegide

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.

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.

dragospop28

Hello!
I have found another option on how to restrict access to /admin without any other problems to other paths eg./SOGo.
Add the below piece of code in data/conf/nginx/site.ip-restrictions.custom in order to have it merged with the config that is already present. In the below example we are permitting the following IP Adddreses: 192.168.1.1-192.168.1.255.

if ($request_uri ~* "^/admin") {
    set $admin_access 0;
}

if ($remote_addr ~* "^192.168\.1\.1\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$") {
    set $admin_access 1;
}

if ($admin_access = 0) {
    return 444;
}

NOTE: IP CIDRs(eg.192.168.1.0/24) won’t work because they will break the Mailcow routing for /admin/* eg. /admin/dashboard therefore we have to use regex.

Return code of nginx can be modified from 444 to 403 or whatever status code you want: HTTP_status_codes

If you want to grant permission for one or two IPs then you can use it like this:

"^192\.168\.1\.50$"
"^192\.168\.1\.(50|100)$"

If you want to grant permission to a whole subnet use the following:

"^192.168\.1\.1\.([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$"

@bogdanovser maybe you want to give this a try since I saw that you don’t really want to have a reverse proxy.
@gorby by doing this the reverse proxy won’t be needed anymore.

stefan21

If you are with a private mailcow on a Linux OS, this is an easy approach:

create a appropriate cert for NPM (DNS-Stuff…)
install and configure ufw
install and configure fail2ban with a sshd, ufw and npm jail
configure NPM for a self cert
configure NPM for mailcow

Follow the instructions you’ll find in the web. Take care for your own IP (don’t lock yourself out) or use a VPN to connect. Take also care for logrotation and the logs, fail2ban needs to read from npm and ufw.

Personally I like the rule: “one false knock, and out”. My banned IP list from NPM is actually 286 IP’s, the one from the ufw jail is 8935 IP’s.

Depends on your rules, of course.