ASA HTTP Filtering by Domain with Host Headers

One of the questions that regularly comes up with firewalls is how to filter based on domain name. Access Control Lists, or ACLs, are designed to filter based on IP addresses and networks. One of the things that many would expect to see is an easy way to whitelist or blacklist sites based on their name. Although more challenging than one might expect, there is a way that the ASA’s HTTP application inspection can be utilized to perform this function.

Before I get into the details of this, I would caution that HTTP application inspection is best done in a content filter or something that is built primarily for that function. While what I’m about to outline can and will work, it may have performance ramifications and maintaining this type of configuration could create undesired complexities. As with any firewall change, I would encourage making changes in a lab environment that is similar to the applicable production configuration. Only after fully understanding the configuration and its ramifications, should it be implemented into a production environment.

The Host Header

The configuration in this article utilizesHost Header what is known as the host header. The host header is sent to the web server by the browser to indicate the host that it intends to retrieve information from. This information is leveraged when multiple sites are hosted with a shared IP address.

Prior to proceeding, it is important to understand a couple of key limitations of using this parameter and methodology. It is only available for web traffic (HTTP).  SSL encrypted traffic would not expose the host header to the HTTP inspection process. Therefore filtering HTTPS based on host headers, like all other non-http traffic, would not be possible. There may also be cases when a browser might exclude the host header from the request.

Flow Through The ASA

To understand this type of configuration, it is important to grasp some basics about traffic flow through the ASA. We often talk about blocking or permitting traffic with ACL’s. For the purpose of this article, the traffic is permitted to flow through the firewall at Layer 3 and Layer 4.

As traffic is initiated through the ASA, it is sessionized. The session can look like a simple TCP, UDP or ICMP session or it can be further inspected. This may also be known as deep packet inspection. For HTTP traffic, the transport layer is TCP. However our examples add the additional checks by doing an application level inspection. The diagram below shows that incoming sessions are first handled by Layer 3/4 Policies. Based on match criteria, our Layer 3/4 policies will request additional application layer policies be applied.

ASA Traffic Sessionization

The Challenges

This article has two specific challenges. The first challenge is to deny internal users the ability  to connect  to packetu.com and yahoo.com. This would include subsites such as www.packetu.com and www.yahoo.com. The second challenge is to reverse this and only allow access to these two sites for the internal users.

Layer 3/4 Policies and Application Policies

A quick glance at Layer 3/4 Policies and Application Policies reveal only subtle differences. Application policies have parameters that are custom to the protocol being inspected. Additionally, application policies utilize the “type inspect” when they are being defined. These policies have various elements that are defined by the administrator and used to link the components together. The graphic below shows how the components within and between the policy types are related.

L3 L4 and Application Policies

Challenge 1 — Explicitly Blocking Sites

Having a basic understanding of traffic sessionization and the role of both layer 3/4 policies and application policies, we can start looking at a couple of sample configurations. This first example will only allow access to sites at packetu.com and at yahoo.com. Non-HTTP traffic will be unaffected. All other HTTP traffic will be dropped.

//define the regular expressions 
//used to match the host headers
regex yahooc "yahoo\.com"
regex packetuc "packetu\.com"

//create a class map that matches any of the regex
//this is used to aggregate multiple regular expressions
class-map type regex match-any MYREGEX
 match regex packetuc
 match regex yahooc

//create a class map that matches the MYREGEX class-map
class-map type inspect http match-all MYDOMAINS
 match request header host regex class MYREGEX

//create an HTTP policy that drops anything matching
//the MYDOMAINS class map that was previously defined
policy-map type inspect http MYHTTP
 parameters
 class MYDOMAINS
  drop-connection log

//attach this to an L3/4 Class map that will direct http traffic
//to the MYHTTP application policy for further inspection
policy-map INSIDE
 class inspection_default
  inspect http MYHTTP
!
//apply the INSIDE L3/4 policy to interface inside
service-policy INSIDE interface inside

At this point, any browser requests from inside clients made using host headers that match the defined regular expressions should be dropped and logged.

Challenge 2 — Implicitly Blocking Sites

Sort of the opposite approach to the first challenge is permitting requests to yahoo.com and packetu.com. Any site not matching our expressions should be blocked. To do this, the configuration would be changed to the following.

//define the regular expressions 
//used to match the host headers
regex yahooc "yahoo\.com"
regex packetuc "packetu\.com"

//create a class map that matches any of the regex
//this is used to aggregate multiple regular expressions
class-map type regex match-any MYREGEX
 match regex packetuc
 match regex yahooc

//create an HTTP policy that drops anything matching NOT
//in the MYDOMAINS class map that was previously defined
class-map type inspect http match-all MYDOMAINS
 match not request header host regex class MYREGEX

//create an HTTP policy that drops anything matching
//the MYDOMAINS class map that was previously defined
policy-map type inspect http MYHTTP
 parameters
 class MYDOMAINS
  drop-connection log

//attach this to an L3/4 Class map that will direct http traffic
//to the MYHTTP application policy for further inspection
policy-map INSIDE
 class inspection_default
  inspect http MYHTTP
!
//apply the INSIDE L3/4 policy to interface inside
service-policy INSIDE interface inside

It is worth noting that this will not drop the connection until the non-matching host header is sent. Again at this point, the connection should be dropped and logged.

Caveats

  • As previously stated, this can only work for non-encrypted http traffic
  • Configuration is cumbersome at best
  • Care must be taken with negative and double negative (“NOT” used in multiple places) logic
  • Some sites host external content that must be considered
  • Applying may require removing previous L3/4 and reconfiguring
  • Action only taken if host header is included in the communication

Conclusion

The ASA has a complex L3/4 and application inspection engine. However, the configuration is cumbersome and difficult to follow. I typically recommend using the ASA as a layer 3/4 inspection device and punting the more complex work to a content engine such as an ASA CX (content module), Web Security Appliance (WSA), or Websense Appliance. However becoming familiar with the operation of the ASA inspection process and the capabilities may prove useful in unique circumstances or when more appropriate solutions are not available.

Those who found this useful should also check out–

Disclaimer: I am a CCIE Security and a Designated VIP on the Cisco Learning Network. This article was written and published without compensation and accurately represents my view of the product capabilities. As with all network changes, Firewall configurations should be proven in a lab that mirrors the production environment that they will be implemented. 

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.

4 Responses to ASA HTTP Filtering by Domain with Host Headers

  1. Peter esper says:

    From asa 8.4 you can now use hostnames/fqdn directly from an acl https://supportforums.cisco.com/docs/DOC-17014

  2. Ibrahim says:

    I think it will only block what ip address resolve by dns request for that domain and we know site like youtube facebook etc have many public ip

    • Paul Stewart, CCIE 26009 (Security) says:

      Very true. The method described by Peter will block using DNS resolution. It should understand multiple “A” records, but I’d be surprised if it works *exactly* as expected with sites that may do a server side round robin. The method I described uses host headers instead but has other limitations.

Comments are closed.