Firewall egress filtering by domain

Question

In our production environment, we are connecting to a few core external service providers though their APIs, and are required to have all other services blocked (PCI DSS).

We currently have a firewall which supports egress filtering by ip address so all non-essential addresses are blocked based on statically-created firewall rules (deny all, allow 1.2.3.4:443 etc)

So far all is good, now here is the problem, one of our service providers (a big bank) is moving to an edge/cdn hosted API for one of it's services and the ip of the services IS going to change several times per day.

I have read other articles about egress filtering: Firewall egress filtering / quick whitelisting

...as well as possibly using scripts to modify an iptables based firewall based on a DNS query. https://stackoverflow.com/questions/14096966/can-iptables-allow-dns-queries-only-for-a-certain-domain-name

...but these solutions seem hacky

Are there firewalls we can use that have domain based rules, instead of IP based so our API requests continue to arrive un-interrupted yet we continue to block all other outbound connections?

Answer 1

Are there firewalls we can use that have domain based rules, instead of IP based so our API requests continue to arrive un-interrupted yet we continue to block all other outbound connections?

Yes, although usually through a proxy functionality rather than a traditional firewall rule sense.

For example, the Check Point URL Filtering Software Blade allows you to restrict outgoing HTTP and HTTPS connections based on the DNS name they request access to - e.g., either a GET http://example.com/ HTTP/1.0 or a CONNECT example.com HTTP/1.1 would only succeed if a rule exists permitting access to example.com.

The proxy aspect is a result of the problem space. Reverse DNS cannot be trusted in any way, shape, or form, so the firewall can't just reverse the IP the client wants to connect to and decide based on that. It has to be handed a name by the client, and to make its decision based on that. HTTP-style proxies work fine for this because, even when it's for an encrypted connection, the client hands the name over to the proxy before the connection can be made.

The problem with this approach is that it effectively bases security upon the result of DNS queries against remote domains. Reverse DNS can never be trusted because anyone can put any name in for an IP they own. But even forward DNS lacks the security required - you can safely assume that a moderately motivated attacker can manage to spoof or poison DNS if it allows them to exfiltrate PCI data from your datacenter.

(That does not mean you couldn't get this blessed by a QSA - it's a reasonable compensating control. I just don't want you to think it's fully secure!)

I approached the same problem - for the same reasons as you - over a year ago, and concluded that the "secure" method would require that something more than DNS to vouch for remote sites, and that the SSL certificate was a reasonable thing to pin the security upon. I ended up implementing such a proxy and using it for my purposes; the answer mr.spuratic provided promises to do the same thing (the only reason I haven't accepted it yet is because I feel the need to test it first).

Answer 2

The proxy-whitelisting-by-certificate idea is a really interesting/neat one that I'd personally never thought of before for this scenario; I'd definitely take a glance at that & see if it would be workable for your situation.

However, let me say a bit about the older, somewhat simpler solution that you mentioned yourself: setting up a script to do a DNS check periodically to see what IP address will currently work. Specifically: when a related question asked over at the Unix & Linux SE a few years ago yielded a couple of sample scripts for iptables that will work with a crontab rule to check the IP for a given domain every five minutes (from DynamicDNS, in that particular case) and then create a rule allowing inbound traffic from that IP through. I see no reason why you couldn't take such a pre-existing script, set the rule-type to outbound, make whatever other useful additions or subtractions to it you like, and off you go. Not ideally elegant, sure, but I wouldn't call this approach hacky or gimmicky either.

Not sure whether or not it would be proper to copy & paste sample code directly from that Linux SE question I referred to, so I won't. However, there are only two answers, with one script sample each, on the question page. Not difficult to read & sort through at all.

Finally, we should indeed address what you can do to better secure your DNS lookups themselves. Theoretically, if your payment software is communicating to financial institutions solely over https, with the receiving server authenticated to the client as legitimate by having a valid certificate. In that case, even maliciously altered DNS results (whether by local MitM DNS spoofing, DNS cache poisoning done to the resolving server you're connecting to, etc.) that wouldn't be enough to possibly let an attacker intrude on the secure connection/s that you're sending the financial info over. (Because the certificate for a phony server set-up by an attacker wouldn't match the domain name.) But since we're supposed to be thinking about defense-in-depth and presuming that something could go wrong with any one layer of security (like maybe a Certificate Authority's private signing key being compromised, so an attacker could sign any server they wanted with any domain name), let's assume we want some sort of robust protection for DNS queries. Unfortunately, that means either (a) actually running a DNS server--with DNSSec enabled and properly configured to prevent poisoning attacks-- directly on the local machine that going to be doing the connecting or (b) using DNSCrypt to make an encrypted connection to OpenDNS or a trusted DNS server (with DNSSec on) that you've set up inside your local network.

So you have one or two options, at least.