DMZ vs Port Forwarding?

Hello experts,

We are preparing to install a web server (for public web pages accessible from the Internet and our Intranet) at  our organization. I am curious as to where on our network this should be placed.   At our main location we have a T1 which runs from the Telecomm router into our Firewall/VPN appliance.  This appliance does not have a DMZ port only public/private interfaces.  My initial thought was to deploy this public webserver behind our firewall and  forward port 80 from our FW to the server.  The second was to lock the server down with  concrete and place it on the outside of the FW with a public IP (I dont like this) or  finally building a Linux box with two NICS one on the public side of the network on the other in a newly created DMZ zone.  The first part of my question is which of these solutions is the best if any?  Please describe your setups...

The second part of my question is  what is the advantage of using a DMZ over a simple port forward?  If you are port forwarding to only ONE internal IP address what is the danger of the traffic traversing your internal network?  Does the concern come from the possibility of that one machine becoming comproimised and then becoming a tool for furture attacks internally?

Who is Participating?

Improve company productivity with a Business Account.Sign Up

Julian_CConnect With a Mentor Commented:
The architecture you describe with the Web server air-gapped from the rest of the network is more secure than the proxy architecture I mentioned earlier and is good as long as you don't require any (much) access to the web server from the LAN or vice versa. Of course, if all you need to do is put new content on the server then you can expose a secure FTP server on the web server that only allows connections that have come via the external IP on your LAN's FW. In this way new content comes from the LAN, out through FW1 and then back in through FW2. In larger organisations, where Web content is often dynamically generated, based on the state of various internal systems then it is simply not practical to air-gap the web server from the source systems. Even without proxies you can just sandwhich your public facing servers between 2 firewalls. If the www server is compromised then there is no access from that point through to the LAN. This architecture is often used when you have to have access to a DB from the web server. The 2nd FW only alllows data connections in that scenario (and is NOT on the LAN in that case!!)

                                            <--LAN INTERNET
          Allow 80 ->     SRV      --->XXX
                                          No inbound

Well, if I was you I'd go for the DMZ option to keep your network safe should the web server be compromised. This allows you to create a zone for all of your current and future public facing services. You have a network right behind the FW with the web server on and behind that you have another firewall for your LAN to sit behind. BUT personally, if you can go this far I'd go a stage further. I really don't like just forwarding port 80 through to the web server. It is much better to put a proxy between the FW and the web server. In this way you can use the proxy to prevent all but the desired traffic from getting to the web server as we all know that the web server is the most vulnerable point in the initial design. I've used ISA server to publish web/ftp and email servers and it works very well. For a start it only lets through traffic that arrives with the correct URL so if someone scans your IP they'll not even see a web server (depending on how you set it up). IMO application proxies offer an excellent method to remove direct access to your public services.

>Does the concern come from the possibility of that one machine becoming comproimised and then becoming a tool for furture attacks internally?
Absolutely. It does not take much effort to compromise a mis-configured web server. Once an intruder owns the server, if it is on your internal network, they own your whole network.

Best option would be a firewall with a 3rd DMZ interface. Deep packet inspection and intrusion detection capabilities of many firewalls provide a much needed extra layer of protection.

With your Linux firewall option, you might have issues with internal users trying to access the web site, but this would be a viable option if this is a stand-alone server. Your weakest link will be the low-end PC linux firewall.

Lock the server in concrete, place it on your internal LAN and forward port 80 from the firewall.

Only as a last resort, and only temporarily, would I ever put a webserver directly on the 'net without any firewall in front of it.
NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.


You already have strong networking and security concepts. It would have been a good idea to place the server on a 3rd DMZ interface for the reason you suggested but since you don't, I see no point in building up a seperate LINUX firewall because both the firewalls are doing the very same job.

billwharton is not quite correct.

The point of a third DMZ interface is that any traffic between the web server and the rest of the internal network has to go through the firewall (and be filtered).  I think the plan with the Linux firewall is another approach to achieving this same result -- if it isn't, it should be.

Port forwarding does not accomplish this.

akant74Author Commented:
Thank you all for you input thus far! I appreciate the time and effort in your responses!  

billwharton:  If I was going to deploy the linux solution the new linux firewall would sit outside of our current firewall and have one NIC with a public ip and another for a new DMZ zone.  My thinking is I have two seperate FW's but even if they did get through my linux machine to my webserver (which would be dedicated to nothing but this task (and/or a reverse proxy using SQUID?), they could then just kill my webserver and have access to nothing else.

I misunderstood you the first time akant. I completely agree with your analysis.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.