Introduction
One of the ASA features is URL filtering. It can be used to block or allow users from going to certain URLs/websites. This article aims to educate the user on how to use and configure this feature via ASDM. After reading it carefully someone should be able to take full advantage of URL filtering and use it for his needs. This page supplements the ASA URL Filtering (via CLI) at the link below:
https://supportforums.cisco.com/docs/DOC-1268
In this article we will either block or allow domains in URLs and words in the URI. Of course the ASA can match on other things, too. They can be found in the ASA configuration guides. From now and onwards we will allow or block the cisco.com domain. In other words, any user browsing to any page that is behind cisco.com will be subject to URL filtering. Such pages would be www.cisco.com/index.html or cisco.com/exampledir/page.html. Also, we will allow or block "/test/" in the URI. In other words, any page path that contains "/test/" will be URL filtered. Examples are www.examplesite.com/exampledir/test/page.html or www.anyurl.com/test/examplepage.jsp or www.anything.com/onedir/seconddir/test
The mechanism used to apply URL filtering is Modular Policy Framework (MPF). We will create regular expressions (regex) that will be matched in class-maps of type http. These class-maps will be used in policy-maps to define the drop action. Then the policy-maps will be applied with an http inspection in another policy-map that will be applied to an interface. In that way the http inspection action will be applied to the traffic that hits an interface.
NOTE: Though, we need to highlight that for Enterprise URL Filtering, customers should be steered toward using WebSense or N2H2 integration with the ASA. Such web filtering engines can provide much more robust filtering based on classes of sites. URL filtering directly on the ASA using regex, should be used only sparsely when broad classifications can be applied, with limited regex patterns. The ASA will not scale being used in an enterprise with large regex matches and large volumes of HTTP traffic.
Block specific urls
Lets assume that we want to block some specific websites. For example we want to block specifically anything under cisco.com and URIs that contain "/test/". We will create the regexes and match them in a class-map. Note that if ANY regex is matched then the class-map will actually be met. Then in the policy-map block-url-policy whatever meets the class-map (cisco.com OR URI containing "/test/") is reset. The rest are allowed (not cisco.com and not URI containing "/test/"). The policy-map block-url-policy is used for http inspection in another policy-map (global_policy) and applied with a service-policy.
1.) Configure two regex - one matching "/test/" and one matching "cisco\.com" (the backslash "\" is used as an escape character that will match the literal period ".").
In the top pane, select "Add". This will allow you to add a Regex. We will add the first regex, named "blockex1" with the value "/test/".
We repeat this process for the second regex, "blockex2", assigning the value of "cisco\.com". The two regex ("blockex1" and "blockex2") are shown at the bottom of the regex list.
We will now define a single class-map that will use these regex as the match criteria. The first match statement will match a URI with regex "blockex1". The second match statement will match a HTTP header where the host field matches "blockex2". To define the class-map, we'll expand 'Class Maps' on the left and select 'HTTP'.
Click the "Add" button on the right.
Allow every url for specific hosts, block specific urls for the rest
Finally, lets say that we have a few hosts (administrators, i.e. ip address 192.168.1.2) that need access to any website and the rest of the users need to be blocked from specific websites (Note: that you need to understand the example above to be able to follow the process of this example). We will use approximately the same configuration as in the example above but this time we will need an extra access-list, a class-map and a policy-map. This access-list (user-acl) will match all the users with the exception of the ones that need unrestricted access. It will be matched in a new class-map (block-user-class) which in turn will be used in a separate policy-map (block-user-url-policy). That policy-map will do the http inspection for the allowed websites policy-map block-url-policy (that part is the same as above). Thus the block-user-url-policy will be applied to an interface with a service-policy. What this policy-map is actually doing is to match on all the users except the unrestricted ones (class block-user-class) and block them from going to the specified websites (inspect http block-url-policy). The rest of the users (not matching/denied in the access-list) will be able to go anywhere.
Allow only cisco.com
Let's assume that we want to allow only cisco.com. We create the regex and match them (match statement) in a class-map. Note that if the match statements are matched the class-map is met. The match statement is met the regex is NOT matched by the URL, then in the policy-map allow-url-policy the connection is reset. The rest is allowed (cisco.com). In other words, if the page you browse is not cisco.com it will be reset. The policy map is used for http inspection in another policy-map (global_policy) and applied with a service-policy.
Allow specific urls
Let's assume that we want to allow only specific websites. For example we want to allow only cisco.com pages and only URIs that contain "/test/". We create the regexes and match them in a class-map. Note that if both match statements are matched the class-map is met. Both the match statements are matched if and only if NEITHER regex is matched by the URL browsed by the user. Then in the policy-map allow-url-policy the connection is reset. The rest is allowed (cisco.com or URI containing "/test/"). In other words, if the page you browse is neither cisco.com nor contains "/test/" in the URL, it will be reset. The policy map is used for http inspection in another policy-map (global_policy) and applied with a service-policy.
Allow every url for specific hosts, allow only specific urls for the rest
Now lets say that we have a few hosts (administrators, i.e. ip address 192.168.1.2) that need access to any website and the rest of the users need to be able to go only to specific websites (Note that you need to understand the example above to be able to follow the process of this example). We will use approximately the same configuration as in the example above but this time we will need an extra access-list, a class-map and a policy-map. This access-list (user-acl) will match all the users with the exception of the ones that need unrestricted access. It will be matched in a new class-map (allow-user-class) which in turn will be used in a separate policy-map (allow-user-url-policy). That policy-map will do the http inspection for the allowed websites policy-map allow-url-policy (that part is the same as above). Thus the allow-user-url-policy will be applied to an interface with a service-policy. What this policy-map is actually doing is to match on all the users except the unrestricted ones (class allow-user-class) and allow them only to go to the specified websites (inspect http allow-url-policy. The rest of the users (not matching/denied in the access-list) will be able to go anywhere.
Same domain allow/deny
The requirements are as follows:
1. deny facebook.com
2. allow developer.facebook.com which gets redirected automatically to developers.facebook.com
3. and all other domains like yahoo.com and google.com
Alternatively, one could also tie the http policy-map to the default inspection under the global_policy.
Bear in mind, every time you add remove or change regex, you need to remove the service-policy applied to the interface and add it again.
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_basic.html#wp1514315
If you need to change a match command for HTTP inspection after configuring the inspection, you must remove the attached service policy by using the no service policy command and then reconfigure the service policy. Changing the class map by removing a match command causes HTTP inspection to block all HTTP traffic until you remove and reconfigure the attached service policy so that all the match commands are reprocessed.