In today’s IT world, we are relying more and more on public cloud services such as Amazon Web Services (AWS), Azure and Google Cloud which typically have large IP address allocations. These cloud providers have the right to change the IP address of your hosted environment at any point in time and it is important that as network engineers, we can configure our equipment to dynamically adapt to applications changing IP addresses.
Although in some environments use proxy servers for web traffic, there are some applications and websites which simply don’t work via a proxy, meaning traffic must bypass a firewall, typically at your internet edge.
Cisco Adaptive Security Appliance (ASA) running versions 8.4(2)+ have a built-in feature which allows us to filter website addresses via their DNS entries, defined with the `fqdn` command within a network object. There are multiple use cases such as forming VPNs, but this article will specifically focus on resolving DNS names for the purpose of access filtering.
Seeing up an ASA appliance to perform DNS lookups can be broken down into four simple tasks:-
- Define a trustworthy DNS server and tell the ASA where to look it up.
- Define your FQDN to lookup
- Apply in an access list
Before we dive into a scenario relating to dynamic web filtering for ASA’s, we should take a moment to look at potential risks which are associated with enabling this new feature.
The first risk and potentially the most important is the ability to reference a secure and trustworthy DNS server in your ASA configuration. The reason being, if the DNS server you are referencing is exploited, an attacker could change DNS entries to point to a malicious destination and perform a man in the middle (MITM) attack.
Secondly, for websites such as Google and Facebook, due to their IP range, when a resolution occurs, they may receive an entry with a short time-to-live (TTL) value. This can cause an issue when users resolve the same website but receive a different entry from the DNS server, causing their connection attempt to be denied.
A customer has approached us and asked us to perform proxy-bypass filtering for access to facebook.com and twitter.com from the 172.16.1.0/24 subnet. They have specifically requested that we implement a low expense and dynamic solution.
The customers DNS servers are hosted within their DMZ and have an address of 10.0.0.1 and 10.0.0.2 which are hosted on the ‘dmz’ interface of the ASA. The customer also wants to ensure that the TTL for DNS entries is set to 60 minutes, ensuring no resolution issues are seen.
Step 1: Configure the domain and DNS settings.
dns domain-lookup dmz dns expire-entry-timer minutes 60 dns server-group DefaultDNS name-server 10.0.0.2 name-server 10.0.0.3
Step 2: Configure the object to define the websites which are required to filter, for neatness we will apply it to an object-group and bind it to an access list.
object network FACEBOOK.COM fqdn facebook.com object network TWITTER.COM fqdn twitter.com ! object-group network PROXYBYPASS network-object object FACEBOOK.COM network-object object TWITTER.COM ! access-list acl_inside extended permit object-group LAN object-group PROXYBYPASS object-group HTTP_HTTPS
Step 3: Now it’s time to verify our work to ensure that the configuration is being filtered correctly.
show dns host twitter.com Name: twitter.com Address: 220.127.116.11 TTL 00:00:06 ! show dns host facebook.com Name: facebook.com Address: 18.104.22.168 TTL 00:00:10 show access-list acl_inside | begin NONPROXY