RE: [ActiveDir] DMZ to Internal LAN one-way trust via firewall

[Mulnick, Al]

If somebody were to own one of your NT4 machines (not that tough, now is it?) then they now have access internal to your network.  Simple as that.  It wouldn't be tough to see that it's a domain member of an internal domain via the lmhosts file (which is even better information) and then setup netcat or something similar to allow access to your internal servers.  It could start from any of a number of ports and the firewall would happily pass it along if you're using port passing.  Heck, hanging out in the DMZ collecting information wouldn't be too tough either since it's NTLM and it's straight over the wire (no transport protection).  Not that there's been any RPC hacks or anything, but if they own a DMZ host that has access to RPC internal coupled with the information available, I don't think a decent hacker would need very long to own your internal network resources.  They could build a decent map of your resources since those ports are open as well (browser etc).  That's way beyond my risk tolerance, but that's a company decision I supose.   I just seems a high risk move for the convenience of not having to do it better.  Why would this make sense vs. fixing the permissions and creating a second forest?  Most companies want a staging area for web page development to transition from dev --> testing --> qa --> production anyway.  There's tons of management tools that can make this easier for the security and the developers at the same time (content management?), so it seems to me that this request is just being lazy and irresponsible.   Your other DMZ servers are already at risk, but you'd be opening ports that could be used to exploit your internal network.  Treat the DMZ like an asset and upgrade it to something that has security to match the risk. NT4 doesn't do that anymore as I recall...   Al     From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 4:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DMZ to Internal LAN one-way trust via firewall Hi Al, good rant J   I think I can elaborate a bit...We can't use the separate forest idea that you mention as a best practice, because it's not a 2000 or above domain (the one in the DMZ). In fact, my first question was why don't we upgrade it first (as its own forest, of course).   The goal is that we have developers who manage the content and apps on these web servers, and we're trying to eliminate the accounts in the domain in the DMZ. So we're trying to see if there is a good way to allow the developers to use their internal AD accounts to authenticate to the DMZ domain via a one-way trust.   Anything more specific on what risks we'd face? (e.g. would it be possible with a one-way trust for a person who breaks in to an account in a DMZ domain to then cross over into the other domain on the other side of the firewall?)   Is there a "least wrong" way to do this?   <mc> -----Original Message----- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 3:55 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] DMZ to Internal LAN one-way trust via firewall   <shudder>   So, if I read this correctly, somebody wants to put lipstick on a pig?  My first question is why?  My second question is also why?  Why would you ever want to have authentication handled inside your firewall for web servers?  Why would you want to put in a single point of failure only relying on the PDCe?  Why would you want to fly in the face of best practices (use separate forests internal and external?)   IPSec is something that would be nice to have if they had a 2000 forest out there, but then again, see above.    Overall, I'd say that this is a bad idea for many reasons including the single point of failure (what if your PDCe goes down?), the lowered security possibilities of NT4 etc.  Hacking NT 4 is not going to provide much of a challenge to most script kiddies these days, IMHO.  Opening ports from a DMZ to your internal network doesn't buy anything but convenience in this situation and since it flies in the face of good practices, I hate to see it running.   Fix your BAS DMZ domain permissions and upgrade it to 2003 AD for control purposes.    The PPTP that he's asking about is available in Win2K and above, but for Win2K it doesn't work at start up.  That would only be shared secret vs. kerberos negotiation.    </rant>   From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 2:43 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] DMZ to Internal LAN one-way trust via firewall L & G, I'm sending this on behalf of one of our project engineers. Thanks for any assistance or advice.   1.  We have a 12-server (mostly 2000 web servers) NT 4.0 domain in our Checkpoint firewall-protected DMZ subnet.  All support is currently a mess of local and domain users, no security policy, etc. Making it a Workgroup isn't a popular choice given the number of servers and differences between. 2.  Therefore, we are looking to setup a one-way trust to our internal 2000 AD to support user authentication only.  I've read that the ports necessary for an NT 4.0 -> 2000 trust are the same as an NT -> NT (no LDAP, LDAPS, GC ports necessary), as long as you are pointing to NT4 PDC -> 2000 PDCEmulater.  Question - is this correct?? The list of ports I have is: From-To                                    Client Port(s)                             Server Port Service DMZPDC-IntPDC                         1024-65535/TCP                        135/TCP     RPC  DMZPDC-IntPDC                         137/UDP                                   137/UDP     NetBIOS Name *AllDMZServers-IntPDC               138/UDP                                   138/UDP     Netlogon/Browsing DMZPDC-IntPDC                         1024-65535/TCP                        139/TCP     NetBIOS  **DMZPDC-IntWINS Rep              1024-65535/TCP                        42/TCP      WINS *per article 179442 **optional - read below 3.  I've read both sides of the option regarding name resolution. In our environment, I'm leaning NOT to run WINS Replication across the firewall (use lmhosts instead), since the outside boxes only have to know the name of the internal domain and the PDC emulator, but I'd appreciate anyone's insight on whether or not the risk/benefit is worth the admin overhead of managing 10 different lmhosts files and the potential for single POF?  I've never been a fan of hosts or lmhosts, but it may make the most sense from a security perspective. 4.  I've also read about leveraging PPTP for the trust as well - but have had no luck finding documentation other than the port number. Anyone have any insight? Your assistance in verifying my information is MUCH appreciated.     Mark Creamer Systems Engineer Cintas Corporation Honesty and Integrity in Everything We Do