DotW: FQDN Policy

In the week's Discussion of the Week (DotW), we'll  take a look at a question from user 'aguley' about FQDN.

Even though it's not possible to use a wildcard inside an FQDN object, I'll highlight two possible workarounds.

When an FQDN object is committed to the system, the management plane sends out periodic DNS queries to populate this object with IP addresses mapped from the DNS reply. These mapped IP addresses are then be pushed down to the dataplane, where they're used inside the object in the security policy. On the dataplane, this object includes only the IP addresses it receives from the management plane, but no domain information. Each FQDN object on the dataplane is limited to a maximum of 10 IP addresses. No actual URL lookups are performed, which is why a wildcard cannot be used.

If the requirement is to allow web browsing to all possible subdomains of a certain domain, a Security Policy based on a custom URL category in the destination could be useful to fill the gap between an FQDN Object and a URL Filtering Security Profile.

The first step is to create a custom URL category that includes the desired wildcard domains:

Next, a Security Policy where the custom URL category is used in the service/URL category tab.

Note: A URL filtering license or URL Filtering Security Profile is not required for this to work.

This allows outbound web browsing to all subdomains of the domain while all other connections can be blocked.

A slightly more complex workaround that allows for more versatility is to use Dynamic Address Groups and Tags that can be updated by an API call. In this scenario, the DNS resolution must be performed by an external script, but the number of addresses allowed in a Dynamic Address Group is far greater than in an FQDN Object.

First, you'll need to generate an API key:

https://hostname/api/?type=keygen&user=username&password=password

 Where hostname is the firewall IP or hostname, username and password are your username and password.

The output will look somewhat like this:

Next, create a Tag to represent the IP address pool:

Then create a new Dynamic Address Group and add the Tag as Match Criteria:

Finally, create a security policy using the DAG.

This DAG can now be populated with IP addresses from an external script. IPs can be added with a register operation or removed with an unregister operation.

This example was prepared to register 2 new IP addresses to the wildcard1 Tag:

user@myserver:~# cat wildcard.xml 
<uid-message>
<version>1.0</version>
<type>update</type>
<payload>
<register>
  <entry ip="195.51.100.1">
  <tag>
  <member>wildcard1</member>
  </tag>
  </entry>
  <entry ip="195.51.100.2">
  <tag>
  <member>wildcard1</member>
  </tag>
  </entry>
</register>
</payload>
</uid-message>

The file can be pushed out with either wget or curl--the example uses wget:

user@myserver:~# wget --no-check-certificate --post-file wildcard.xml "https://MyIP/api/?type=user-id&action=set&key=111MyKey111=&file-name=wildcard.xml&client=wget" --no-http-keep-alive
--2015-09-28 10:30:30--  https://MyIP/api/?type=user-id&action=set&key=111MyKey111=&file-name=wildcard.xml&client=wget
Connecting to MyIP:443... connected.
WARNING: cannot verify MyIP's certificate, issued by '/C=US/ST=CA/L=Sunnyvale/O=Palo Alto Networks/OU=Support/CN=localhost/emailAddress=support@paloaltonetworks.com':
  Self-signed certificate encountered.
    WARNING: certificate common name 'localhost' doesn't match requested host name 'MyIP'.
HTTP request sent, awaiting response... 200 OK
Length: 167 [application/xml]
Saving to: 'index.html?type=user-id&action=set&key=111MyKey111=&file-name=wildcard.xml&client=wget'

100%[======================================================>] 167         --.-K/s   in 0s      

2015-09-28 10:30:31 (36.7 MB/s) - 'index.html?type=user-id&action=set&key=111MyKey111=&file-name=wildcard.xml&client=wget' saved [167/167]

To verify the IP addresses were added, click the more... link in the GUI Address Groups:

Or use the CLI command:

admin@PA-200> show object registered-ip all

registered IP Tags
---------------------------------------- -----------------

195.51.100.1 #
 "wildcard1"

195.51.100.2 #
 "wildcard1"

Total: 2 registered addresses
*: received from user-id agent #: persistent

You can also verify the IP addresses are now in use in the Security Policy:

admin@PA-200> show running security-policy

dynobject {
        from trust;
        source any;
        source-region none;
        to untrust;
        destination [ 195.51.100.1 195.51.100.2 ];
        destination-region none;
        user any;
        category any;
        application/service  any/any/any/any;
        action allow;
        icmp-unreachable: no
        terminal yes;
}

To view the original discussion, please follow this link: FQDN policy

All comments or suggestions are encouraged.

Thanks for reading!

Tom Piens

For additional information:

RegEx Pattern for FQDN Address Object

How to Configure and Test FQDN Objects 

More information about Dynamic Address Groups:

Working with Dynamic Address Groups on the Palo Alto Networks firewall