Is it possible to harden the Apache Server config or will the settings be overwritten when a new Version of Mail-in-a-box is out? For example, i`ve seen that X-XSS-Protection, X-Content-Type-Options “nosniff” etc. is not set-up out of the box. Same goes for -TSL1.0 (yes, i know the implications of not supporting some protocols) etc. This can be done manually without any problems, and usually Apache configs will not get overwritten, but i want to be on the safe side here. Thanks!
FYI: MIAB doesn’t use apache. It uses Nginx instead.
1 Like
Thank you @cromulus, but this does not render the question invalid. Anyhow:
Is it possible to harden the Nginx Server config or will the settings be overwritten when a new Version of Mail-in-a-box is out? And do you know the path of the file(s) responsible for header/SSL hardening? That would be great. Thank you!
I’m not sure what you mean by “harden”.
ssl config lives here:
/etc/nginx/conf.d/ssl.conf
and yes, it is overwritten every time you run the MIAB setup.
The nginx ssl config MIAB uses is pretty much state of the art, and should get you an “A+” on the qualsys ssl test.
If you have suggestions of how to make the nginx configuration more secure, please don’t hesitate to open up a pull request on GitHub!
1 Like
@cromulus I am not into GitHub, but:
I. Webmail: Roundcube is fixing important security vulnerability quite fast. Currently they are on version 1.2.4 and fixed issues like #5583, #5472, the “vulnerability in handling of mail()'s 5th argument”, #5401 etc. Currently MIAB is on version 1.2. (May 2016) or 1.2.1 (?) (Aug. 2016). A regular update of the Webmail client could help mitigate Webmail vulnerability and yes i know it is work. You are right that SSL settings give me confidence that basic security is considered and well implemented.
But when scanning the mail admin page (e.g. box.example.email/admin) the header seems not to be sent by the server or is misconfigured (therefore possible classical vulnerability issues arise: X-XSS-Protection, X-Content-Type-Options and Content-Security-Policy). Same goes for just e.g. box.example.email with even more issues: header setting alerts: X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Referrer-Policy and Content-Security-Policy. Those pages are different “entry points”. Qualsys SSL check does not check header configurations afaics.
II. I recommend to disable TLS v.1.0 (-tls1) completely as nowadays most users should not run into compatibility problems and doing this is a security plus, as “The bottom line is that TLS 1.0 is insecure and we must migrate away from it.”
III. The option to disable Owncloud (more secure fork: Nextcloud) (only) for those who do not sync address book and calendars would be a security plus. Cf.: Owncloud Security Vulnerabilities.
Having said that all with no professional knowledge; you are right that MIAB is pretty much state of the art otherwise and i have a huge respect for you guys doing this. Thank you!
2 Likes
- security issues with roundcube are just that, security issues with roundcube.
XSS is only a concern with untrusted, end user provided input. Nothing of the sort happens on the MIAB admin page.
If an untrusted third party is serving content from your admin page, you are already compromised.
-
should you desire to disable TLSv1.0 it’s just line 35 in
/etc/nginx/conf.d/ssl.conf -
There is much discussion about owncloud/nextcloud, etc. That’s a whole other kettle of fish.
1 Like
@cromulus I am not sure if your answers implies sarcasm or arrogance, or both… either way:
Exactly. And therefore keeping the system (such as webmail) up to date is crucial to mitigate problems. Means: Update on the MIAB side webmail more often (cf. August 2016 -> April 2017). That was my proposal: plain simple.
I am not sure if you understand Cross-site scripting well, as there are many different scenarios. Anyhow: adding around 3 lines in MIAB to mitigate such problems (even if you feel its completely unimportant) would for sure help imho.
Re TLSv1.0: It was my proposal to exclude TLSv1.0 permanently in MIAB (means: implement it in the distro) to make the system more secure (see link above) and you would not run into compatibility problems of users here imho.
Re owncloud: My point was obviously not on the OC/NC discussion, but on the proposal to implement the function of turning it off completely (disable-option at install). But on a side note: the community is changing to NC and NC seems the way to go (if).
These are proposals to make the system a bit more secure, these are in no way complains.
If you do not like them, just say it that way. As I said: I love MIAB and you are doing a great job @JoshData & Co.
@Filippos My general policy is to not fix hypothetical vulnerabilities. If you have found a vulnerability (meaning, you can demonstrate an ill effect), please report that on Github and then we can determine the right course to fix it.
With regard to TLS settings, we roughly track best practices. https://www.ssllabs.com/ssltest gives an A+ to Mail-in-a-Box boxes. We’re approximately at Mozilla Intermediate Compatibility (since we don’t know what end-user devices Mail-in-a-Box users are trying to support).
2 Likes
@JoshData Thanks. And I agree. Just FYI:
SSL Labs Test does not check header configurations afaics. X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Referrer-Policy and Content-Security-Policy are in fact not mitigated on “box.example.email/admin” and “box.example.email.” Doing this is pretty much state of the art and adding two or three lines would solve the problem for those “point of entries” imho:
add_header X-Content-Type-Options nosniff
add_header X-XSS-Protection "1; mode=block"
add_header X-Frame-Options SAMEORIGIN;
etc.
I can do it manually but as it gets overwritten every time one run the MIAB setup, it would be better to implement it in the distro.
SSL Labs themselves state that TLS v1.0 is outdated nowadays, and there is rarely an end user that even uses TLS v1.0 imho - so its worth a try but of course its all up to you. Just wanted to add (a bit more than) five cents. Feel free to ignore or implement whatever you feel right. See also: TSL v1.0 depreciation at pci.
SSL Labs Test does not check header configurations afaics
That’s why I said “With regard to TLS settings” before I mentioned SSL Labs. Because I was only referring to your point about TLS settings. I know very well that it does not check the headers.
there is rarely an end user that even uses TLS v1.0 imho
Look, your opinion about how many people use TLSv1 doesn’t matter. What matters is whether our users use it, and what happens when we remove functionality that someone is using. And whether there might still be important use cases that we should support, rather than cutting people off with old devices from being able to have secure email. Are you volunteering to spend some time surveying our users about TLSv1 usage?
Your link about PCI says their deadline is June 2018. It’s not even June 2017 yet.
And as I said before, if you want to propose a change in the headers, please demonstrate a security vulnerability that you are able to exploit. That’s not too much to ask. If you can’t demonstrate a problem, then there’s no reason to make a change.
1 Like
Just a thought on all of this, as I also agree with Josh, I’ve added the same nosniff and antitrace commands as well. Though on my apache webserver server, as well best practices for SSL within the apache virtualhost config files. (Since I host websites as well)
My feeling, is you can sure secure Nginx, on the browser, webmail front. Though the exception is, IF your clientele is using a desktop email solution (port 443) and of course port 587 etc. Securing webmail is not securing the entire server, but only one section of the larger whole.
I feel the real security lies within Fail2ban settings!
That`s correct. Therefore it was just my opinion as a possibility to make it more secure imho. As I said; “Feel free to ignore or implement whatever you feel right.”
@ricky1146 “Securing webmail is not securing the entire server” That`s exactly right, therefore I used the term “one point of entry”.
Anyone else with ideas for optimizing security (without a decreased usability)?
Why not run an nginx security hardening script after you upgrade?
Everything that’s currently in MiaB is there because Josh felt like it. Seeing as how you seem to be unhappy with the responses you’ve gotten so far, look up how to secure nginx to the max and customize your own instance.
1 Like
@netoperatorwibby @JoshData Guys; cool down. Nobody said i am unhappy.
.
Great idea! My proposal was only to include such things in the distro as MIAB gets overwritten every time you run the setup (eg. update) (see comment from Bill Cromie).
I made some proposals (take whatever you want), including to have the webmail updated regularly (to mitigate vulnerabilities) and reduce risks on frontends, and asked if somebody have other ideas as i think hardening would not be a bad idea in general. Maybe some people (including me) can stick together and focus more on the security part. Thats all. I don`t see the rationale of not doing things per se unless its is a lot of work and in no way proportionate.
Have a great evening and be well.
1 Like
I’d agree that it’s worth enabling some of the security headers Fillips mentions. There’s really very little downside (why would you choose to allow some types of XSS or clickjacking attacks?), and the entire point of their existence is to prevent whole classes of hypothetical vulnerabilities, not to fix known, existing ones. Qualys tests are for TLS config; An equivalent for headers is https://securityheaders.io, along with Ivan Ristic’s https://hardenize.com and https://se.cr
1 Like
Famous last words!
When you are responsible for an open source project with actual users who depend on the software to run, you will understand that no change comes without the likelihood of a serious downside.
2 Likes
Well then you know what I mean!
+1 that the setup should be further hardened.
With regards to TLS configuration, it should be pretty easy to programmatically implement Mozilla’s three recommended configuration profiles and allow the administrator to choose. Until then I am modifying files after each upgrade. 
3 Likes