Re: Difference between port forwarding and DMZ
Big difference. If the Management server resides on the internal LAN, and it gets hacked, it has direct access to the LAN. If it resides on a DMZ, and gets hacked, it only has direct access to other machines on the same DMZ subnet, it is isolated from the Internal LAN. Depending on the configuration of the DMZ. Christopher Bodnar Enterprise Architect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459 3900 Burgess Place, Bethlehem, PA 18017 christopher_bod...@glic.com The Guardian Life Insurance Company of America www.guardianlife.com From: David Lum david@nwea.org To: NT System Admin Issues ntsysadmin@lyris.sunbelt-software.com Date: 03/14/2013 11:23 AM Subject:Difference between port forwarding and DMZ 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 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 ~ 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 - This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you. ~ 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 image/jpeg
RE: Difference between port forwarding and DMZ
I will make some assumptions. 1) You have allowed the port forwarding through the firewall ( therefore no inspection into the traffic to truly determine if it is what it proports to be) 2) If I can compromise the box in the DMZ, then I can use this to push into the Internal network based on the trust you have established via port forwarding. ( Evil hat on, setup a Netcat shell or Cryptcat shell to do the same thing and then sell the bandwidth and access to your compromised DMZ box to participate in global botnet fun, serve up malware, etc etc) (Ok evil hat off) 3) Leverage this trust on port forwarding to explore your internal network, or to compromise your internal network and have another system to leap frog to other systems and establish foothold, after this its game over... ( I just use your outbound bandwith with multiple compromised boxes, to attack other networks, etc etc) I hope this opens the window to the dark side of thinking in hacker methodology :) Z Edward E. Ziots, CISSP, CISA, Security +, Network + Security Engineer Lifespan Organization ezi...@lifespan.org Work:401-444-9081 This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. [Description: Description: Lifespan] From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 11:22 AM To: NT System Admin Issues Subject: Difference between port forwarding and DMZ 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 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 ~ 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.commailto: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 ntsysadmininline: image001.jpg
RE: Difference between port forwarding and DMZ
“Depending on the configuration of the DMZ.” This is an important point. Once the box in the DMZ is popped what traffic from it is allowed to the internal network needs to be considered. From: Christopher Bodnar [mailto:christopher_bod...@glic.com] Sent: Thursday, March 14, 2013 11:33 AM To: NT System Admin Issues Subject: Re: Difference between port forwarding and DMZ Big difference. If the Management server resides on the internal LAN, and it gets hacked, it has direct access to the LAN. If it resides on a DMZ, and gets hacked, it only has direct access to other machines on the same DMZ subnet, it is isolated from the Internal LAN. Depending on the configuration of the DMZ. Christopher Bodnar Enterprise Architect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459 3900 Burgess Place, Bethlehem, PA 18017 christopher_bod...@glic.commailto: [cid:image001.jpg@01CE20A8.D9CAE370] The Guardian Life Insurance Company of America www.guardianlife.comhttp://www.guardianlife.com/ From:David Lum david@nwea.org To:NT System Admin Issues ntsysadmin@lyris.sunbelt-software.com Date:03/14/2013 11:23 AM Subject:Difference between port forwarding and DMZ 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 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 ~ 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.commailto: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.commailto: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 inline: image001.jpg
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 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
RE: Difference between port forwarding and DMZ
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 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
RE: Difference between port forwarding and DMZ
And you make swiss cheese of your firewall. Thanks Webster -Original Message- From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 1:35 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ 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 ~ 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
RE: Difference between port forwarding and DMZ
And no longer have a DMZ by my definition. You just have another subnet for your domain. -Original Message- From: Webster [mailto:webs...@carlwebster.com] Sent: Thursday, March 14, 2013 2:45 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ And you make swiss cheese of your firewall. Thanks Webster -Original Message- From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 1:35 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ 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 ~ 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
RE: Difference between port forwarding and DMZ
Put an SSL reverse proxy in the DMZ and tunnel that to the RDS Gateway -Original Message- From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 2:37 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ 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 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
RE: Difference between port forwarding and DMZ
Correct. How does Citrix handle this? Member server in the DMZ yes? -Original Message- From: Webster [mailto:webs...@carlwebster.com] Sent: Thursday, March 14, 2013 11:43 AM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ And you make swiss cheese of your firewall. Thanks Webster -Original Message- From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 1:35 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ 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 ~ 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
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-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 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
RE: Difference between port forwarding and DMZ
Kurt hit the bingo... what I was covering from a evil prespective earlier... Z Edward E. Ziots, CISSP, CISA, Security +, Network + Security Engineer Lifespan Organization ezi...@lifespan.org Work:401-444-9081 This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. -Original Message- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: Thursday, March 14, 2013 3:04 PM 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 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
RE: Difference between port forwarding and DMZ
Citrix handles this via TCP port 443. It also depends on if you are using CSG, CAG or NetScaler in the DMZ. No matter what, CSG/CAG/NS pass 443 thru to the Web Interface which is usually in the internal LAN and WI contacts the XML Broker service on your Collector or Controller (XenDesktop or XenApp) which contacts a DC/GC server for auth purposes. Citrix has docs for single and double firewall setups. I believe they also have docs for WI sitting in the DMZ but Ihave never seen anyone use it in that config. Thanks Webster -Original Message- From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 1:49 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ Correct. How does Citrix handle this? Member server in the DMZ yes? -Original Message- From: Webster [mailto:webs...@carlwebster.com] Sent: Thursday, March 14, 2013 11:43 AM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ And you make swiss cheese of your firewall. ~ 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
RE: Difference between port forwarding and DMZ
+1 -Original Message- From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Thursday, March 14, 2013 2:44 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ Put an SSL reverse proxy in the DMZ and tunnel that to the RDS Gateway -Original Message- From: David Lum [mailto:david@nwea.org] Sent: Thursday, March 14, 2013 2:37 PM To: NT System Admin Issues Subject: RE: Difference between port forwarding and DMZ 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 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
RE: Difference between port forwarding and DMZ
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 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
Re: Difference between port forwarding and DMZ
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 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
