4

From a design perspective, is it a good idea to put servers that need to perform outbound connections to internet in a separate DMZ?

These servers would be servers like web filters, WSUS servers, etc.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Othman
  • 587
  • 5
  • 16

2 Answers2

2

It isn't unheard of. I have setup many that way. It depends on how sensitive your systems are.

I like that you said "from a design perspective". Part of security is good design, whether something "theoretically shouldn't happen" doesn't make it impossible. Hacking happens. Layering and segregation is one way to introduce choke points, as well as make firewalls easier to audit, and finally, to protect against human error and misconfiguration.

DMZ is not only for inbound services. Extremely sensitive systems also restrict outbound Internet access, so if you have a separate group of servers that need outbound access, you d want to put them on a separate DMZ to segregate them rather than mixing ACLs and potentially exposing your private network. At minimum, consider separate VLANs.

Many sensitive financial, medical, telecom and government systems are on private networks that are not NATed or routable to the outside whatsoever. Some have front-end application servers on a DMZ that have firewall rules that allow punching through from the DMZ -> Private, but some don't even have that much.

codenheim
  • 174
  • 4
  • These are all good points that I hadn't thought of in my answer. – Nic Barker Aug 28 '15 at 06:25
  • Thank you for your answer. Client side attacks are less common but if they occur, it would be nice to have your servers in an isolated network – Othman Aug 28 '15 at 12:35
1

For those who aren't aware, a DMZ - demilitarized zone in computing is perimeter network between the local LAN and the internet, used to house equipment or software that can handle inbound external traffic. As a result, it only applies if you potentially have public facing services (i.e an email or web server) hosted in the same network as things you don't want to be publicly accessible (i.e your local computer or office intranet)

In your case, you're referring to services that only make outbound or symmetric calls to the open internet (i.e only make outbound calls and usually expect a response from a specific remote server). In this situation, of course there is a risk of some kind of exploit occuring (i.e in the case of WSUS the connection to the windows update server gets hijacked, DNS gets spoofed etc.) but it's a similar risk to any of your machines inside the network.

As a result, I would say that there isn't really much point putting these servers in a DMZ.

EDIT: Depends on just how sensitive the data you're dealing with is. See mrjoltcola's answer for more in depth thoughts.

Community
  • 1
Nic Barker
  • 1,170
  • 7
  • 11
  • DMZ aren't limited to public facing services. It is common to use a DMZ for app servers, and hide DB servers behind an additional layer, but the direction of the communication isn't really as important as the segregation and the layering. I say that because the OP said "from a design perspective" and we can limit risk by design. – codenheim Aug 28 '15 at 05:59
  • That's definitely a good point. I took the use of the word DMZ to be a single zone isolating an internal network from the outside, but I hadn't thought about multiple layers of segregation. – Nic Barker Aug 28 '15 at 06:27
  • The downside is automatic updates can be a pain, but there are solutions to that. :) – codenheim Aug 28 '15 at 06:28