Hi,
I’m worried seeing that default top menus are being displayed even some ones redirect to content without being logged-in yet…
Then I would like to protect this URL: https://box.domain.com/admin from public access with a given username & password or if not possible because .htaccess files doesn’t work…!? (normally used if Apache should be installed)
or at least
To know how to block direct public access allowing only some IP’s to view that page: https://box.domain.com/admin
Speaking in an unofficial capacity, with a solution that would technically render your warranty void should you decide to do it. If it were me, and I wished to implement option #1 and #2 as you have described them, I would be looking to use a .htaccess file in the /admin directory. The options that can be implemented in there can do all of what you have described.
With that in mind, I find the built in access controls sufficient for good security practices and would not myself implement such a change in this situation.
Thanks for sugestion… But seems there is not a real /admin directory (just a link /admin mentioned inside the nginx.conf file)
If you know where /admin directory is lated by default that could help me to apply at least one of security mesures I mentioned.
Thanks in advance,
Rgrds,
Gabriel, I don’t know if you figured it out back then but I managed to do following. In /etc/nginx/conf.d/local.conf I added a strict IP policy to the location directive for /admin
This checks if /admin is called from your (desired) IP and allows that or it redirects to webmail frontend for any other IP.
Again the file may be overwritten so I guess I’m going to remove write access to it for now. No idea what errors that will create down te line. At least that leaves some time to figure out if this is something that could be configured in a separate configuration file.
I can see why as well. The first domain / user I added the changes were overwritten. Even though the file was write protected.
Now my intention was never to leave it there. Just tried to point out another approach to help a fellow MiaB’er. I’m already looking into alternatives but it seems it is almost “impossible” to add or alter anything on this level and in this regard.
As far as I can see the box writes any changes in the domains to local.conf in /etc/nginx/conf.d/. Is there any reason these directives aren’t written to their own individual config files? That would allow altering local.conf so one could use it to secure things if they like.
Don’t know if this has been suggested before but to me it seems weird this wasn’t implemented in such way in the box since it is basically all I’ve ever seen anywhere else.
Yep, probably true. But that wouldn’t be such a problem to me. Not much to do there for the things I see people running in to as well. So these can stay relative untouched I guess.
The only time the local.conf would be changed in this approach is when te box is updated. If nothing significantly changed it even isn’t required then. Changes would be a little more persistent that way and it would thus allow for using local.conf to do HTTP AUTH on /admin and other parts.
My personal opinion (for what that’s worth):
I do understand you’d be opening the flood gates when you start to allow users to tweak their setups and most certainly this will make it a lot harder to be omnipotent.
I do think however that being omnipotent is more then just hard coding / writing a setup and configuration without consideration for what users are doing (or desiring to do) with their machines.
I can’t imagine that you’d want someone to start a fork just to add basic security features as HTTP AUTH to /admin or /cloud. I guess that’s definitely not in line with the project’s mission.
So to show I mean this in the most constructive and positive way possible I’d like to conclude this post with a question: where and how would such a “feature” request be best directed to be discussed in this project?
I do understand you’d be opening the flood gates when you start to allow users to tweak their setups
Exactly.
So here’s the thing: My time is limited. I have to prioritize what I do. As you might see from the forums, a lot of questions already go unanswered because I don’t have time to get to everything. I want the project to live up to its promise to be an easy, good mail appliance. I don’t have the time to make a project that lives up to a promise of being an easy, good, and customizable server configuration tool.
I can’t imagine that you’d want someone to start a fork
Forks don’t bother me…
basic security features as HTTP AUTH to /admin or /cloud. I guess that’s definitely not in line with the project’s mission.
All I’ve said is that endless customization is not a goal. Being secure, following best-practices, etc. are clearly listed as goals.
where and how would such a “feature” request be best directed to be discussed in this project?
Here (in a new thread) or on github as an issue or pull request.
Thanks for that last reply. I sincerely empathize with what you’re pointing out. After all time is your most valuable asset and I see indeed you’ve got a ton of other stuff to sort out as well.
Now as for my remarks. I see an active community and understand that you’re in no way against contributions from others so I’ll see what we can add. Since you point out Github would be a more suitable location for this I’ll cohere to that and have a look around there.
Again I’d like to stretch that I really love what you’re doing with MiaB. Keep it up and thanks!
Hi, I am a bit puzzled, you say the menus are populated once a user is logged in, but when not logged in I can still see my webmail address and email settings (not email accounts or aliases) in Mail>Instructions on the"Checking and Sending Mail" page and also the urls for Calendar and Contacts on the “Contacts & Calendar Synchronization” page.
Is it possible I have not set something up correctly or is this information always public?
