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-in-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

Reply via email to