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 utilizes 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.
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.
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.
- 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
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.