URL Filtering

URL Filtering

In addition to Java applet filtering, IOS Firewall can also be configured to filter the web traffic based on other criteria such as address, userid, group, and so on to websites on the internet. This feature is called URL Filtering or Destination URL Policy Management and is introduced in versions 12.2(11) YU and 12.2(15) T and above.

Now look at the details of how URL filtering works with CBAC. The following sequence of events occurs when a CBAC router is configured with URL filtering as shown in Figure 5-4:

Step 1.
The CBAC router configured with URL filtering receives an HTTP request from a user wanting to go to a specific website.

Step 2.
The router simultaneously forwards the request to the destination websites and a query to the URL filter server. The query contains the requested URL destination Domain Name System (DNS) or Internet Protocol (IP) address.

Step 3.
The server replies with a permit or denial of access to the router that is based on the policy setup on the server.

Step 4.
The router either allows or denies (when it denies, the URL server redirects the users to information that indicates which category the user is denied) based on the response from the URL server.


Step 2 needs little more elaboration. Before the router queries the server (if configured) it goes through two local tables on the router that contain the URLs of the destination web servers. Based on the tables, either all users are always permitted or always denied. If no entries or matches are found, the router checks its local cache to determine if the request has been made at an earlier time. If so, it studies the results. To improve the performance, this caching is enabled by default, and does not need to be explicitly configured. By default, the cache table can hold 5000 IP addresses. This can be modified with the following command:



Caching enriches the URL filtering by minimizing the number of URL query requests that are sent to the filter server. It is interesting to note that the filter server makes decisions about caching an IP address. When the filter server receives a query request from Cisco IOS Software, it checks whether the request needs to be cached. If it does, the filter server sets a bit map in the response, which indicates that the IP address needs to be cached.

The URL server is a large detailed knowledge base of the Internet and has categorized many URLs into one of the more 80 categories including gaming, pornography, MP3s, freeware, shareware, and so on. You can define the policy based on one of the following categories:

  • Allowable URL categories

  • Users and groups that can access the content

  • Timeframes in which access to content is allowed

  • Additional content restrictions (that is, content is permitted by a time-based quota, with a warning message)

  • Indication of whether the filtering is enforced or content is just monitored and stored in a database

Any degradation of network traffic performance due to URL filtering is not noticed by the user. For performance reasons, the GET request is forwarded to the desired URL destination if nothing triggers the local mechanisms, and to the URL server simultaneously. If the router has not received permission or denial by the time the destination URL replies with a web page, the router does not forward it, but instead holds it in its buffer until the reply comes from the URL server. If the URL server permits, the router allows the connection and maintains that URL in the cache. If the URL server denies, the router drops the connection, redirects the users, and gives them the reason the connection was denied. This cache improves the performance dramatically.

The commands for turning on URL filtering on the CBAC router follow: