Mailinabox: Security: Change ports for webmail and admin

[sshelton76]

It's extremely insecure to have webmail and admin on the same box, but having them running off the same port is just nuts. Could you please add an option to move these to separate ports? I realize we could do this with some changes to nginx.conf, but having the option at install would be far better.

[anoma]

Can you expand more on why two ports are better than one in terms of security i.e. what you also plan to do if this is implemented.

[sshelton76]

It's more secure to have email and admin for email on separate ports for a number of reasons.

The first reason is called "attractive nuisance". Any user on the system can go directly to the admin pages simply by removing parts of the URL and because they can, they occasionally will. It's a temptation to try and break in. If admin and webmail are on seperate ports, this becomes far less attractive.

The second reason is to permit access control via firewall. If the admin pages are on their own separate port, you can restrict access directly in the firewall. Then if you need to do an admin task requiring the admin web interface, it is very simple to write a script to grant access through the firewall for say an hour or two in order to allow the admin to do their job and the script can lock the door on the way out. You can do all of this without interfering with webmail if admin and webmail are on different ports.

The third reason is related to the first. If these things are sitting on well known ports such as 80 and 443, then anyone pulling your DNS record has most of what they need to in order to compromise you. They just go to https://mail.mydomain.com and it drops them right at the admin page. If these were on alternate ports, they would need to port scan the entire server looking for something serving https. That it time consuming, but it is also something that can be detected and mitigated, thereby preventing discovery all together.

The fourth reason is that not everyone wants webmail. We for example don't use it at all, preferring to stick with good 'ol IMAP and SMTP. If webmail is on a different port than admin, then it can be firewalled off while leaving admin in tact. It also means a simple script can be written to enable / disable webmail &/or admin as needed without impacting the rest of the services.

[JoshData]

Hi. Those are good points.

As a general rule, I don't include security-through-obscurity practices in Mail-in-a-Box. They can be good practices, but the obscurity part conflicts with other objectives of this project, like that it be easy to understand and maintain. I hope for Mail-in-a-Box to be secure and also completely transparent about how it works. (That's in response to your points about "attractive nuisance" and port scanning.)

Your other two points relate to ease of configuration. While we want Mail-in-a-Box to work in a variety of environments, we probably don't have the capacity to create a project that has a more complex configuration to support those sorts of things. I'm always open to making _small_ changes in Mail-in-a-Box that makes is more configurable, but splitting up services across ports isn't likely to be a small change.

One thing that I'd find more concerning would be a cross-site attack. Putting user-generated content (e.g. emails viewed in webmail) on the same origin as an administrative function can allow for a sort of cross-site attack where a script in user-generated content accesses information that should be private to the administrative function. For instance, a script in an email uses saved credentials for the Mail-in-a-Box control panel to make an administrative change in the control panel. We assume that Roundcube and Nextcloud (the two services running on HTTP on a box's primary domain) have protections in place for this (since they would themselves be susceptible to similar attacks), however, so we don't address it specifically.

[sshelton76]

It's not security through obscurity though. If you think that, then it's because you don't really understand the term. Security through obscurity means you add nothing and are relying on the ignorance of the attacker. Here we do add something, we move the admin interface to a bespoke port. Then we disable the admin interface until the admin explicitly turns it back on. By keeping it disabled and offline it cannot be attacked.

This is isolation and separation of concerns, as well as the principle of least privilege action.
They are vital parts of a well designed security plan.

Serving the admin interface from the same port as the webmail and other user services makes it harder if not impossible to mitigate attacks against the admin interface and yes the API itself should also be on another port, but since it is part of the admin core web interface I don't think that's possible without a substantial rewrite.

You are right that the current design leaves one vulnerable to XSS as well. I had thought of that but did not mention it because I felt it too obvious. Eitherway this system is vulnerable and a simple config change makes it less vulnerable. Seems like something you would want to do in order to tighten things up a bit.

[api4user]

@sshelton76 I look forward to seeing your pull request so we can all perform a security audit on it.

[JoshData]

As I said, I'm open to simple changes. There are lots of things I would want to do. But there are constraints and goals in this project that are more important than tightening security a bit.

[sshelton76]

Well for now I'm just dealing with it by creating scripts to block web access all together via

ufw deny proto tcp from any to any port 80,443

Then re-enable it only when admin is needed.

But that approach reduces the utility dramatically, for instance I would love to have the API accessible to other processes.

I'll look into the ngnix config another day and maybe issue a pr but if security is a low priority I don't know how much of a priority I should make the PR. Seems to me some simple security steps would be a fairly high priority.

[JoshData]

As I said, I'm open to simple changes.