How big of a problem is it to punch a hole in the DMZ to one web server?

We currently have our web server in a DMZ. The web server cannot see anything within the internal network, but the internal network can see the web server. How safe would it be to punch a hole in the firewall between the DMZ and the internal network to only one web server in the intranet? We are working on something that will be interfacing with several of our back-office applications (which are all on one server) and it would be so much easier to do this project if we could communicate directly with the IBM i server holding this data (via web services).

From my understanding (and I don't know brands), we have one firewall for the DMZ with a different external IP from our primary IP with another firewall. Another firewall is between the web server and the intranet.

So something like:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

Solution 1:

There's nothing wrong with creating access mechanisms for hosts in the DMZ to access hosts in the protected network when this is necessary to accomplish your intended result. It's, perhaps, not preferable to do so, but sometimes it's the only way to get the job done.

The key things to consider are:

• Limit the access to the most specific firewall rule you can. If possible, name the specific hosts involved in the rule along with the specific protocols (TCP and/or UDP ports) that will be used. Basically, open only as small a hole as you need.

• Be sure that you're logging access from the DMZ host to the host on the protected network and, if possible, analyze those logs in an automated fashion for anomalies. You want to know when something out of the ordinary happens.

• Recognize that you're exposing an internal host, even if it's in an indirect manner, to the Internet. Stay on top of patches and updates for the software you're exposing and the host's operating system software itself.

• Consider mutual authentication between the DMZ host and the internal host, if that's feasible with your application architecture. It would be nice to know that the requests coming to the internal host are actually coming from the DMZ host. Whether you can do this or not is going to be highly dependent on your application architecture. Also, bear in mind that someone who "owns" the DMZ host will be able to make requests to the internal host even if authentication is occurring (since they'll, effectively, be the DMZ host).

• If there's concern about DoS attacks consider using rate-limiting to prevent the DMZ host from exhausting the resources of the internal host.

• You may want to consider using a layer 7 "firewall" approach, where the requests from the DMZ host are passed first to a special-purpose internal host that can "sanitize" the requests, sanity-check them, and then pass them on to the "real" back-end host. Since you're talking about interfacing to your back-office applications on your IBM iSeries I'm guessing that you have limited capability for performing sanity-checks against incoming requests on the iSeries itself.

If you approach this in a methodical fashion and keep some common sense about it there's no reason you can't do what you're describing while keeping risk minimized at the same time.

Frankly, that you've got a DMZ that doesn't have unfettered access to the protected network puts you leaps and bounds beyond a lot of networks I've seen. For some people, it seems, DMZ just means "another interface on the firewall, possibly with some different RFC 1918 addresses, and basically unfettered access to the Internet and the protected network". Try and keep your DMZ as locked-down as you can while still accomplishing business goals and you'll do well.

Solution 2:

There are obviously some dangers, but you can do it. Basically you're opening a pinhole that someone could get in through, so make it tiny. Limit it to only the servers on either end, and allow only data on the chosen ports. Its not a bad idea to use port address translation to just use bizarre ports. Still, security by obscurity is no security at all. Make sure that whatever the server on the other side is has some sort of way to check that information going through that connection is truly what it appears to be... or at least have some sort of context aware firewall in place. Also, there are certain firewalls made for this sort of thing... I know microsoft ISA does this same thing for OWA and Exchange servers.