DMZ and secure?

hey DMZ gurus..

why would you put a machine on a DMZ??? what about firewall security.
why would you put and exchange server or web server in a DMZ
what about portforwarding??? I am confused as to why you would do this
at home my exhange server and webserver are behind my fwl and portforwarded
so what the DMZ is for???

thanks

what would you put on dmz Like VPN routers that are config as vpn p2p?

Find more posts tagged with

Comments

Thiassi

Quite simply: it's much more secure to use a DMZ for some services.

Exchange 2003 front end servers, for example, would be placed in the DMZ and you could then encrypt communication between it and the internal mailbox server for additional security.

Exchange 2007 uses an Edge Server (please correct me if I'm wrong) in a similar role but is required NOT to be domain'd making it that more secure.

External DNs would be another example. You wouldn't want to have internet DNS requests passing through to the internal network and potentially exposing your internal network unnecessarily so it's best put on the DMZ.

It's all about the security dude.

(please someone correct me if I'm wrong on any points)

HeroPsycho

First off, Edge Transport servers aren't front end servers. They're SMTP smart hosts, effectively.

You put things in the DMZ that typically receive direct traffic from the internet. Then grant them only the specific access they need to internal resources, that typically house valuable data.

Taking Exchange 2007 ET servers as an example, you would allow SMTP from the internet only to the ET, then open port 25 between just the ET in the DMZ and your Hub Transport servers (along with other ports for EdgeSync, but we won't go there) on the internal firewall. The reason this is more secure is for one no internal server is exposed directly to internet traffic, so attackers on the internet can't take an internal server down from a DoS attack from an internet host. Also, if the DMZ homed server gets breached, the only way they can be used to attack the internal network is through only the traffic you explicitly allowed through the internal firewall. Without that firewall there, that breached server would effectively have unfettered access to the attack surfaces of your internal servers, such as SMB, RPC, etc. Instead, they would have to attack somehow with SMTP in this scenario, which is much harder.

Thiassi

HeroPsycho wrote:

First off, Edge Transport servers aren't front end servers. They're SMTP smart hosts, effectively.

You put things in the DMZ that typically receive direct traffic from the internet. Then grant them only the specific access they need to internal resources, that typically house valuable data.

Taking Exchange 2007 ET servers as an example, you would allow SMTP from the internet only to the ET, then open port 25 between just the ET in the DMZ and your Hub Transport servers (along with other ports for EdgeSync, but we won't go there) on the internal firewall. The reason this is more secure is for one no internal server is exposed directly to internet traffic, so attackers on the internet can't take an internal server down from a DoS attack from an internet host. Also, if the DMZ homed server gets breached, the only way they can be used to attack the internal network is through only the traffic you explicitly allowed through the internal firewall. Without that firewall there, that breached server would effectively have unfettered access to the attack surfaces of your internal servers, such as SMB, RPC, etc. Instead, they would have to attack somehow with SMTP in this scenario, which is much harder.

Had a strong suspicion I was incorrect about the Edge Server role (only just started looking at the 236 book last night) but my underlying point of a DMZ was correct.

itdaddy

Does NAT still take place? I think it does...but so no firewall protection it seems
when they are on the DMZ hence the word DMZ no protection.. but there is protection
as far as DNS servers. I have seen portforward work (53..) and work fine if done right.

i guess it blows my mind of now fwl out there on the DMZ to get shot at?

any good books on DMZ security or shoudl I do an Amazon query??
thans dudes!

CoryS

In a two firewall internal/external(dmz)/internet setup you will still have NAT happening, you will probably have it vlan'd or subnetted differently and then setup route statements if necessary but the main thing here is isolating the traffic that will be reaching your internal servers to very specific things. Another thing to remember, even though its called the DMZ its still going to have strict firewall rules applied against it, so its not like it will have one of your public IPs and two interfaces and sit directly in front of your PIX or whatnot.

Theres some good technet examples if I run into them I will post the links, otherwise it shouldnt be to hard to search.

HeroPsycho

Typically speaking, NAT is deployed on the edge firewall, but not the internal firewall, as this would result in a double NAT environment, which often causes problems.

Remember, a DMZ is typically the network *between* the border firewall and the internal firewall.

Internet -> Border Firewall -> DMZ Network -> Internal Firewall -> Internal Network

NetAdmin2436

Sorry, but I still don't buy it.

I have often wondered why my college text books and even some exams questions point to putting exchange servers in DMZ and calling them 'Secure'. I have read plenty of stuff on the internet and still don't understand why. This seems to be a debated practice.

The following comes from Simon Butler, a Microsoft Exchange MVP. Personally, his argument seems the most logical I have read.

"A good firewall administrator wants the least number of ports open to the production network.
Having worked with financial institutions, showing them the list of ports that need to be open between an Exchange server on production and one in the DMZ usually means they give up on the idea.
This is the list of ports that need to be open between the frontend server and the production domain to allow all features of Exchange to work. The actual list required can vary from site to site, depending on the features deployed.

* SMTP: 25
* LDAP (DC lookup): 389
* LDAP (GC lookup): 3268
* NetBIOS (ports): 135, 139, 1024+ (default config is usually 6000 something).
* DNS: 53
* RPC: 111, 135, 1024+
* Netlogon: 445
* Kerberos: 88
* OWA: 80 (HTTP), 443 (HTTPS)
* IMAP4: 143, 993 (with SSL) SSL
* POP3:110 995 (with SSL)

The NETBIOS ports (125, 139 etc and 445) are the ones that usually scare the firewall administrators the most as those are frequent targets and the NETBIOS traffic shouldn't be passing over a firewall.
Put all domain members inside the production network and open only the ports that you need to. In many cases this can be two - 25 (SMTP) and 443 (HTTPS). "

Who would open all that up? Not me.

http://www.sembee.co.uk/archive/2006/02/23/7.aspx

With all that said, I understand heroPsycho's last comment and having 2 firewalls. Fine, if you work for a large company. But how many companies actually can afford or implement 2 firewalls? Most companies only have 1 firewall....because that's all they really need.

Turgon

Years back we had a Solaris box working as an Exim mailer in the DMZ forwarding mail traffic to the Exchange Server on the LAN. That worked pretty well for mail filtering and security. No OWA though.

HeroPsycho

NetAdmin2436 wrote:

Sorry, but I still don't buy it.

I have often wondered why my college text books and even some exams questions point to putting exchange servers in DMZ and calling them 'Secure'. I have read plenty of stuff on the internet and still don't understand why. This seems to be a debated practice.

First off, I must say again that Edge Transport is NOT OWA! I'm not referring to OWA at all in the above posts.

Going forward in fact, in Exchange 2007 your OWA servers, called "Client Access Servers", are actually unsupported in a DMZ. The preferred secure OWA solution is to use ISA to securely publish the server.

Going back to Exchange 2003, is it more secure for them to be in your DMZ? Yes. The reality is you can still lock down to allow those protocols to only the servers the front end needs to be connecting to and no more. However, the increased security is marginal. The better solution would be to use ISA as a reverse proxy either as a proxy server within the DMZ, or have ISA be one of your cascading firewalls, preferably your Internal firewall. Firewalls such as ISA that can do true application layer filters are far more effective than simple packet filters in blocking attacks, but they don't process traffic as efficiently as more simple packet filters like PIX's, etc. So, have a PIX or whatever ASIC proc based firewall on the edge, and something like ISA as the second firewall.

NetAdmin2436 wrote:

With all that said, I understand heroPsycho's last comment and having 2 firewalls. Fine, if you work for a large company. But how many companies actually can afford or implement 2 firewalls? Most companies only have 1 firewall....because that's all they really need.

You don't have to have two firewalls to do this. You can have a multihomed single firewall. Taking ISA as an example, you could have three NIC's within it, one called External hooked to the internet, one called DMZ hooked to an isolated switch, and one called Internal hooked into the Internal network. Grant only the access DMZ hosts need to the Internal network within the ISA ruleset.

As for the comment that most companies only have 1 firewall, that doesn't mean they necessarily only need one firewall. They compromised security for cost savings, and are willing to live with the risks associated with it. If their needs are high availability, or they have sensitive private data, and there are opened ports into servers directly, I don't care who they are, they should have a DMZ. If a design for a network topology that included a DMZ were free, they'd be foolish not to have it. But again, it's all about cost to them. They only truly don't need a DMZ if they're perfectly willing to accept the risks of not having it in exchange for the money they save. In my experience, most businesses have no clue if they truly need it or not, because they scream their heads off when the potential risk becomes reality.

royal

Speaking of which. Every Exchange 2007 server is not supported if there is ANY firewall device in the middle. This includes Exchange Servers talking to each other between sites. The only server role supported with a firewall in between, is.... you guessed it... the Edge Transport Server.

Front End in the DMZ? IPSEC it and all those ports are encapsulated inside IPSEC protocols and sent to the back-end. NEVER EVER EVER put the FE in the DMZ and open up all those ports. At the very least, IPSEC it. I'd still put the FE in the internal network and just use ISA for Client Access and a dedicated smart hosted device like a Barracuda in the DMZ for Anti-Spam/Anti-Virus.

HeroPsycho wrote:

In my experience, most businesses have no clue if they truly need it or not, because they scream their heads off when the potential risk becomes reality.

Isn't that the case with most things? The majority of people are after the fact. They need a disastrous act to make them do something. It's really unfortunate most people are reactive rather than proactive.

NetAdmin2436

Ok, Sorry for the confusion. hero, I re-read your initial comments again. I'll admit I have to study up on the edge transport server (among many other things

).

So, basically though....if you just have 1 plain exchange 2003 or later server never EVER put that in a DMZ alone. That was my point.

HeroPsycho

royal wrote:

Front End in the DMZ? IPSEC it and all those ports are encapsulated inside IPSEC protocols and sent to the back-end. NEVER EVER EVER put the FE in the DMZ and open up all those ports. At the very least, IPSEC it.

While I agree with this as well, if you think about it, it's still a problem. The FE, which is exposed directly to internet traffic, is still able to hit internal resources through SMB, RPC, etc. Encapsulating hacker packets in IPSec doesn't make them safe.

Bottom line - if you really want security, use a reverse proxy like ISA. It's more resistant to attacks than an FE, and it actually scrubs the traffic through the secure publishing rule, which is again something an FE doesn't do.

royal

HeroPsycho wrote:

royal wrote:

Front End in the DMZ? IPSEC it and all those ports are encapsulated inside IPSEC protocols and sent to the back-end. NEVER EVER EVER put the FE in the DMZ and open up all those ports. At the very least, IPSEC it.

While I agree with this as well, if you think about it, it's still a problem. The FE, which is exposed directly to internet traffic, is still able to hit internal resources through SMB, RPC, etc. Encapsulating hacker packets in IPSec doesn't make them safe.

Bottom line - if you really want security, use a reverse proxy like ISA. It's more resistant to attacks than an FE, and it actually scrubs the traffic through the secure publishing rule, which is again something an FE doesn't do.

Agreed. That goes back to my saying:

royal wrote:

NEVER EVER EVER put the FE in the DMZ and open up all those ports. At the very least, IPSEC it. I'd still put the FE in the internal network and just use ISA for Client Access and a dedicated smart hosted device like a Barracuda in the DMZ for Anti-Spam/Anti-Virus.

HeroPsycho

NetAdmin2436 wrote:

So, basically though....if you just have 1 plain exchange 2003 or later server never EVER put that in a DMZ alone. That was my point.

I wouldn't see the point. If you have just one Exchange 2003 server, it's already storing the critical data - mailboxes. The point of DMZ usually is to separate the server that receives traffic directly from the internet from the server that stores the data with a firewall. With one server, you can't do that.

In fact, instead of a front end if you're thinking security, deploy an ISA server instead.

royal

The only time I'd ever really use a FE is if I had multiple back ends. You need a FE for the routing logic to proxy users to the back-end which ISA can't do. Other than that, I'd always just leave the bridgehead on the BE and just have it smart host to an antispam/antivirus appliance and then configure ISA for client access reverse proxying.

HeroPsycho

royal wrote:

The only time I'd ever really use a FE is if I had multiple back ends. You need a FE for the routing logic to proxy users to the back-end which ISA can't do.

Oh but it can!

http://www.msexchange.org/tutorials/Configuring-ISA-Server-2004-Exchange-Frontend-Server-DMZ-Part1.html

Did I just blow your mind, because THAT JUST HAPPENED!

royal

Like I said, you still need a FE if you have multiple BEs. In that diagram, he still has an Exchange 2003 FE server in the internal network. And the doc says, "But what is the reason for using ISA Server 2004 instead of Exchange Server 2003 in the DMZ? " The article is more for, "Use ISA instead of a 2003 FE, but for the DMZ and then putting your FE in the internal network."

Let me rephrase what I was saying. ISA can replace a FE for the DMZ and is recommended. ISA cannot completely (I never mentioned DMZ) replace a FE for your entire topology if you have more than 1 back end. So, there are 2 options. IF you have 1 BE, don't use a FE and just use ISA in the DMZ. If you have multiple back ends, use ISA in the DMZ, but you will still need a FE on the internal network for the routing functionality to multiple back end.

HeroPsycho

"But why should we still use a front end server in the LAN segment? The reason is quite simple, it is just because you are able to publish one single URL to all your employees even if you still have more than one back end server available."

They're referring to internal OWA users. Since ISA wouldn't be involved in that situation, you can't use it to proxy the connection to the appropriate backend.

Don't get me wrong, I'd still setup a front end, but I just wanted to illustrate that it is possible to use ISA to proxy to multiple backends.