A Forum reader recently asked:
“We have a single domain GroupWise 7.0.2 structure with a single server running POA, MTA, GWIA and WebAccess for 1 post office of 300 users. We want to implement some additional security to separate and isolate the Internet-facing mail services.
We have another server that we would like to deploy onto the DMZ, and we would like to put the GWIA and WebAccess services on the DMZ. It’s my understanding that we should create a secondary GW domain. That domain would have an MTA on the DMZ server that would be used to communicate back with the primary domain’s MTA.
I have 2 major questions about this process:
1) If we set up the secondary domain on the DMZ, I know that the GWIA would be installed on the DMZ server, but would both WebAccess Agent and application live on the DMZ server, or just the application, or just the agent? In this scenario, where is the best place for the agent and for the application?
2) I have heard conflicting information regarding whether or not to set up a second tree for the DMZ. Some say it’s essential for security, and others say that the limited ports opened to allow GroupWise and NCP to communicate across the firewall doesn’t demand a separate tree. What is the best practice, and what are some reasons for or against setting up a separate tree?”
And here’s the response from Jim Michael …
The WebAccess agent is the portion that “belongs” to a domain, so it needs to be local to its domain. The WebAccess application can exist on the same server as its agent, or remotely … it doesn’t really matter. In your example you would want the secondary domain in the DMZ
and put both GWIA and all WebAccess components on the same box.
It’s just my opinion, but having your production tree “in” the DMZ negates the purpose of a DMZ in the first place. You’d be better off leaving everything behind a single firewall and just letting the few pinholes in for SMTP, HTTP, TCP1677, etc. However, managing a separate tree in the DMZ can be a PITA … which is why I don’t like DMZs I much prefer to keep everything inside and reverse-proxy the “high risk” portions like WebAccess.
The key is that the agent needs to be *local* to its domain. Thus, if the agent is to live in the DMZ, you need a domain (MTA) in the DMZ so the agent can be installed to it. You do NOT want to put an agent in the DMZ that is part of a domain that exists on the private LAN. Doing so would mean the agent would need file system access (through the firewall) to the domain box … yuck It also makes for an unstable setup if any glitches happen on such a link.
As far as having the WebAccess application on the DMZ server – or the inside server – it depends. If you’re “set” on having a DMZ then your webaccess application should be there. Whether the agent the application talks to is ALSO in the DMZ or on the private LAN doesn’t matter; both work equally well. On the other hand, there are some (like me) who think DMZs
create as many problems as they solve, and things like reverse proxies and careful packet filters can be just as effective.
Having the DMZ server in the same tree limits the exposure in theory, but the fact remains that access to your tree is now “outside” of your internal firewall. I consider that a worse threat than the problem you’re trying to solve … that is, to secure specific services. Using the same logic, if your SMTP server and web server are not in the DMZ and behind the private LAN, “if only those few service ports” are pin-holed through the firewall, isn’t that just as effective?
It will definitely work on a single tree. You just have to weight the risk of exposing your tree outside of the internal firewall vs. the security you’re trying to enhance.
It makes the most sense to install the WebAccess application and agent to the same box. There is no technically superior method (in my opinion) to either scenario, but it makes more LOGICAL sense to keep them together. The only difference between the two scenarios is the ports you need to pinhole through the firewall. In the case of only the application in the DMZ, it would need to talk to the agent on TCP 7205. In the case of both existing in the DMZ, the agent would now need TCP 1677 (for multiple destination IPs, if you have more than one POA) to get to the POAs.
If machines in the DMZ are compromised, they have limited exposure to the private LAN. But my point is that administering such a setup (and exposing things like NCP that would never need exposing AT ALL if you didn’t need a server in the DMZ in the same tree) can be a
nightmare and can lead to errors in misconfiguration that could be worse than the problem you’re trying to solve. It’s all a matter of degrees, and if you’re “perfect” about the configuration, and don’t mind the PITA of managing DMZ servers, it is more secure, yes. For *us* the benefit does not outweigh the negative aspects. For you, it does (or seems to.)
Why do I think its a PITA to manage a server in the DMZ? This is because I’m always coming from the angle of exposing a NetWare server that belongs to your production tree in the DMZ is dangerous. So, the only way *I* would put a WebAccess/GWIA in the DMZ is if they are in a different tree, and that’s where the PITA management comes in … just having to authenticate to the other tree and manage these “separate” objects is bothersome. However, if you’re comfortable with the production tree living in the DMZ, then this is a moot point – and the management of that server is no more difficult that normal.