Effectively limiting outgoing firewall traffic to frequently-changing IPs

Question

PCI DSS 1.2.1 states:

Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit "deny all" or an implicit deny after allow statement

The servers in our DMZ need to make outbound calls to a number of external services (mostly through HTTPS APIs). Most of these services have their own high-availability setups with low-TTL DNS records, and are liable to add or change IP addresses at any time.

Therefore it does not seem feasible to restrict outbound traffic on our firewall based on IP address, because the rules would be constantly out of date and an admin nightmare.

I've seen that some firewalls support FQDN-based rules, which sounds like it could solve the problem, but unfortunately neither our ISP nor others I've looked at (Rackspace, AWS, etc.) support FQDN-based firewall rules. We'd prefer not to have to move hosting providers.

Another solution is to set up a completely separate external hosting environment (complete with it's own redundancy and authentication) that is simply used to proxy all non-credit-card outgoing traffic. Then we'd only have to allow the IP of our proxy. This feels like overkill, and I struggle to believe it's the best solution.

Surely we cannot be the only PCI compliant company that has to deal with such dynamic outbound traffic rules? How are other companies solving this problem?

Answer 1

Sounds like a right pain. The problem with "FQDN" addressing is that a DNS lookup is required, and relying on timeouts can result in a delay in the firewall reacting. I'd suggest looking at this another way.

Can this be handled with a VPN? Is there a certain block of address space that you can expect to own for your servers?

You can explicitly allow a connection to a port on any host and still be in the spec (e.g., *:80). You could also make use of SSL for authenticating your connections (though that will be rough if they're not persistent).

Answer 2

Is it possible to get around such a scenario by restricting the IP addresses to a "range", normally a subnet block (as the external company had a contiguous block and so even though there was a low TTL, the rules would still be ok)? Do you external service providers either have a contiguous block or a known range of IP addresses? In my experience, most do.

From my understanding of the PCI requirements (disc: I'm a little rusty, it's been a while), the afore-mentioned solution would be sufficient because the destination is restricted and your rulebase will still have an explicit deny.

Another potential solution is to have a proxy server, either internally on the LAN or in a quasi-DMZ zone that the DMZ server can talk to the external services through. Policy can be really locked down on the proxy server such that external access from the DMZ server can be restricted to site, protocol, time etc. The proxy server is designed to deal with FQDNs (whereas the firewall typically isn't and can suffer considerabe performance degradation as outlined by @JeffFerland) so you could have a tighter policy as it'd be based on the FQDNs as destinations, not IP ranges.

I guess a lot depends on the QSA who turns up on the day :)

Additionally, I'm sure you know this but all "security best practices" (afaik) strongly insist on preventing outbound calls from the DMZ (period) so that if the box on the DMZ gets popped, the attacker cannot easily load further goodies onto the server or a piece of malware can much more easily call home.

Answer 3

Reading through your post, I was coming round to the idea of using your proxy before I got that far:

Another solution is to set up a completely separate external hosting environment (complete with it's own redundancy and authentication) that is simply used to proxy all non-credit-card outgoing traffic

Really I do't see that this is so onerous: You should be able to proxy the encrypted traffic (thus preventing data leakage from your processing servers, without issues of confidentiality/integrity on the proxy). The only problem then becomes third party traffic being routed through your proxy and being accepted as if it had come from your servers - I'd like to think that your upstream providers use more than just an IP address to identify your legitimate trasactions - but you could pin down the access further by only allowing incoming TCP connections on the proxy via ipsec / vpn.

So a proxy device, with a smple firewall, outgoing DNS requests, outgoing HTTPS requests, incoming HTTPS requests (over restricted channel) and ssh for remote access - that doesn't sound too complex to me.