My friend Matthias Luft sent me an interesting tweet a while ago:

@ioshints What’s your take on firewall rule sets & IP addresses vs. hostnames?

— Matthias Luft (@uchi_mata) August 16, 2016

All I could say in 160 characters was “it depends”. Here’s a longer answer.

Read this first

I’m looking at this challenge from the data center perspective: how do you build firewall rules that protect hosts within your data center (for north-south or east-west traffic)?

There’s another more interesting (= harder) challenge: how do you allow your clients controlled access to external services. I would not use DNS in that scenario as I don’t trust third-party DNS servers enough to use their data in my security rules. For more details, see the comments.

The Problem

Application developers and architects don’t think in IP addresses and port numbers (one would hope), they want to express their needs in terms of “these hosts have to talk to those other hosts using this software package/library”.

On the other hand, all firewall products have packet filters working on IP addresses and TCP/UDP ports hidden deep down within their bowels.

Some firewalls go way beyond that and inspect session content as well, but in the end, if you dig deep enough you’ll always find a packet filter and/or a session table.

The fundamental questions to ask are thus:

• Who does the mapping between groups of hosts and IP addresses?
• How is that mapping performed?
• When is the mapping done? In real time or offline?
• And finally, what/where is your single source of truth?

In this blog post we’re focusing exclusively on the mapping of host groups into IP address sets. Mapping software packages into TCP/UDP port numbers or URL patterns is a totally different can of worms.

The Extremes

In traditional firewall management the mapping is done manually by the firewall administrator often using dubious sources of truth (Excel spreadsheets, assumed knowledge, guesswork, traffic traces…).

On the other extreme, most decent cloud management platforms perform the mapping automatically, using cloud orchestration system as the single source of truth. For more details, listen to the excellent podcast with Brad Hedlund explaining how VMware NSX distributed firewall does its job.

TL&DL summary: Looking through the NSX Manager GUI it looks like the NSX distributed firewall is using VM groups or portgroups to enforce security policies. In reality, these definitions are compiled into sets of IP address using vCenter data and pushed into distributed firewalls as packet filters that are changed dynamically every time a VM is started, stopped, or assigned to a different security group.

OpenStack security groups are doing the same operations behind the scenes using iptables and ipset when implemented on Linux.

Best of both worlds?

Is there a middle ground? Could you use DNS names to translate human-readable rules into packet filters? The traditional answer was “no, because I don’t trust DNS”. OK, let’s look at some details:

• Most decently-managed enterprise environments have some sort of IPAM solution serving as single source of addressing truth (note I said “decently managed” ;)
• The same IPAM solution is used to generate data populating DNS zones;
• DNS server is using a read-only set of IPAM data to answer queries;
• DNS server is (hopefully) running in a highly protected zone on a redundant set of servers using anycast IP addresses for seamless failover.
• In Windows environments, the DNS server is getting its data straight from AD.

Based on all of the above, you still don’t trust DNS data? OK, you can stop reading.

Does it make sense to use DNS data in real time and build IP address sets on a firewall based on DNS queries? Definitely not in the data plane (on-the-fly), but the control plane approach is perfectly doable: the firewall could recheck DNS mappings when TTLs expire and adjust the firewall rule sets. But what if you want to be even more static than that?

My recent work with Ansible (while creating scenarios for my network automation workshop) gave me an interesting idea that might work for traditional non-cloudy environments:

• Define the security policies in human-readable terms;
• Transform those policies into a YAML model (or define them as YAML objects, they are pretty readable);
• Use Ansible DNS lookups to convert hostnames into IP addresses;
• Create firewall rules from security policies and DNS data;
• Compare new firewall rules with existing ones and report the changes (including changes in DNS lookup results);
• When a security engineer approves the changes, push them into firewalls.

Would that work? Would your security policy allow you to do that? Do you think this is better than managing firewall rules in Notepad? Please write a comment!