URL conditions in access control rules allow you to limit the websites that users on your network can access. This feature is called URL filtering. There are two ways you can use access control to specify URLs you want to block (or, conversely, allow):

• With any license, you can manually specify individual URLs, groups of URLs, and URL lists and feeds to achieve granular, custom control over web traffic.

• With a URL Filtering license, you can also control access to websites based on the URL’s general classification, or category, and risk level, or reputation. The system displays this category and reputation data in connection logs, intrusion events, and application details.

Note	To see URL category and reputation information in events, you must create at least one access control rule with a URL condition.

You can combine URL conditions with each other and with other types of conditions to create an access control rule. These access control rules can be simple or complex, matching and inspecting traffic using multiple conditions.

When you block a website, you can either allow the user’s browser its default behavior, or you can display a generic system-provided or custom page. You can also give users a chance to bypass a website block by clicking through a warning page.

With a URL Filtering license, you can control your users’ access to websites based on the category and reputation of requested URLs:

• The URL category is a general classification for the URL. For example, ebay.com belongs to the Auctions category, and monster.com belongs to the Job Search category. A URL can belong to more than one category.

• The URL reputation represents how likely the URL is to be used for purposes that might be against your organization’s security policy. A URL’s risk can range from High Risk (level 1) to Well Known (level 5).

Note	Before access control rules with category and reputation-based URL conditions can take effect, you must enable communications with Cisco Collective Security Intelligence (CSI) to obtain the latest threat intelligence.

URL categories and reputations allow you to quickly create URL conditions for access control rules. For example, you could create an access control rule that identifies and blocks all High Risk URLs in the Abused Drugs category. If a user attempts to browse to any URL with that category and reputation combination, the session is blocked.

Using category and reputation data also simplifies policy creation and administration. It grants you assurance that the system will control web traffic as expected. Finally, because Cisco’s threat intelligence is continually updated with new URLs, as well as new categories and risks for existing URLs, you can ensure that the system uses up-to-date information to filter requested URLs. Malicious sites that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and deploy new policies.

Some examples include:

• If a rule blocks all gaming sites, as new domains get registered and classified as Gaming, the system can block those sites automatically.

• If a rule blocks all malware sites, and a blog page gets infected with malware, the system can recategorize the URL from Blog to Malware and block that site.

• If a rule blocks high-risk social networking sites, and somebody posts a link on their profile page that contains links to malicious payloads, the system can change the reputation of that page from Benign sites to High Risk and block it.

If the system does not know the category or reputation of a URL, browsing to that website does not trigger access control rules with category or reputation-based URL conditions. You cannot assign categories or reputations to URLs manually.

To supplement or selectively override URL filtering by category and reputation, you can control web traffic by manually specifying individual URLs, groups of URLs, or URL lists and feeds. This allows you to achieve granular, custom control over allowed and blocked web traffic. You can perform this type of URL filtering without a special license.

For example, you might block a category that mostly contains sites that are not appropriate for your organization. However, if the category contains a web site that is appropriate, and to which you want to provide access, you can create a manual allow rule for that site and place it before the block rule for the category.

Although manual filtering gives you precise control over allowed and blocked web traffic, you cannot qualify a manually specified URL with a reputation. Additionally, you must make sure that your rules do not have unintended consequences. To determine whether network traffic matches a URL condition, the system performs a simple substring match. If the requested URL matches any part of the string, the URLs are considered to match.

Therefore, when manually filtering specific URLs, carefully consider other traffic that might be affected. For example, if you allow all traffic to example.com, your users could browse to URLs including:

• http://example.com/

• http://example.com/newexample

• http://www.example.com/

As another example, consider a scenario where you want to explicitly block ign.com (a gaming site). However, substring matching means that blocking ign.com also blocks verisign.com, which might not be your intent.

Users see an HTTP response page if you block their session. You can either display a generic system-provided response page, or you can enter custom HTML.

When the system blocks a user’s HTTP web request, what the user sees in a browser depends on how you block the session, using the access control rule’s action. You should select:

• Block or Block with reset to deny the connection. A blocked session times out; the system resets Block with reset connections. However, for both blocking actions, you can override the default browser or server page with a custom page that explains that the connection was denied. The system calls this custom page an HTTP response page.

• Interactive Block or Interactive Block with reset if you want to display an interactive HTTP response page that warns users, but also allows them to click a button to continue or refresh the page to load the originally requested site. Users may have to refresh after bypassing the response page to load page elements that did not load.

In each access control policy, you configure the interactive HTTP response page separately from the response page you use to block traffic without interaction, that is, using a Block rule. For example, you could display the system-provided page to users whose sessions are blocked without interaction, but a custom page to users who can click to continue.

Response pages do not appear when web traffic is blocked:

• by a Security Intelligence blacklist, and the session was originally encrypted; this includes encrypted connections blocked by the SSL inspection feature, as well as decrypted and encrypted traffic that matches a Block or Interactive Block access control rule

• as a result of a promoted access control rule, after a connection has been established and allowed to flow for a few packets so the system can inspect it for requested URLs and application details