Securely exposing web client to the internet

[mikelcu]

I know this seems like a moot point to public mail servers, but in my case we're in a corporate environment where the security requirements are quite different. Now that we have this swanky new web client in common use, I've had the inclination to make it available directly on the internet as opposed to our current VPN-centric setup. However, I'm concerned about directly exposing any part of our core mail server(s) to the internet.

Ideally, we'd have a separate machine in a DMZ that would handle the direct traffic, but so far it seems like I have to run nearly a complete ZCS install to get a fully functioning web client. Is it possible to run *just* a web client instance that would connect back to the core server? We may also need to make Zimbra Mobile available outside, is that a separate component or are they both just part of mailboxd?

Is there a official best practice in a scenario like this?

-mike

[Dirk]

Allow or port forward port 443 to the Zimbra server, nothing else (well, 25 obviously).

You already allow the world to reach the zimbra server on port 25, that's how email is coming in, adding 443 is not that bad.

I have my servers set in the same way, and I was worried about it too at first, but then I figured that googlemail, hotmail etc all have their webclient email servers configured to allow world access and they manage it, so why cant we?

I'm not aware of any exploit that can root a zimbra machine over port 25 and 443 so it should be safe. You can mitigate the risk with a local firewall on the zimbra server to further reduce it's access and add password policy will lock accounts on repeated failed password attempts in order to stop brute force attacks.

[mikelcu]

That is basically what we're looking at implementing; either punching a hole through the firewalls back to the web client, or getting the same end result by proxying through another server back to the web client. Basically this, applied to normal web access as well:

Zimbra Mobile Architecture - Zimbra :: Wiki

AFAIK, this should only require 443 though, the web client does not send directly to port 25. It still would be nice to run a standalone web/mobile install though...

-Mike

[tgx]

THe biggest issue is a user has a poor password and the account is hacked or compromised in some fashion. Easiest to exploit without getting technical. Unfortunately
difficult to enforce good passwords. Adding a two factor system onto Zimbra could give you another level of feel good, but there's a price. Compromised accounts can be used to send spam blasts and getting your site blacklisted. I don't think many people blacklist Yahoo!, Hotmail or Gmail...it's just not feasible, but your little joe.company could be very easily, so your concerns are valid. As for email account hijinx, if you have mobile phone users that access via IMAP, it's another point of entry.

It's about risk management really. Do your best to secure it, but don't spend every waking moment worrying about it either. If someone wants in, generally they'll find a way to get there. If the hassle is big enough though you can keep the majority out as they'll look for easier targets. Stay patched and do an occasional password audit, if your ultra paranoid, look for a two factor vendor.

[jholder]

I agree with the password complexity issue. Also, let's not forget that that Zimbra is several pieces of fallible software. The last thing you want is for there to be a jetty exploit, and you're open to the net when you had the option of VPN.

I would suggest vpn

(PS - We try very hard to prevent that type of issue, and there are no known issues...but it's the unknown that you're trying to protect against)

[mikelcu]

Exactly, it's the bugs that we *don't* know about that concern me, though I agree that historically there is no reason to be particularly worried. I agree password complexity (and rotation) enforcement is required for any decent level of security.

The only reason we're second-guessing a VPN-only setup is because:

1) crappy mobile devices with no VPN client (*cough* blackberry *cough*)
2) restrictive client sites with no way to VPN out

I think that we can get the best of both worlds by just implementing some kind of two-factor authentication for outside services, hopefully something that will work on mobile devices. If we can't find one, we might only expose services whose clients can handle two-factor of some kind. Client SSL certs jump to mind...they're something remote users could carry in a USB thumb drive. Who knows though... moving everyone to devices that can VPN might just be easier.

-M