Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Multi-Node Installation behind Firewall and NAT, with Web Proxy Issues

  1. #11
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    First of all, I'm sorry i haven't replied earlier but some other things came up, and we we were not able to advance this pilot for a couple weeks.

    Well now that I'm back on it again, I'll start by answering each reply. Thank you all for your collaboration in advance.

    Quote Originally Posted by Bill Brock View Post
    that you put your proxy on the WAN. I'm just suggesting you put the hosts file entry in your proxy so it is forced to hit the mail server using the LAN IP address instead of the DNS resolved public IP address.

    Also, correct me if I'm wrong, but any machine sitting in the DMZ is accessible by the Internet. It's basically a one to one NAT map of your public IP to a private IP. So why would you be willing to compromise a mail server in the DMZ but not put a WAN card in a proxy server? A firewall running an appliance is no more secure than a firewall running on a PC. Again, I'm not suggesting you use a WAN interface on a PC if you are not comfortable doing so. But it is no less secure than a computer sitting in the DMZ.
    Bill, I don't think you understood our setup, our proxy IS in the DMZ and can reach the NAT'ed private address of our mailbox servers just fine.

    The problem is when the Route Handler (sitting on our LAN, and therefore resolving names in the internal DNS server, to the private addresses of the LAN servers) returns when queried, the NOT NAT'ed private address of the mailbox server, to the proxy. Then obviously the proxy can't reach the private LAN.

    Quote Originally Posted by LMStone
    Not sure I understand your network config...

    Are you saying the proxy/MTA server and the DNS server have public IP addresses and the Zimbra LDAP/mailstore and Internal DNS servers have private IP addresses?

    Are you also saying DMZ DNS server supplies just public IPs, whereas the Internal DNS server supplies private IPs?

    Please also supply the /etc/hosts and /etc/resolv.conf files for the Zimbra servers. You can change the IPs/hostnames if you like.

    Thanks,
    Mark
    Mark, I'm gonna try to explain our setup a little better:

    Intranet - Private subnet
    Firewall - Separation between subnets, communication is done with NAT'ed IP's of Intranet subnet to the DMZ subnet
    DMZ - Private subnet
    Internet - Public (we aren't doing NAT to the outside at this moment, as this is just a pilot and it isn't fully functional yet)

    Intranet:

    Zimbra LDAP/Store:
    Private IP in the Intranet subnet;
    Resolves names at the Internal DNS;
    Has a NAT'ed IP on the DMZ subnet.

    Internal DNS:
    Private IP in the Intranet subnet;
    Resolves all the servers in the Intranet to their private Internal LAN IP's;
    Resolves the MTA/Proxy server in the DMZ to it's IP on the DMZ subnet.

    - Firewall -

    DMZ:

    Zimbra MTA/Proxy:
    Private IP in the DMZ subnet;
    Resolves names at the external DNS;
    Can reach the NAT'ed IP on the DMZ subnet of the Internal LDAP/Store server just fine.

    External DNS:
    Private IP in the DMZ subnet;
    Resolves the MTA/Proxy server in the DMZ to it's IP on the DMZ subnet;
    Resolves the LDAP/Store server in the Intranet to it's NAT'ed IP on the DMZ subnet.

    All the servers have only the localhost entry in /etc/hosts.
    All the servers have the corresponding DNS server in /etc/resolv.conf depending on their location, as I mentioned above.

    I dont think pasting the results of cat'ing those files here would be necessary as this already is going to be a huge post, and the 2 lines above are perfectly clear (I think).

    Quote Originally Posted by Rich Graves
    The simplest fix would be a DNAT on your proxy server. It's silly, because you'll be NAT'ing twice (where each NAT simply reverses the other's work), but you wouldn't have to change anything about either Zimbra or your firewall setup.

    -t nat -A PREROUTING -d (private ip) -j DNAT --to-destination (public ip)

    As far as any Zimbra server knows, the DMZ server is communicating directly with the private IP address.

    That will satisfy any policy requiring separation of application and database servers.

    But consider that your Zimbra MTA/proxy host in the DMZ will likely have Zimbra superuser credentials available in cleartext via zmlocalconfig. The :7071 admin port may be firewalled off, but if you have LDAP write access, you can change the server configuration, or any user's password. Depending on your needs, putting Zimbra on a single host on the internal network and using a non-Zimbra antispam appliance and a non-Zimbra passthrough might make more sense. nginx is a load-balancing tool, not a security tool.
    06-27-2009 12:51 AM
    Rich, yes that would work because the main problem it's in the fact that there is a NAT between the two subnets, reversing the original NAT with another one would definitly be a workaround.

    About the fact that the superuser password would be available in clear text in zmlocalconfig, I don't know if I'm doing things right but grepping zmlocalconfig returns all passwords not visible:

    Code:
    zmlocalconfig | grep password
    
    ldap_amavis_password = *
    ldap_nginx_password = *
    ldap_postfix_password = *
    ldap_replication_password = *
    ldap_root_password = *
    mailboxd_keystore_base_password = *
    mailboxd_keystore_password = *
    mailboxd_truststore_password = *
    mysql_root_password = *
    zimbra_ldap_password = *
    zimbra_logger_mysql_password = *
    zimbra_mysql_password = *
    What do you guys think?

    I have a couple of ideas that Im gonna try out and then let you know the result.

    Thank you for your collaboration.

    Regards,
    Miguel

  2. #12
    Join Date
    May 2007
    Location
    Oklahoma
    Posts
    703
    Rep Power
    9

    Default You are right, I don't understand.

    But I do know that the proxy server will resolve from it hosts file before it resolves from the DNS server. If the private (LAN) IP of the mail server is entered in the hosts file of the proxy server, it will hit the mail server with that IP and not the WAN IP. Your Internal DNS server will not even be involved at this point.

    But since you say this won't work, and I am assuming you have tried it, then I completely don't understand the issue and hopefully others in the forum can help you.

  3. #13
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Quote Originally Posted by Bill Brock View Post
    But I do know that the proxy server will resolve from it hosts file before it resolves from the DNS server. If the private (LAN) IP of the mail server is entered in the hosts file of the proxy server, it will hit the mail server with that IP and not the WAN IP. Your Internal DNS server will not even be involved at this point.

    But since you say this won't work, and I am assuming you have tried it, then I completely don't understand the issue and hopefully others in the forum can help you.
    Bill, I appreciate your help. But as I said, you are really not understanding our setup.

    If you read the explanation i tried to give to Mark, you'll see that our Proxy isn't on the same subnet as the Mail server, therefore having the Mail server IP in the Proxy hosts file won't do any help as we'll have the exact same problem that we have now, a host in the DMZ trying to connect to an IP in the LAN.

    Another thing you said that I think it's not correct is the order in wich the proxy does name resolution. In my understanding, the proxy will use whatever priority of choice on name resolution that is present in the Operative System, and that order is perfectly customizable, simply by editing the /etc/host.conf. But as I said above that doesn't help me solve this problem either.

    Thanks,
    Miguel

  4. #14
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default

    All: the nginx router returns IP address, not hostname. The normal use of a nginx proxy is to front-end a bunch of backend mailbox servers, all invisible to the end user.

    Miguel: "zmlocalconfig -s" shows passwords. My point is to document what you're trying to achieve by separating the mailbox server and the MTA/proxy, and make sure you're actually achieving that goal. If your policy is that any suspected-compromised DMZ host should be disconnected and rebuilt immediately, then your proposed layout does help with that; it is far easier to reinstall a fresh MTA/proxy from scratch than a mailbox backend. But if your goal is to protect confidential email from external attack, then I don't think that the separation adds anything but extra work for you.

  5. #15
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    Quote Originally Posted by Mcnf View Post
    Bill, I appreciate your help. But as I said, you are really not understanding our setup.

    If you read the explanation i tried to give to Mark, you'll see that our Proxy isn't on the same subnet as the Mail server, therefore having the Mail server IP in the Proxy hosts file won't do any help as we'll have the exact same problem that we have now, a host in the DMZ trying to connect to an IP in the LAN.

    Another thing you said that I think it's not correct is the order in wich the proxy does name resolution. In my understanding, the proxy will use whatever priority of choice on name resolution that is present in the Operative System, and that order is perfectly customizable, simply by editing the /etc/host.conf. But as I said above that doesn't help me solve this problem either.

    Thanks,
    Miguel
    Hi Miguel,

    I think I understand your network setup correctly now, thanks.

    I've reread this whole thread and what is not entirely clear to me are the specific security exposures you are trying to address with this proposed architecture.

    Although Zimbra runs nicely on multiple servers, Zimbra does require a fair amount of inter-server communication. For example, an MTA server does LDAP lookups to check for valid recipient email addresses. So, putting the MTA server in a zone separate from the LDAP server doesn't buy much additional protection for the LDAP server. (Plus, there is a performance benefit to running an LDAP replica on busy MTA servers.)

    So if we can shift the conversation to your specific security concerns, then I think we will be in a better position.

    OK?

    All the best,
    Mark

  6. #16
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Rich, the goal with the separation requirement is as you said grant some level of protection of the mailbox servers, preventing that those box's are directly connected to the "outside world".

    I didnt realize until now that the information could be exposed anyway as you mentioned, by having the passwords cleartext'ed in the proxy config aswell.

    Now I'm thinking the better solution would probably be, a single box and a non-Zimbra Proxy as you said.


    Just to get this out of my mind,

    You also said that, by having the admin port firewalled the proxy servers will still have access because of LDAP writing access.

    Is there a way to only allow proxy to have ldap read access?

    Because we're using a non-Zimbra LDAP server synchronizing with the Zimbra LDAP and as we are not allowing users to change their LDAP information, that way we wouldn't need the supersuser passwords in the proxy config and would be much more secure.

    But Im thinking that not having those passwords would influence other services and something wouldn't work aswell.

    Is this making any sense?

    Regards,
    Miguel

  7. #17
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Mark, as I told Rich,

    the goal is to grant some level of protection of the mailbox servers, preventing that those box's are directly connected to the "outside world".
    [...]
    Now I'm thinking the better solution would probably be, a single box and a non-Zimbra Proxy...
    Mainly, protect the user information aswell as the mailbox's data is the main goal.

    Thanks,
    Miguel

  8. #18
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    Quote Originally Posted by Mcnf View Post
    Mark, as I told Rich,



    Mainly, protect the user information aswell as the mailbox's data is the main goal.

    Thanks,
    Miguel
    Thanks Miguel for the clarification.

    The architecture we use for very high security email environments is as follows:
    • Use an MTA gateway server of a different architecture (e.g. a plain Postfix box) as the MX for the domains. A periodic Zimbra LDAP export push onto the MTA box is used for populating the box with a list of vailid email recipients and domains. This gateway server is in a different firewall zone or even a different data center.
    • Locate all of the Zimbra servers behind a firewall, without NAT, and require end users establish a VPN connection (or use a NAC device or PKI) to connect first, thereby adding another layer of easily revocable security before anyone can even begin to talk to the Zimbra servers, and ensuring only pre-authorized users can even attempt a login to Zimbra.


    Basically, I'm proposing you "cocoon" your Zimbra system rather than try to separate out into different firewall zones different portions of Zimbra, which we have always seen as a unified appliance (albeit one that scales well by adding more servers).

    Zimbra's components expect inter-server communication (MTA needs LDAP!), and regardless of whether you use Zimbra Proxy or not, mailbox data is only a login away from the Internet (which is why we insist on strong passwords!).

    This may not be what you wanted to hear, but the cocooning need not be a pain for users; the Cisco VPN Client software for example generally works well we have found even with non-technical users.

    Hope that helps,
    Mark

  9. #19
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Than you for your answer Mark.

    Some of the requisites are dependent of the architecture we're building the pilot on. And others are just established at first and can't be turned around.

    VPN's are out of the scene at the moment, and all servers in the Intranet must be NAT'ed when reached by the outside.

    With that, I think the best solution would be implementing 1 zimbra box with the complete suite behind the firewall and use a non-Zimbra passthrough at the DMZ, as we already talked about. Not really the GREATEST security possible but under the circunstances might be the most reliable solution.

    I'll give news when some more developments happen.

  10. #20
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    11

    Default

    Quote Originally Posted by Mcnf View Post
    Than you for your answer Mark.

    Some of the requisites are dependent of the architecture we're building the pilot on. And others are just established at first and can't be turned around.

    VPN's are out of the scene at the moment, and all servers in the Intranet must be NAT'ed when reached by the outside.

    With that, I think the best solution would be implementing 1 zimbra box with the complete suite behind the firewall and use a non-Zimbra passthrough at the DMZ, as we already talked about. Not really the GREATEST security possible but under the circunstances might be the most reliable solution.

    I'll give news when some more developments happen.
    Given the constraints I think you are on the right track there.

    Keep us all posted as to your progress!

    All the best,
    Mark

Similar Threads

  1. Replies: 2
    Last Post: 09-06-2006, 01:15 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •