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.

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

@"esackbauer"#p23923 I have the same task for my server. Why can't we use nginx from mailcow-dockerized for it?

@"bogdanovser"#p24546 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.

@"esackbauer"#p24547 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?

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.

Hi @"esackbauer"#2109 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 :)

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...

Hi @"esackbauer"#2109 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.

@"gorby"#p24633 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

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 ;)

@"bogdanovser"#p24699 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?

Restrict IP for location /admin/ with nginx

CK_beats

mx8
Thank you for this information!
I also recorded the path. Is now rejected with error 403.

mx8

It’d be awesome if there were two separate sites using SNI:
Site 1 would be for all admin activity
Site 2 would be for lower permission level, non-admin user activity

Then we could just expose the non-admin site to the internet and keep the admin site on the private network.
I know that would be more legwork on the dev side, probably require some api changes for permission levels, but it sure would add value to Mailcow

TellMeMore

I think i secured my server for now after an attack. but i would love to see a full on guild (if not yet exist) on how to do each security step. I do know i need to do more for instance SSH Keys instead of passwords. it took me alot of time to get most of it sorted. by default i think mailcow can do better with a QA setup script with clear instructions and guidance, checks for security, or send a email of possible attacks happening, In my case they where able to find a password of one of my mail servers within the first month and exploited to send 1000’s of emails that i would not see being sent as they used it as a template to do there dirty work. I was blacklisted. and did not even know about it until i could not send emails. Since i moved my server to cloud flare but lets be honest, you cant have mail servers with proxy’s on, can you? i was also using IPV6 at the time, the damage is unbearable. There has to be away to have measurements in place that will warn us. and i am not just talking about abuse@domain.com

CK_beats

But that’s not nice to hear! I’m sorry for you, your mail server and your reputation!

How could this happen to you so quickly that the password was found out?
Normally Fail2Ban responds after 5 (?) attempts and blocks the IP (factory setting).

Was the password that easy to “guess”?

esackbauer

And why did you not enable 2FA?

TellMeMore

this is when i was moving all my mail servers over to mailcow. Fail2Ban was not strong enough back then, the settings where at default, i was being brutal attacked. i kept seeing all kinds of attacks. Attempts in SSH, email logins etc. Little did i know fail2ban that comes with mailcow does not include SSH, i had to make my own firewall on that. I was learning Mailcow and still learning mailcow. i turnd off port 25 and did alot more. and no i did not have 2fa enabled at the time and unfortunately i will not be able to enabled it fully for all my mailboxes. i have to many emails that i run solo, (Unless i get a key or paid service) The Admin account does have 2fa. I am aware that’s not enough. however i did for now disable outbound email and allowed inbound for the emails on the emails i do not use for outbound. I think mailcow is awesome and does already have alot of security in place. a simple setup is not enough though. a guild to secure the server and a guild for setup. The password was not so easy to guess. it was random. i made fail2ban ban IP Address for longer times such as a week or month. that’s when i saw the attack less.

« Previous Page