ASA FQDN access-lists Part 1

A recent change came through which required a geo-spatial map data server from an isolated network to cache maps from various public entities. The geo-spatial database calls upon various websites.  The use of Bing, Google, government agencies, traffic management combine together to provide layered map data.  With a static source references a dynamic entity the need to look beyond IP addressed destinations was required.

The Fully Qualified Domain Name (FQDN) access-lists were introduced in 8.4(2) and allow name to ip resolution for access-lists. This post outlines what is required to perform DNS lookup to enable FQDN ACLs.

A DNS server is required to perform the lookup and resolve the FQDN.

domain-name ciscoinferno.net
dns domain-lookup inside
DNS server-group SG-CI-DNS
    name-server 10.0.20.100
    name-server 10.0.30.100
    domain-name ciscoinferno.net <strong> </strong>

Now like any other object in the ASA we can reference the FQDN. This allows us to define the site in question.

object network OBJ-maps.google.com
   fqdn maps.google.com

As you would reference an object normally on the ASA you can reference the OBJ-maps.google.com. This has the nested FQDN.

access-list acl-inside permit ip any object OBJ-maps.google.com
access-list acl-inside deny ip any any

To check access-list hit counts and what is in an access-list normally you would issue a show access-list . When you use a FQDN ACL it is a little different.  This is a standard ASA access-list.

ASA5515X# sh access-list OLD-ACL
access-list OLD-ACL line 10 extended deny ip 172.16.0.0 255.255.0.0 any (hitcnt=2314931)
access-list OLD-ACL line 11 extended permit ip 192.168.0.0 255.255.0.0 any (hitcnt=29207)

This is a FQDN access-list. Notice the resolved addresses make entries themselves in the ACL.

ASA5515x# show access-list acl-inside
 access-list acl-inside line 1 permit ip any object OBJ-maps.google.com 
 access-list acl-inside line 1 permit ip any fqdn maps.google.com (resolved) 
 access-list acl-inside line 1 permit ip any host 74.125.238.104 (maps.google.com) (hitcnt=5810) 
 access-list acl-inside line 1 permit ip any host 74.125.237.105 (maps.google.com) (hitcnt=3351) 
 access-list acl-inside line 1 permit ip any host 74.125.238.110 (maps.google.com) (hitcnt=15) 
 access-list acl-inside line 1 permit ip any host 74.125.237.96 (maps.google.com) (hitcnt=12) 
 access-list acl-inside line 1 permit ip any host 74.125.238.97 (maps.google.com) (hitcnt=0) 
 access-list acl-inside line 1 permit ip any host 74.125.237.98 (maps.google.com) (hitcnt=0) 
 access-list acl-inside line 1 permit ip any host 74.125.238.99 (maps.google.com) (hitcnt=0) 
 access-list acl-inside line 1 permit ip any host 74.125.237.100 (maps.google.com) (hitcnt=0) 
 access-list acl-inside line 2 deny ip any any (hitcnt=259428)

This has definitely helped in the business problem we had. Now we rely on DNS servers we do expose ourselves to DNS hijacking. Additional filtering can be applied to narrow ip any to the specified host to include port information. This tightens the vector of attack. The next part looks at DNS packet information and tweaking FQDN resolution for look up improvement.

 

Cisco DOCCD – the single point of truth

Many are aware I am working on my CCIE. I currently have the written exam lined up and in might sights. Given my enterprise background there are quite a few technologies in which I do not get to deploy quite often. The blueprint provides me a point of reference to study against. Technologies I come across that I do not deploy often end up getting tested in the lab. What happens when you need to clarify something?

This may be the one time where I would say “do not google the topic!” It is important that you get your information from a trusted source. Our community has a lot of user-generated information. We all blog, we develop articles based upon the technologies we use. The only problem is that sometimes they are cornerstone cases, maybe a mistype, or in a rare case, not all caveats are documented. The problem arises in the fact what you may read from an unofficial source

The DOCCD is the online version of Cisco’s documentation. It is supplied to CCIE lab hopefuls as reference when in times of strife. It allows a candidate to quickly look up a nuance or that command that slips the mind. This combination of documents force the single point of truth for your studies. It is good practice to reference it where possible. Cisco bases its exams off the contents. It is also important to use this in your studies due to the fact learning the document structure will save you time. In an exam where 8 hours seems like 15 minutes every second counts.

As per the Cisco CCIE documents the following hardware versions are used in the lab.

  • Version 4.0
  • 1841 series routers – IOS 12.4(T) – Advanced Enterprise Services
  • 3825 series routers – IOS 12.4(T) – Advanced Enterprise Services
  • Catalyst 3560 Series switches running IOS version 12.2 – Advanced IP Services

Where you should look to find commands relating to IOS 12.4(T) resides under the following stanza.

Products > Cisco IOS and NX-OS Software > Cisco IOS > Cisco IOS Software Release 12.4 Family > Cisco IOS Software Releases 12.4 T

 

Screen Shot 2013-08-04 at 5.15.25 PM

Once you select Cisco IOS Software Releases 12.4 T you are brought to all information relating to 12.4 T.

Screen Shot 2013-08-04 at 5.19.02 PM

What I look to is the command reference guides. These will give commands and related troubleshooting commands for a specific feature.

Screen Shot 2013-08-04 at 5.19.40 PM

 

 

The above show a sample of what is included under the 12.4 T banner. Quite a lot of information. This point of reference is the ultimate source of truth regarding the technologies used in the CCIE exam. Whether you are doing the lab or doing the written the message relates to you! It is a great habit to start using it and learning the document structure. The seconds you save in your exams the few times you reference it may just be the difference between the magical pass and failure.