6

We currently have all our email stored on a Dovecot IMAP server in our internal network. Client machines on the network are able to connect and access their email.

Now we want to allow certain users to be able to connect in and view their email from the outside using IMAP. We currently have a firewall/router with a dedicated (unused) DMZ port. The way I see it we have two options:

  1. Set up port forwarding on the router to forward any IMAP requests on ports 585 or 993 to the server; the server can then validate the user.
  2. Attach a reverse proxy IMAP server to the DMZ of the router; this in turn can forward the IMAP requests to the server on the internal network (with the possible option of validating the user-name before doing so).

Does anyone have any suggestions/comments on the merits of either approach?

I'm find it difficult to think of any read advantages to having an extra reverse-proxy in the DMZ of a three-legged firewall, since it's pretty much just going to effectively be doing port forwarding anyway. ...Or am I missing something?

Wesley
  • 32,320
  • 9
  • 80
  • 116
FixMaker
  • 235
  • 1
  • 3
  • 9

2 Answers2

4

Port-forwarding the IMAP from the Internet to the LAN means adding a pretty selective forwarding rule. You don't have ugly things like dynamic port assignment happening on the server side (like you would with protocols like FTP or MSRPC). The exposure to the LAN is minimal, to my mind. You're relying on the IP stack on your IMAP server not to do anything stupid (since you're giving unsolicited inbound IP access to the server) and you're relying on the IMAP server software itself not to do anything stupid.

With the DMZ scenario you describe you're limiting direct IP connectivity for the IMAP server to the Internet, and you're limiting the extent to which the IMAP server doing something stupid can expose you to risk. You're trading the risk of direct IP connectivity to the IMAP server with direct IP connectivity to the IMAP proxy server, and you're relying on the IMAP proxy server software not to do anything stupid. There's still the possibility in this scenario that a vulnerability in the IMAP server could be exploited via the IMAP proxy, depending on how "stateful" the IMAP proxy is and how much "sanity checking" it does.

To my mind the DMZ approach is adding moving parts and complexity without adding much real security. I think you'd be better served port-forwarding to the LAN and using the effort you would've spent on the DMZ / IMAP proxy approach with making sure that you've got good logging for the IMAP server, password / lockout policies that resist brute force password cracking, and an alerting mechanism that lets you know if you're seeing unexpected traffic to the IMAP server ("never before seen" analysis).

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • That was pretty much my reasoning too, I just wasn't sure if I was missing something. Now all I've got to do is find out how to harden Dovecot... Thanks :-) – FixMaker Oct 27 '11 at 08:09
-1

I was facing a similar problem, and I solved it by adding a column "allow_remote_login" to my authentication database, and then I changed the sql command to authenticate users to:

SELECT email as user, password FROM users WHERE email='%u' AND (allow_remote OR %a != 144);

In dovecot.conf, I changed the listen line to list to both ports 143 and 144; where 144 is the one that the external port forwarding directs to:

listen = *:143 [::]:143 *:144 [::]:144
mgorven
  • 30,036
  • 7
  • 76
  • 121
user105797
  • 1