Firewall Wizards mailing list archives
Re: IMAP- how to protect a server?
From: "Steven M. Bellovin" <smb () research att com>
Date: Thu, 03 Jun 1999 21:48:32 -0400
In message <Pine.SO4.4.02.9906031134080.15597-100000 () carerra corp vicinity com> , "Aaron D. Turner" writes:
Hmmm... I guess this brings up a good question. How good are the SSL implimentations? My understanding was that SSL was pretty solid. Sure I could give all my users SecurID tokens and SecuRemote to access email, but I'm going to get a lot of phone calls at 3am from pissed off Sales people traveling in Europe who lost it or forgot how to use the dumb thing. Also, putting the IMAP server in a DMZ may protect my other servers and it from them, but it doesn't solve the issue of securing the data on the mail server itself. If the IMAP server has a buffer exploit then I'm kinda hosed no? One person suggested a proxy to protect the server, but then I got to thinking- how does the proxy inspect the content of the packets if they're encrypted? Or does the fact that the connection is encrypted make the buffer exploit moot? The more I think about it the more confused I get. I know some one on the list has actually done this- secure an IMAP server (it's content and the connection between it and the clients). It's not like IMAP is some wacky unused protocol that only runs on Atari 2600's.
There are several separate pieces to this problem. Bear in mind that there are no perfect solutions, merely a tradeoff between different sorts of risks. First -- *no* application is inherently "absolutely secure". It doesn't matter if it's a host-based application or an application-aware proxy on a firewall. Applications are programs, and are therefore buggy. One can hope that firewall applications are written by more security-conscious programmers -- but frankly, I wouldn't count on it. Second -- if the IMAP server is compromised, the mail folders on it are at risk. That's going to be true whether the server is inside or outside the firewall. If the only access to that server is the IMAP port, in that respect it doesn't matter where you put it; the purpose of the machine is to offer up IMAP, which will be just as risky inside or outside the firewall. You may be better off with it outside, though, for one reason: a failure won't endanger the rest of your inside machines. There was an important caveat in that analysis, though: I specified that the "only access" be via IMAP. That, of course, ignores the question of how mail is to be delivered to the IMAP server. Do you trust SMTP clients that outsider access? I have serious qualms there, though I haven't heard of any serious sendmail holes lately. And there are other choices, such as postfix. Finally, you could write your own program that would "pull" the mail from the inside. (Of course, you still have to have *something* listening to external smtp.) Call this the fundamental law of firewalls: an application whose purpose is access by outsiders can't be protected by a firewall. A corollary is that a machine that runs only such applications can't be protected by a firewall, either. You specified that you want to use SSL to protect access. SSL can do two things: encryption and authentication. Which do you want? Encryption is the easy one; however, an encrypted channel between a hacker and a buggy application will still let the bad guys in. If you're using client-side certificates, SSL can provide access control; in that case, however, you're betting the complexity of the SSL implementation (and hence its correctness) against the complexity of the IMAP implementation. Certificate access does have the advantage that users aren't sending their passwords to a possibly-compromised application; an easy work-around there is to make sure that different passwords are used for email access than for login. (Also caution your users that they should check the certificate of the server after connecting but before they type their password. Then enforce that by using a different certificate one time out of a hundred, and reaming out the users who don't notice...) Is the SSL certificate-checking code likely to be complex? Yup. IMAP? Yup. Is there a clear winner? Nope. What, then, should you do? The best choice is to get out of the game entirely. For example, you may be able to write a simple IMAP authentication program that runs outside the firewall; if authentication succeeds, let it log in to the real IMAP server on the inside. Using SSL is still a good idea -- there are serious threats of session hijacking and data compromise. But there is still complexity in that part of SSL (as, indeed, in any cryptographic module that handles X.509 certificates). You're still at risk if someone can compromise an account, and then compromise the IMAP server. It isn't clear to me how great a risk that is. If you're afraid of that, follow another poster's advice and have the real IMAP server separated from your other inside machines by a firewall.
Current thread:
- IMAP- how to protect a server? Aaron D. Turner (Jun 02)
- Re: IMAP- how to protect a server? jacob carlson (Jun 03)
- Re: IMAP- how to protect a server? Ge' Weijers (Jun 03)
- Re: IMAP- how to protect a server? Aaron D. Turner (Jun 03)
- Re: IMAP- how to protect a server? chuck (Jun 04)
- Re: IMAP- how to protect a server? Aaron D. Turner (Jun 03)
- <Possible follow-ups>
- Re: IMAP- how to protect a server? Steven M. Bellovin (Jun 04)
- RE: IMAP- how to protect a server? sean . kelly (Jun 14)
- RE: IMAP- how to protect a server? Mayne, Peter (Jun 14)
- Re: IMAP- how to protect a server? Carric Dooley (Jun 14)
- Re: IMAP- how to protect a server? Ge' Weijers (Jun 14)
- Re: IMAP- how to protect a server? Aaron D. Turner (Jun 14)
- Re: IMAP- how to protect a server? Ge' Weijers (Jun 14)
- IMAP who provides CERT support (was Re: IMAP- how to protect a server?) chuck (Jun 14)
- Re: IMAP who provides CERT support (was Re: IMAP- how to protect a server?) Andy Smith (Jun 15)
- Re: IMAP- how to protect a server? Ge' Weijers (Jun 14)