- Understanding the FQDN ACL Feature
- Basic Configuration
- Step 1: Define DNS server
- Step 2: Create the FQDN object for the host name in question
- Step 3: Add the FQDN Oject to an ACL
- Verify the ACL with FQDNs
- Best Practices
- Use a trusted DNS server
- Increase the lifetime for short-lived DNS records
- Limitations of the Feature
- Sites returning DNS responses with low TTL cause unpredictable access
- Multiple hostnames resolve to the same IP address
- Multiple DNS names for the same website
Understanding the FQDN ACL Feature
Starting in ASA version 8.4(2) (Feature not available in 8.5(1) code) , ACL entries can contain a new type of object that represents a fully qualified domain-name. This allows administrators to create ACL entries that contain a new object type fqdn that represents a hostname. For this functionality to work, the ASA must be able to resolve these FQDN's to one or more IP addresses. The object then becomes a representation of those IP addess(es).
Basic Configuration
Step 1: Define DNS server
Since the ASA has to be able to resolve each hostname to one or more IP addesses, we must define what DNS server the ASA can use.
domain-name cisco.com ! dns domain-lookup inside dns server-group DefaultDNS name-server 192.168.1.200 domain-name cisco.com
Step 2: Create the FQDN object for the host name in question
Similar to creating other object in the 8.3.x code and later, we need to define the fqdn under the object
object network obj-hr88.cisco.com fqdn hr88.cisco.com
Step 3: Add the FQDN Oject to an ACL
Reference the newly created Object in an ACL on the ASA so we can begin to resolve it
access-list inside_in deny ip any object obj-hr88.cisco.com access-list inside_in permit ip any any
Verify the ACL with FQDNs
Once the access-list is applied to the security policy of the ASA, the ASA will resolve the DNS entries to IP addresses, then use those IP addresses in the access-list.
ASA# show access-list inside_in access-list inside_in; 4 elements; name hash: 0xd3a8690b access-list inside_in line 1 deny ip any object obj-hr88.cisco.com access-list inside_in line 1 deny ip any fqdn hr88.cisco.com (resolved) access-list inside_in line 1 deny ip any host 10.32.2.4 (hr88.cisco.com) (hitcnt=10) access-list inside_in line 1 deny ip any host 10.32.2.3 (hr88.cisco.com) (hitcnt=35) access-list inside_in line 2 permit ip any any (hitcnt=12022)
The 'show dns' command will display the IP to hostname mappings currently active on the ASA
ASA# show dns Name: hr88.cisco.com Address: 10.32.2.4 TTL 13:27:02 Address: 10.32.2.3 TTL 13:27:02
Best Practices
Use a trusted DNS server
Obviously it is important that the DNS server used by the ASA for FQDN resolution is trusted, since the responses from this DNS server will affect the security policy of the ASA. You also want to ensure that your DNS server is stable and has a very low latency since your security policy will rely on the results it recieves.
Increase the lifetime for short-lived DNS records
When the ASA receives the response from the DNS server for the ACE hostname resolution, the answer has a Time to Live (TTL) associated with it. The ASA will keep that domain-to-ip mapping active until the TTL expires, at which time the ASA will re-resolve the IP address of the hostname.
The output of 'show dns host hostname' will show the TTL of the DNS entry on the ASA:
In some cases, DNS responses might be extremely short, on the order of a few seconds. Usually, low lifetimes like this are employed by DNS load-balancers and content hosting services where IP addresses change frequently. If many DNS entries are used on the ASA, short TTLs might cause the ASA to re-resolve the IP addresses very frequently, therby causing extra load on the ASA, DNS server, and the network.
The ASA can be manually configured to increase the TTL of each response it receives by a set time value, using the command
'dns expire-entry-timer minutes minutes'. For example, to increase the timeout by 60 minutes you would use the following command:
dns expire-entry-timer minutes 60
Limitations of the Feature
It should be emphasized that this new FQDN ACL feature on the ASA is not a replacement for URL filtering solutions. Administrators attempting to write basic ACL policies that permit or deny traffic to FQDN names outside of their organization might have intermittent success, due to the factors discussed below. The preferred methods for blocking access to certain websites is the use of an external URL filtering server, or by using the application inspection on the ASA to control the access.
Sites returning DNS responses with low TTL cause unpredictable access
Some popular websites such as www.facebook.com send back DNS responses with very low Time To Live (TTL) values. The screenshot below is from a packet capture. It shows that the DNS server responded back to the request and indicated that the TTL of the entry was only 20 seconds.
This means that a computer would continue to use the IP 69.171.224.14 for www.facebook.com for 20 seconds, and after 20 seconds it would re-resolve the DNS entry and use the new IP address the DNS server responded with :
The ASA will behave slightly differently with the TTL indicated in the DNS response. By default (and at a minimum) the ASA always adds one minute to the TTL (due to the default command 'dns expire-entry-timer 1') of the response received to the DNS request, meaning that in this case the ASA would consider the entry valid for one minute and twenty seconds.
ASA# show dns Name: www.facebook.com Address: 69.171.224.41 TTL 00:01:20 ASA#
The side effect of this is that the inside client will start using a new IP address for www.facebook.com one minute before the ASA updates its own IP to hostname mapping, and during that time the access-list line might not match. This would result in the clients being permitted or denied intermittently when they access www.facebook.com.
Multiple hostnames resolve to the same IP address
If two hostnames resolve to the same IP address, the ASA cannot distinguish between the two, since it is essentially blocking or permitting the traffic based on the destination IP address in the packet. Many popular webpages have moved away from hosting thier own content to using content delivery networks like Akamai, Amazon CWS. This means that come FQDN's may resolve to IP addresses used by these content hosting providers and they may host multiple sites worth of content on the same IP. This is also seen with Webhosting companies like GoDaddy, Network Solutions, etc. These providers may use one signle IP to host hundred of websites. The content served to you web-browser is determined based on the URL accessed (and the Host: field in the HTTP request). Let take a simple example of 'URL FIltering' and see how it can go awry. Here is the simplified config:
object network obj-superbadwebsite.com fqdn superbadwebsite.com ! access-list inside_in deny ip any object obj-superbadwebsite.com access-list inside_in permit ip any any
Now lets say that superbadwebsite.com is hosted by HostingCo which also hosts benign websites like catsinsinks.com (benign all-beit a time waster). HostingCo uses webservers at 64.102.67.9 an 64.102.67.10 so now our ACL looks like:
access-list inside_in line 1 deny ip any object obj-superbadwebsite.com access-list inside_in line 1 deny ip any fqdn superbadwebsite.com (resolved) access-list inside_in line 1 deny ip any host 64.102.67.10 (superbadwebsite.com)(hitcnt=5) access-list inside_in line 1 deny ip any host 64.102.67.9 (superbadwebsite.com)(hitcnt=120) access-list inside_in line 2 permit ip any any (hitcnt=4423)
If someone in your network wants to browse the site http://catsinsinks.com they will not be able to. This is because catsinsinks.com will resolve to either of the IP's that HostingCo uses, both of which are blocked because they were the A-Records returned when we resolved superbadwebsite.com. This issue can be summed up in the follow way:
FQDN functionality in ACLs is not a replacement for HTTP Filtering. It cannot distinguish what content is being sent.
Multiple DNS names for the same website
Another reason to stay away from URL filtering using FQDn's... if you were to create an object and use it to block the following fqdn "www.facebook.com" users may still be able to get to "facebook.com". This is because both FQDN's resolve to different IPs. Blocking one FQDN for a website does not always block all the possible was of accessing it:
admin@server> host www.facebook.com www.facebook.com has address 69.171.224.13 admin@server> host facebook.com facebook.com has address 69.63.181.12 facebook.com has address 69.63.189.11 facebook.com has address 69.63.189.16
