fir3net
PPS-Firenetbanner-780.5x190-30-03-17
  • Home
  • Articles
  • Firewalls
  • Cisco
  • Cisco ASA - How to Permit/Deny Traffic based on Domain Name (FQDN)

Cisco ASA - How to Permit/Deny Traffic based on Domain Name (FQDN)

Introduction

Introduced within Cisco ASA version 8.4(2), Cisco added the ability to allow traffic based on the FQDN (i.e domain name).
This feature works by the ASA resolving the IP of the FQDN via DNS which it then stores within its cache. Traffic is then either denied or permitted accordingly.

Within this article will look at the configuration, caveats and some of the key commands required for troubleshooting.

Configuration

There are 2 steps in configuring FQDN lookups. The first is to configure DNS, the access policy is then created.

Configure DNS

To configure DNS the egress interface, the DNS servers IP (here it is 8.8.8.8) and default domain name is defined.

dns domain-lookup outside
DNS server-group DefaultDNS
  name-server 8.8.8.8
  domain-name fir3net.com

Configure Access Policy

Next we define our FQDN via a network object group. This group is then specified within an ACL (as shown below).

object network obj-google.com
 fqdn google.com

access-list acl-inside extended deny ip any object obj-google.com
access-list acl-inside extended permit ip any any log

Show

When troubleshooting there are 2 key commands, 'show access-list ...' and 'show dns'.

ACL

To quickly see the IP`s that have been resolved and that have been added to the ACL, the command 'show access-list <ACL NAME>' is used.

asa-skyn3t(config)# sh access-list acl-inside
access-list acl-inside; 13 elements; name hash: 0x3a87ecb6
access-list acl-inside line 1 extended deny ip any object obj-google.com (hitcnt=29) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any fqdn google.com (resolved) 0xbd27c0d0
  access-list acl-inside line 1 extended deny ip any host 173.194.34.104 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.99 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.96 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.100 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.110 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.101 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.105 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.102 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.98 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.103 (google.com) (hitcnt=0) 0x8aaa140d
  access-list acl-inside line 1 extended deny ip any host 173.194.34.97 (google.com) (hitcnt=29) 0x8aaa140d
access-list acl-inside line 2 extended permit ip any any log informational interval 300 (hitcnt=8531062) 0x433f2632 

Cache

To view the cache the command 'show dns' is used. This provides the remaining TTL for each of the cached responses.

asa-skyn3t(config)# sh dns
Name: google.com
  Address: 173.194.34.104                                TTL 00:02:58
  Address: 173.194.34.99                                 TTL 00:02:58
  Address: 173.194.34.96                                 TTL 00:02:58
  Address: 173.194.34.100                                TTL 00:02:58
  Address: 173.194.34.110                                TTL 00:02:58
  Address: 173.194.34.101                                TTL 00:02:58
  Address: 173.194.34.105                                TTL 00:02:58
  Address: 173.194.34.102                                TTL 00:02:58
  Address: 173.194.34.98                                 TTL 00:02:58
  Address: 173.194.34.103                                TTL 00:02:58
  Address: 173.194.34.97                                 TTL 00:02:58

Caveats

Now, lets look at some of the caveats that this feature brings,

URL Filtering

As you will appreciate as this feature doesn't look into the HTTP content (i.e URI or host header) it is important to understand that this feature is not a replacement for URL filtering.

Security

As the DNS protocol is used for FQDN to IP resolution this adds an additional attack vector (i.e cache poisoning attacks etc) to your environment. Because of this it is recommended to use a trusted (i.e internal) DNS server.

Multiple FQDN`s

As you will be aware multiple FQDN`s can reside on a single IP. Meaning that, though you may permit abc.com as xyz.com also resolves to the same IP. You are not only permitting access to abc.com but also xyz.com.

Single IP Answers

Many DNS servers respond with a single IP at a time, with each subsequent request resulting in different IP address being returned. As you will appreciate this isn't ideal, as it can result in the ASA resolving a different IP to the client and traffic being intermittently allowed or denied.  

Loadbalanced DNS TTLs

Many DNS hosting providers present a server farm (pool) of DNS servers via a single IP address. For each DNS query that is sent, the request is loadbalanced across the pool of DNS servers. Based on this and also that the TTL value returned from a DNS caching server is the TTL value from its cache (where as an authoritative servers which provides the TTL set on the actual record).

Why does this matter ? Lets consider the following scenario,

  1. The ASA queries DNS for xyz.com.
  2. The request is sent to a loadbalanced pool of DNS servers. DNS Server A responds with an answer of 1.1.1.1 with a TTL of 30 seconds.
  3. The client then queries DNS for xyz.com.
  4. The request is sent to a loadbalanced pool of DNS servers. DNS Server B responds with an answer of 1.1.1.1 with a TTL of 3600 seconds.
  5. The ASA DNS entry then expires 30 secs later.
  6. The ASA then queries DNS for xyz.com again.
  7. The request is sent to a loadbalanced pool of DNS servers. DNS Server A responds with an answer of 2.2.2.2.
  8. As the ASA still has a DNS cache entry of 2.2.2.2 but the client has an entry of 1.1.1.1 traffic will be incorrectly (depending on the ACL action) permitted or denied.

In this situation you should look to configure the "expiry timeout value". This will allow you to increase the TTL of the DNS entry within the ASA cache. Further details can e found within the 'Expiry Timeout' section, further down.

Unreachable DNS Server

There are times when the DNS server is unreachable. Should this occur, and the ASA is unable to resolve the IP of the FQDN then the ACL will be marked as 'inactive', as shown below.

asa# sh access-list acl-inside
access-list acl-inside; 5 elements; name hash: 0xf4313c68
access-list acl-inside line 1 extended permit ip any object obj-google.com 0xb541940f
  access-list acl-inside line 1 extended permit ip any fqdn google.com (unresolved) (inactive) 0x54f9d97f
access-list acl-inside line 2 extended permit ip host 192.168.100.200 any (hitcnt=0) 0x923a45a3
access-list acl-inside line 5 extended deny ip any any (hitcnt=12) 0x7b5326c0

Expiry Timeout

Though not a direct caveat, the way in which the use of the 'expiry timeout value' is good to know.
The 'expiry timeout value' defines the additional time that the ASA will wait once the original TTL has expired, before it removes the entry from its cache.

dns expire-entry-timer minutes <minute>

Example : The command 'dns expire-entry-timer minutes 2' is used.  The DNS server returns an IP of 1.1.1.1 with a TTL of 5 minutes. The ASA then adds this entry to its cache with a TTL of 7 minutes.  After the 5 minutes (the original TTL) has expired the ASA re-queries DNS*.

* If a different IP is returned this is added to the cache along with the existing cache entries.

Note : Both the minimum and default DNS expire-entry-timer value is 1 minute.

References

http://www.cisco.com/en/US/docs/security/asa/command-reference/d7.html
https://supportforums.cisco.com/docs/DOC-17014

Tags: ASA, Cisco, DNS

About the Author

RDonato

R Donato

Rick Donato is the Founder and Chief Editor of Fir3net.com. He currently works as a Principal Network Security Engineer and has a keen interest in automation and the cloud.

You can find Rick on Twitter @f3lix001