That's certainly a major improvement. And, if all that's happening is that managed machines are initiating the conversations to the machine in the DMZ, that should be sufficient, as long as the machine in the DMZ can't initiate conversations with the production subnets, I'd probably be fairly comfortable with that. Specifically, WSUS works on that model (though it doesn't require auth, or AD), and until I stood up DirectAccess, I thought hard about standing up that for our long-term mobile users.
I'd then be more concerned about host security for the machine in the DMZ, and wanting to make sure that it's not handing out nastiness to the managed machines that are talking to it. Kurt On Thu, Mar 14, 2013 at 3:19 PM, Ken Schaefer <k...@adopenstatic.com> wrote: > In general (not specifically to address this RDS issue): > You could create a second Forest in the DMZ, which trusts the internal > Forest, but not the other way around. Whilst the host In the DMZ would have > FW ports open to internal hosts, it has no access, per se, to any internal > hosts, and simply subverting the DMZ host doesn't give you any access to > anything internally. > > Cheers > Ken > > -----Original Message----- > From: Kurt Buff [mailto:kurt.b...@gmail.com] > Sent: Friday, 15 March 2013 6:04 AM > To: NT System Admin Issues > Subject: Re: Difference between port forwarding and DMZ > > Section 2.2 says "This is a more secure approach because an attacker has to > break both firewalls in order to get to the internal network." > > This is incorrect. All he has to do is subvert the machine in the DMZ, and he > has access to all of the resources in the production network to which the > machine in the DMZ has access. You've already done the work of subverting the > second firewall. > > I suppose you could set up IPSec connections, or perhaps as suggested an SSL > tunnel, but ISTM that it my caveat about the subverted machine in the DMZ > still holds. > > Kurt > > On Thu, Mar 14, 2013 at 11:34 AM, David Lum <david....@nwea.org> wrote: >> " I'll make another sweeping statement here: Don't put any machine in the >> DMZ that requires membership in your production domain. At that point you >> don't have a DMZ, you merely have another subnet of your production network, >> and basically no protection." >> >> How does this work, then? RDS Gateway servers need to be domain-joined >> http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-i >> n-a-perimeter-network-firewall-rules.aspx >> >> Dave >> >> -----Original Message----- >> From: Kurt Buff [mailto:kurt.b...@gmail.com] >> Sent: Thursday, March 14, 2013 9:34 AM >> To: NT System Admin Issues >> Subject: Re: Difference between port forwarding and DMZ >> >> On Thu, Mar 14, 2013 at 8:22 AM, David Lum <david....@nwea.org> wrote: >>> What’s the risk difference between a server in a DMZ (firewalls on >>> each end) and port forwarding from the Internet to a machine inside a >>> network perimeter? Scenario : I have PC’s that use port xxxx to talk >>> to a management server, I’m wondering of that server needs to be in >>> the DMZ (with that port opened), or if forwarding that port through is >>> functionally the same thing? >>> >>> David Lum >>> Sr. Systems Engineer // NWEATM >>> Office 503.548.5229 // Cell (voice/text) 503.267.9764 >> >> Go back to the fundamentals. >> >> Why do you have a DMZ - that is, what is the fundamental reason that you >> have a DMZ? It is to have a place where you can put machines that are >> untrusted, but to which your production network (and perhaps other untrusted >> networks) need access. >> >> So, if it's untrusted, and you need access, what is the fundamental thing >> you *DON'T* do? You don't allow untrusted machines unrestricted access to >> your production network. In particular, you don't allow machines in the DMZ >> to initiate traffic to the production network. >> Machines in a DMZ should only respond to requests for traffic from the >> production network, or if they need to initiate traffic to the production >> network, that traffic should be strictly limited and throughly examined by a >> proxy that understands the traffic in question. >> >> So: >> o- Where are the machines located that need access to your management server? >> o- Does the server initiate any traffic, or is it just the clients? >> >> If all of the clients are in the production network, and you have all of >> them under your control, then putting the management server in the DMZ is >> not required. If the clients are both in and out of the production network, >> put the management server in a DMZ and make sure you have a firewall that >> understands the traffic (an application layer gateway, or proxy). Simple >> port forwarding doesn't examine the traffic. >> >> I'll make another sweeping statement here: Don't put any machine in the DMZ >> that requires membership in your production domain. At that point you don't >> have a DMZ, you merely have another subnet of your production network, and >> basically no protection. It's possible that TMG could act as a proxy for >> something like this, but I'd be very nervous about it. >> >> Kurt >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
