Security – Best practices for LDAP and DMZ

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.

First, DON'T capitulate. He is not only an idiot but DANGEROUSLY wrong. In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. It would also expose your company to all sorts of liabilities.

The next thing I would do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action.

This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.