The three card configuration is safer. With it, you can protect your public servers from hackers and if they do happen to get through, you can protect you internal network from your DMZ. Exchange Server? I'll let someone else bite on that one. DCOM? This can't be secured. DCOM can run on multiple protocols unless it's running from a 95 or 98 client, then it has to be TCP/IP. If it's running on udp, then the DCOM subsystem maintains the state, even though it's running over a stateless protocol. Remember, IP is stateless, but TCP adds state to it through an additional layer. One of the biggest security problems with DCOM, is that fact that it connects initially on port 135. This is the Remote Process Control port, and it's not the only service that can be accessed through this port. After a multi-packet negotiation, DCOM then reconnects at some high port, who's range is defined by registry entries, and defaults to 1024 > Port <= 65535. Any FireWall that is filtering DCOM, must watch the negotiation to see which port is being opened, in order to open up the appropriate port. Otherwise, you have to open a range of ports, and hope that trojans haven't been installed on your servers, listening in the same range. If you're running NT with DCOM, then DCOM will actually try multiple protocols to get through. You can view the protocols using DCOMCNG. If the client fails with one protocol, then it will try another. So it may try UDP on 135, then TCP on 135 then switch to NetBEUI on 139. It will also attempt to tunnel protocols over other protocols. It's a sneaky protocol in practice. If your clients are connecting through DCOM, then you definitely want your DCOM server on the DMZ. If a DMZ server is communicating from the DMZ into your internal network using DCOM, then you may be a little safer, but I wouldn't feel secure about it. Jack Dingler Michael Borkin wrote: > I have been called upon to re-design an existing network to allow the > hosting of a web and e-mail server. It is a pure Microsoft network > (95/98, NT, and W2K) that will incorporate a checkpoint FW-1 firewall > (actually VPN-1) as part of the design. My main questions at this > point have to do with the DMZ, what belongs there, and how to connect > it to the firewall and the internet. The connection to the internet > will come in over an SDSL router (brand unknown at this time), but > from there I have gotten conflicting advice. Should all traffic be > passed back to the firewall which will have 3-nic cards (1- Internet, > 2- DMZ, 3- Internal network), or should the router itself have two > ethernet ports (1- Firewall, 2- DMZ) and the firewall only have two > nic cards (1- Internet, 2- Internal Network) as well? The argument > for the 3-card configuration is that logging is better that way. > Meanwhile, the 2+2 argument is to keep as little traffic from being > able to flow into and through the firewall machine as possible for > both overhead and security reasons. I am leaning towards the 3-card > configuration based on the fact that it is the recommendation from > Checkpoint (or at least their vendors), but I would like to know if > anyone has any opinions before I decide. As for the machines in the > DMZ, other than the web server itself (IIS 4.0) I am not sure which > ones need to reside there and which need to be placed on the internal > network for the best security configuration. Below is described the > main services that I am concerned with at the moment. E-mail is > currently handled by an Exchange Server, but is also used for services > besides just internet e-mail such as public folders and internal > company mail. One person therefore recommended setting up an SMTP box > in the DMZ and having it dedicated to relaying internet based e-mail > from the outside back through the firewall (and vice-versa) to protect > the other information on the Exchange server. That sounded good to > me, but later when I was discussing this with another person I got a > totally different opinion. He said it was a bad idea to let another > box handle the e-mail and that to have the Exchange box on the > internal network would cause me to have to punch huge holes in the > firewall to let certain services through. Therefore, the Exchange box > needed to reside in the DMZ rather than behind it. What he said > really didn't make sense to me, because I would think that it would be > having the Exchange server in the DMZ that would cause me to have to > punch holes rather than the other way around. But, just because I > don't understand his reasoning doesn't mean he is incorrect especially > since he knows a lot more about firewalling than I do, so I ask which > is the better way to go? Next, is that the web server uses dynamic > html for much of the website content. This leverages both a SQL > server and DCOM programming built through Visual InterDev to deliver > the content to the web server. This is where it really goes over my > head at the moment, if it was just SQL server then I know to place it > on the inside and let the calls from the web server come back through > the firewall. However from what I have been told by a developer, DCOM > uses dynamic port allocation when establishing a stateful connection > (although from what I have read it uses udp, so I don't know why there > should be a stateful connection). I honestly don't understand enough > to know where the DCOM part of the process sits (although I am > guessing it is on the web rather than the database server), and > whether this means that I have to open up a port range for DCOM to > work properly or to move the SQL server out to the DMZ (neither of > which sounds like a good idea to me). Also, I am not sure about what > ports or rules would need to be incorporated to get this to function > as securely as possible if everything other than the web server > resides behind the firewall. If anyone could either point me towards > reference material and/or give me advice about how the DMZ portion of > the network should be setup based on the factors explained above it > will be greatly appreciated. If you need any further information > before making a suggestion or recommendation, please feel free to > contact me either on or off list and I will be more than glad to do > what I can to fill in the gaps. Thanks, Mike
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:02:29 PDT