DMZ and secure?
itdaddy
Member Posts: 2,089 ■■■■□□□□□□
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?
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?
Comments
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)
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.
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!
Theres some good technet examples if I run into them I will post the links, otherwise it shouldnt be to hard to search.
Remember, a DMZ is typically the network *between* the border firewall and the internal firewall.
Internet -> Border Firewall -> DMZ Network -> Internal Firewall -> Internal Network
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.
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.
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.
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.
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.
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.
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:
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.
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!
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.
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.