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: OT: Happy PI Day!
I'm waiting for Tau day: http://tauday.com/tau-manifesto Pi are squared? No, cornbread are square, pie are round... Kurt On Thu, Mar 14, 2013 at 10:03 AM, Heaton, Joseph@Wildlife joseph.hea...@wildlife.ca.gov wrote: In case someone out there didn’t know… Joe Heaton Enterprise Server Support CA Department of Fish and Wildlife 1807 13th Street, Suite 201 Sacramento, CA 95811 Desk: (916) 557-3422 ~ 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
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: OT: Happy PI Day!
Remember celebrate Pi Day by being irrational. Jim On 3/14/13 10:54 AM, Kurt Buff wrote: I'm waiting for Tau day: http://tauday.com/tau-manifesto Pi are squared? No, cornbread are square, pie are round... 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
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: Keeping 550+ systems maintained
Excellent questions Ken, thanks. Up to date at this point means 1. Current (within 1 day) of anti-virus signatures 2. Have the latest Acrobat/Java/Firefox/Chrome updates within two weeks 3. Successful backups (we use Tivoli to back up endpoints) 4. Weekly report to confirm the above Dave From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Wednesday, March 13, 2013 8:01 PM To: NT System Admin Issues Subject: RE: Keeping 550+ systems maintained I think you need to know what your requirements are. How do you define up to date? e.g. - How quickly do you need to deploy something (or even have a range of critical/medium/low priority updates)? - And how do you need to report compliance (on demand? At pre-set intervals?) - And how do you measure your SLA? E.g. what is an acceptable level of 'unknown' state devices? And how long can they remain as 'unknown' Once you have an idea of what you need to meet, then you can start to work out what combination of technologies and people you need to meet it. Cheers Ken From: David Lum [mailto:david@nwea.org] Sent: Wednesday, 13 March 2013 1:40 AM To: NT System Admin Issues Subject: Keeping 550+ systems maintained Scenario: * 550 Windows workstations, with 100+ of them remote. * Active Directory (W2K8R2 and W2K3 DCs). * Windows 7 and Windows XP. * Users are local admins. * Some remote users VPN in daily, others only VPN in once/month, a few others almost never * 30+ onsite users frequently jump between wired and wireless (in my experience this occasionally trips up DNS and thus management agents for a bit) * Systems are cycled out at the rate of about 30 machines every quarter (relevant because finding a noncompliant machine often means knows if a system has been decommissioned or not). Systems are not always immediately removed from AD for various reasons. Task: Keep them up to date on anti-virus and patches, incl. 3rd party (Java/Adobe/Chrome/etc.). This includes coordinating (with select users) installing/testing the patches on their systems before full rollout to the rest of the org. Is this enough info to give a SWAG for how many hours/week you would you tell management this would take? A rough number works. 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 ntsysadmin
Re: Keeping 550+ systems maintained
Have you considered packaging those Firefox/Adobe etc apps up with App-V or something? It certainly mitigates some of the risk given that the packaged app can't interact heavily with the underlying OS due to the SystemGuard feature. When a client system checks in, it could then pick up the updated app. You'd have to pre-cache the apps for offline use, but it would certainly mitigate against a large part of the risk factor. Cheers, JR Sent from my Blackberry, which may be an antique but delivers email RELIABLY -Original Message- From: David Lum david@nwea.org Date: Thu, 14 Mar 2013 20:23:57 To: NT System Admin Issuesntsysadmin@lyris.sunbelt-software.com Reply-To: NT System Admin Issues ntsysadmin@lyris.sunbelt-software.comSubject: RE: Keeping 550+ systems maintained Excellent questions Ken, thanks. Up to date at this point means 1. Current (within 1 day) of anti-virus signatures 2. Have the latest Acrobat/Java/Firefox/Chrome updates within two weeks 3. Successful backups (we use Tivoli to back up endpoints) 4. Weekly report to confirm the above Dave From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Wednesday, March 13, 2013 8:01 PM To: NT System Admin Issues Subject: RE: Keeping 550+ systems maintained I think you need to know what your requirements are. How do you define up to date? e.g. - How quickly do you need to deploy something (or even have a range of critical/medium/low priority updates)? - And how do you need to report compliance (on demand? At pre-set intervals?) - And how do you measure your SLA? E.g. what is an acceptable level of 'unknown' state devices? And how long can they remain as 'unknown' Once you have an idea of what you need to meet, then you can start to work out what combination of technologies and people you need to meet it. Cheers Ken From: David Lum [mailto:david@nwea.org] Sent: Wednesday, 13 March 2013 1:40 AM To: NT System Admin Issues Subject: Keeping 550+ systems maintained Scenario: * 550 Windows workstations, with 100+ of them remote. * Active Directory (W2K8R2 and W2K3 DCs). * Windows 7 and Windows XP. * Users are local admins. * Some remote users VPN in daily, others only VPN in once/month, a few others almost never * 30+ onsite users frequently jump between wired and wireless (in my experience this occasionally trips up DNS and thus management agents for a bit) * Systems are cycled out at the rate of about 30 machines every quarter (relevant because finding a noncompliant machine often means knows if a system has been decommissioned or not). Systems are not always immediately removed from AD for various reasons. Task: Keep them up to date on anti-virus and patches, incl. 3rd party (Java/Adobe/Chrome/etc.). This includes coordinating (with select users) installing/testing the patches on their systems before full rollout to the rest of the org. Is this enough info to give a SWAG for how many hours/week you would you tell management this would take? A rough number works. 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 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: OT: Happy PI Day!
I'd rather be transcendental... Kurt On Thu, Mar 14, 2013 at 12:05 PM, James Edwards jedwa...@mail.sdsu.edu wrote: Remember celebrate Pi Day by being irrational. Jim On 3/14/13 10:54 AM, Kurt Buff wrote: I'm waiting for Tau day: http://tauday.com/tau-manifesto Pi are squared? No, cornbread are square, pie are round... 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
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! ~ ~
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 it.
RE: Keeping 550+ systems maintained
So, if I could summarise your requirements, and current state: Machines: In Office Remote: once-per-day connectivity Remote: once-per-month connectivity Remote: no connectivity 450 ~30 ~30 ~30 Requirement Metric Compliance Update AV Within 24 hours of release 100% of machines. Weekly report Update Acrobat/Java/Firefox/Chrome Within 14 days of release 100% of machines Weekly report Successful Backup (unsure what the scope is here) Unsure what the metric is here (Daily? Weekly? Monthly?) Weekly report Compliance Report Weekly 100% coverage If you need to meet 100% compliance (you don't mention meeting, say, 90% compliance within 1 day, 100% within a week, or dividing machines into in-office vs. remote) then I think your problem is the infrequently connected machines (~10% of the fleet), as they don't connect frequently enough for central enforcement and meeting your turn-around-times. So you might look at: a) A configuration management system that's able to communicate over the internet. Could be as simple as a script that runs as a scheduled task and posts the data back to a web server that you have centrally b) Some way of making remote configuration changes (Go-To-Meeting or something) to enforce updates (if/when required) You could look at using RDS or similar to publish the apps you need to update within 14 days (except the ones listed all have their own updating mechanisms). If that's not working well, then Citrix/RDS might be an option, as at least you can enforce the updating centrally Backup - I'm going to assume that TSM is not going to work for the machines that do not VPN in, so you need something separate for them. I'd also look at your configuration management procedures, and tighten up the link between asset lifecycle management - configuration management - AD configuration, to reduce the time being spent on machines that haven't been removed from AD. You might want to read the ITIL docs to see all the process areas you should have (not saying you should implement ITIL, but it'll help with proactive/consistent management of the environment. If you really need to hit the metrics you have above (including proving compliance), you could be devoting almost an entire FTE to the above. Cheers Ken From: David Lum [mailto:david@nwea.org] Sent: Friday, 15 March 2013 7:24 AM To: NT System Admin Issues Subject: RE: Keeping 550+ systems maintained Excellent questions Ken, thanks. Up to date at this point means 1. Current (within 1 day) of anti-virus signatures 2. Have the latest Acrobat/Java/Firefox/Chrome updates within two weeks 3. Successful backups (we use Tivoli to back up endpoints) 4. Weekly report to confirm the above Dave From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Wednesday, March 13, 2013 8:01 PM To: NT System Admin Issues Subject: RE: Keeping 550+ systems maintained I think you need to know what your requirements are. How do you define up to date? e.g. - How quickly do you need to deploy something (or even have a range of critical/medium/low priority updates)? - And how do you need to report compliance (on demand? At pre-set intervals?) - And how do you measure your SLA? E.g. what is an acceptable level of 'unknown' state devices? And how long can they remain as 'unknown' Once you have an idea of what you need to meet, then you can start to work out what combination of technologies and people you need to meet it. Cheers Ken From: David Lum [mailto:david@nwea.org] Sent: Wednesday, 13 March 2013 1:40 AM To: NT System Admin Issues Subject: Keeping 550+ systems maintained Scenario: * 550 Windows workstations, with 100+ of them remote. * Active Directory (W2K8R2 and W2K3 DCs). * Windows 7 and Windows XP. * Users are local admins. * Some remote users VPN in daily, others only VPN in once/month, a few others almost never * 30+ onsite users frequently jump between wired and wireless (in my experience this occasionally trips up DNS and thus management agents for a bit) * Systems are cycled out at the rate of about 30 machines every quarter (relevant because finding a noncompliant machine often means knows if a system has been decommissioned or not). Systems are not always immediately removed from AD for various reasons. Task: Keep them up to date on anti-virus and patches, incl. 3rd party (Java/Adobe/Chrome/etc.). This includes coordinating (with select users) installing/testing the patches on their systems before full rollout to the rest of the org. Is this enough info to give a SWAG for how many hours/week you would you tell management this would take? A rough number works. 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! ~ ~
RE: Meraki
After a little talking to a sales drone (quite nice they let me initiate the conversation) I found out that if the Cloud Management License lapses by 90+ days then the AP will stop passing traffic. I don't know yet if that would be good thing or bad. I guess I will have to actually do some testing of the device they are shipping me to see if it is worth the MSRP of $150/AP/year. I can't see this for homeowners or even a lot of mom pop SMBs. I don't think they will be willing to fork over the year fee. Jon From: gswe...@acts360.com To: ntsysadmin@lyris.sunbelt-software.com Subject: RE: Meraki Date: Mon, 11 Mar 2013 21:23:41 + I love the Meraki AP’s. We have 40+ over multiple clients. Easy management, great performance. We had have replaced clients that were having horrible issues with Rukus, Firetide, Cisco, etc.. Not because the equipment was bad, but because the reseller sold it without the proper controllers, or told them they could manage multiple sites from a web page, when in fact they had to connect to the controller locally at each site to manage…. Fortunately almost all of them were able to return their products to reseller or direct. Setup the info on the dashboard. SSID, policies, etc.. Connect your laptop to the Meraki, set the IP/connection info, plug in to POE or injector and 2 mins later you are on and connected. Seamless roaming across a 12000 sqft facility with multiple walls, offices, floors. We have had what we think was just a bad manufacturing batch because about 4 in a one month period arrived, plugged in and promptly (3 -4 mins) fried. Different locations… But since then no issues. Prompt RMA service also.. Now the Firewalls…Same interface, excellent performance. Seriously lacking on features and granular controls. Sonicwall, Watchguard have them beat hands down. Needs polishing on the usability of the interface as well. We are actively involved with their development team as we have some of their higher end stuff in our datacenter and I am unable to meet some client application needs, but I am hopeful for some resolutions. In the meantime I had to install my old Sonicwall 2040 to get around it. If you are just looking for basic firewall and don’t need a lot of higher end firewall features the single management interface for everything is really nice. Automatic Site to Site with WAN Acceleration, Failover, etc are all included. The switches have some huge promise too. We only have one at a client due to price.. Definitely not the cheapest when you can get a 24 port HP 1910 for 400 bucks vs 1100+… Greg Sweers CEO ACTS360.com P.O. Box 1193 Brandon, FL 33509 813-657-0849 Office 813-644-3479 Cell 813-644-3476 Fax From: Tom Miller [mailto:tmil...@sfgtrust.com] Sent: Monday, March 11, 2013 8:56 AM To: NT System Admin Issues Subject: RE: Meraki We're looking at Meraki for our two manufacturing facilities.Here at HQ we installed Cisco wireless last year. I've been trying to get Cisco to buy back the equipment so it would be Meraki everywhere. So far no luck - seems like they are pretty much separate companies. I'm still hopeful since I like the meraki management. From: Patrick Salmon [mailto:psal...@gmail.com] Sent: Friday, March 08, 2013 4:38 PM To: NT System Admin Issues Subject: OT: Meraki Since it came up the other week (and with full disclosure: I am a Cisco employee and Meraki is now a part of Cisco), anybody want a free AP? Yeah. Free. Follow link. sign up. Participate in webinar. Validate shipping details. Done. Before I get spanked, it is limited to NA and EU so apologies to anyone outside those geos. 802.11n, fully cloud-managed with a 3-yr subscription. Setup is a breeze. I did this a couple of months ago and was very happy with the MR16 they sent (I'm pretty certain that's the $699 one referenced in the link) and when I certified (SE's and Cisco partners only) they replaced it with the MR24 (more radios) added the NGFW and POE Switch. My home network is now entirely Meraki and while I have incentive to be somewhat biased have found it to be uber cool in its own right. Kinda harks back to the good old days when you could get Cisco t-shirts and books just by finding the right link; this is one such link, and you're welcome ;-) Link here: http://www.meraki.com/freeap Pat. ~ 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
