Local Content Filtering in Cisco IOS

Additional Resources
By Ivan Pepelnjak

IOS release 12.4(20)T introduced support for web content filtering based on Trend Micro URL
filtering service. This feature allows the routers to intercept HTTP requests, perform deep packet
inspection (DPI) and query the Trend Micro server to determine whether an HTTP request
should be allowed or blocked. A subset of this feature allows a router to perform local content
filtering without contacting an external filtering service.

IOS Content Filtering (or any other DPI technique) cannot examine HTTPS (HTTP over
SSL/TLS) sessions.

Other IOS features, including Modular QoS CLI and Network Based Application Recognition
support HTTP DPI, but these features can only block access to the target server. IOS Content
Filtering can intercept a transit HTTP session and return alternate content to the end-user (see
Figure 1).

Figure 1: Sample "URL is blocked" page returned by a router

This article contains a step-by-step explanation of a working Cisco IOS Content Filtering
configuration implemented on a firewall router connecting a LAN to an FTTB service.
If you’re familiar with the NAT and zone-based firewall configuration, go directly to the content
filtering configuration section.
Contents
[hide]

• 1 IP addressing and generic configuration commands

• 2 Zone-based firewall configuration
• 3 Content filtering configuration
o 3.1 Defining the patterns
o 3.2 Filtering classes
o 3.3 Content filtering policy
o 3.4 Applying the URL filtering policy
o 3.5 URL filtering policy parameters
• 4 Monitoring the local content filtering
o 4.1 HTTP request logging
• 5 Complete router configuration

• 6 Additional Resources

IP addressing and generic configuration commands

The gateway router has two Fast Ethernet interfaces. The inside interface uses an IP subnet from
the private IP address range, the IP address of the outside interface is assigned via DHCP. The
router uses NAT with overload on the outside interface to translate the source address of all
outbound into the IP address assigned by the Service Provider’s DHCP server.

IP addressing configuration

ip domain name example.com

!
interface Loopback0
ip address 10.17.0.20 255.255.255.255
!
interface FastEthernet0/0
description Outside interface
ip address dhcp
ip nat outside
ip virtual-reassembly
!
interface FastEthernet0/1
description Inside LAN
ip address 10.17.0.1 255.255.255.240
ip nat inside
ip virtual-reassembly
!
ip nat inside source list Inside interface FastEthernet0/0 overload
!
ip access-list standard Inside
permit 10.17.0.0 0.0.0.255

No routing protocols are used; the router gets the default route from the DHCP server:

IP routing table on the gateway router

rtr>show ip route | begin Gateway

Gateway of last resort is 192.168.200.193 to network 0.0.0.0

192.168.200.0/28 is subnetted, 1 subnets

C 192.168.200.192 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.17.0.20/32 is directly connected, Loopback0
C 10.17.0.0/28 is directly connected, FastEthernet0/1
S* 0.0.0.0/0 [254/0] via 192.168.200.193

Zone-based firewall configuration

IOS content filtering is configured as a service-policy attached to a class that matches HTTP
protocol within the zone-based firewall configuration framework. To deploy IOS content
filtering, you have to configure the zone-based firewall with at least two zones.

In the sample configuration, we’ll configure two zones: Inside and Outside. The inter-zone
policy is simple: HTTP, HTTPS, DNS and ICMP can pass from the Inside zone to the Outside
zone. The inspect configuration option configures stateful inspection of these protocols. No
unsolicited traffic is permitted from the Outside zone to the Inside zone.

The zone-based firewall configuration shown in this article is not complete, as it does not protect
the router (the self zone). In-depth information on the zone-based firewall configuration can be
found in the Deploying Zone-Based Firewalls e-book published by Cisco Press.

The zone-based firewall configuration starts with the class-map configurations defining security-
relevant traffic classes:

Traffic inspection classes

class-map type inspect match-any Control

match protocol dns
match protocol icmp
class-map type inspect match-any Web
 match protocol http
class-map match-all SecureWeb
match protocol secure-http
class-map type inspect match-all WebSecure
match protocol https

After the traffic classes have been defined, you can configure a policy-map defining an inter-
zone security policy. The security policy allows outbound HTTP, DNS, ICMP and HTTPS
sessions and drops all other outbound traffic.

Security policy

policy-map type inspect InsideToOutside

class type inspect Web
inspect
class type inspect Control
inspect
class type inspect WebSecure
inspect
class class-default
drop

Next, the zones are defined:

Security zones

zone security Inside

zone security Outside

The zone-pair definition ties together a source zone, a destination zone and a security policy
defining the traffic inspection/filtering between the pair of zones. The outside-to-inside zone pair
is not defined; all unsolicited traffic from the Outside zone to the Inside zone is thus dropped.

Security policy is applied to a pair of zones

zone-pair security Inside_to_Outside source Inside destination Outside

service-policy type inspect InsideToOutside

As the final configuration step, individual interfaces are assigned to the security zones.

Interfaces are assigned to the Inside and Outside zones

interface FastEthernet0/0
description Outside interface
ip address dhcp
ip nat outside
ip virtual-reassembly
zone-member security Outside
!
interface FastEthernet0/1
description Inside LAN
 ip address 10.17.0.1 255.255.255.240
ip nat inside
ip virtual-reassembly
zone-member security Inside

Content filtering configuration

The content filtering configuration is performed in these steps:

1. Define the patterns you want to match using a new parameter-map type urlf-glob
object.
2. Define URL filtering classes with the class-map type urlfilter.
3. Define URL filtering policies with the policy-map type inspect urlfilter. You can allow
or reset individual classes within the policy and (optionally) log their usage.
4. Apply the URL filtering policy as a child policy to the zone-based firewall security
policy.
5. Optionally, change the parameters of the content filtering functionality with the
parameter-map type urlfpolicy local.

Defining the patterns

The content filtering feature has introduced yet another pattern matching object – the
parameter-map type urlf-glob with the following syntax:

Content filtering pattern definition syntax

parameter-map type urlf-glob ''name''

pattern ''glob-pattern''

The content filtering patterns are glob patterns, not regular expressions. They have only two
special characters: * matches any number of characters and ? matches a single character.
Numerous patterns can be listed in the same parameter-map; any one of them can match.

The sample configuration matches two social networking sites (LinkedIn and Facebook). It also
contains a wildcard match that will be used to permit all other sites.

Sample pattern matching configuration

parameter-map type urlf-glob Facebook

pattern facebook.com
pattern *.facebook.com
!
parameter-map type urlf-glob LinkedIn
pattern *.linkedin.com
pattern linkedin.com
!
parameter-map type urlf-glob PermittedSites
pattern *
When used to match server names, the URL filter parameter maps have to match the whole
server name. You have to use pattern *.example.com and pattern example.com in the same
parameter map if you want to match http://example.com as well as http://www.example.com.

Filtering classes

The content filtering feature uses its own class type (type urlfilter). The matching logic is the
same as in other IOS classes: a class can match any (match-any) or all (match-all) match
conditions specified in the class. The URL filter classes support two match conditions:

• match server-domain matches the Host header of HTTP request. All RFC 2616-
compliant browsers (Cisco IOS is not one of them) set the Host header to the server name
(the part of the URL between http:// and the next slash).

The specified pattern has to match the whole server name. For example, pattern facebook.com
will not match www.facebook.com.

• match url-keyword matches the URL passed in the GET or POST request. Unless the
browser is using an HTTP proxy, the server name is not part of the URL.

In IOS release 12.4(24)T, the URL filter classes do not support class hierarchies (a class cannot
be member of another class).

The sample configuration defines two classes: social networking sites (which will be blocked)
and the rest of the internet (permitted sites).

Sample filtering classes

class-map type urlfilter match-any SocialNetworking

match server-domain urlf-glob Facebook
match server-domain urlf-glob LinkedIn
!
class-map type urlfilter match-any PermittedSites
match server-domain urlf-glob PermittedSites

Content filtering policy

After the URL filtering classes have been defined, you can define a filtering policy. The policy
configuration syntax is very similar to the Modular QoS policy or zone-based firewall policy
configuration with a few minor differences:

• Only the URL filter classes can be used in the URL filtering policy.
• You have to configure allow or reset action in each class.
• You might configure the log action to write the filtering results to the syslog.
• You might configure a parameter map in the filtering policy.
The sample filtering policy blocks access to social networking sites and allows access to all
permitted sites.

If you’re using local content filtering with no external server, any requests not explicitly matched
by a class with the allow action will be blocked. If you want to block a few sites, you have to
have an explicit permit all at the end of the policy-map.

Sample URL filtering policy

policy-map type inspect urlfilter SocialNetworking

class type urlfilter SocialNetworking
log
reset
class type urlfilter PermittedSites
allow
log

Applying the URL filtering policy

You have to apply the URL filtering policy as a child policy (with the service-policy urlfilter
configuration command) of a zone-based firewall class which matches HTTP traffic (no other
traffic can be matched by that class).

In the sample configuration, the SocialNetworking URL filtering policy is applied within the
Web class of the InsideToOutside security policy.

Applying the URL filtering policy to a zone-based firewall security policy

policy-map type inspect InsideToOutside

class type inspect Web
inspect
service-policy urlfilter SocialNetworking
class type inspect Control
inspect
class type inspect WebSecure
inspect
class class-default
drop

URL filtering policy parameters

The URL filtering policy accepts a few parameters that have to be configured in yet another
object: the parameter-map type urlfpolicy. For local content filtering, you have to use the
parameter-map type urlfpolicy local (you could also specify parameters for N2H2 and
Websense servers). The only meaningful parameter in the purely-local scenario is the block-
page parameter which can specify an URL to which the blocked requests are redirected or a text
message to be included in the “content is blocked” web page generated by the router.

Sample local URL filtering parameters

parameter-map type urlfpolicy local URLFilter
alert off
block-page message "Don't even try to go there"

The URL filtering policy parameters are applied to the URL filtering policy with the parameter
type urlfpolicy policy map configuration command.

Each URL filtering policy could have its own set of parameters. To customize the filtering
behavior, you might have multiple HTTP-based classes in the same policy-map or use different
URL filtering policies in individual inter-zone security policies.

Monitoring the local content filtering

The show class-map type urlfilter and show policy-map type inspect urlfilter commands can
be used to display the contents of individual URL filtering classes and policies.

URL filtering classes on the test router

rtr#show class-map type urlfilter

Class Map type urlfilter match-any SocialNetworking (id 1)
Match server-domain urlf-glob Facebook
Match server-domain urlf-glob LinkedIn

Class Map type urlfilter match-any PermittedSites (id 2)

Match server-domain urlf-glob PermittedSites

URL filtering policy on the test router

rtr#show policy-map type inspect urlfilter

Policy Map type inspect urlfilter SocialNetworking
Parameter URLFilter
Class SocialNetworking
log
reset
Class PermittedSites
allow
log

The local pattern matching parameter maps and URL filtering policy parameter maps can be
display with the show parameter-map type urlf-glob|urlfpolicy command.

URL filtering related parameter maps on the test router

rtr#show parameter-map type urlf-glob

parameter-map type urlf-glob Facebook
pattern facebook.com
pattern *.facebook.com

parameter-map type urlf-glob LinkedIn

pattern linkedin.com
pattern *.linkedin.com
parameter-map type urlf-glob PermittedSites
pattern *

rtr#show parameter-map type urlfpolicy local

parameter map type urlfpolicy local URLFilter
alert off
allow-mode off
block-page message "Don't even try to go there"

The show policy-map type inspect zone-pair urlfilter command displays the operational
parameters and counters of the IOS content filtering. Its outputs are very similar to the show
policy-map type inspect zone-pair command; the only addition are the server-based filtering
counters and statistics (highlighted below).

rtr#show policy-map type inspect zone-pair urlfilter

policy exists on zp Inside_to_Outside

Zone-pair: Inside_to_Outside

Service-policy inspect : InsideToOutside

Class-map: Web (match-any)

Match: protocol http
144 packets, 5720 bytes
30 second rate 0 bps

Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [51:4054]

Session creations since subsystem startup or last reset 139

Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [14:3:8]
Last session created 00:53:15
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 52
Last half-open session total 0

URL Filtering is in ALLOW_MODE

Current requests count: 0

Current packet buffer count(in use): 0
Maxever request count: 0
Maxever packet buffer count: 0
Total cache hit count: 0
Total requests sent to URL Filter Server :0
Total responses received from URL Filter Server :0
Total error responses received from URL Filter Server :0
Total requests allowed: 0
Total requests blocked: 0
1min/5min Avg Round trip time to URLF Server: 0/0 millisecs
1min/5min Minimum round trip time to URLF server: 0/0 millisecs
1min/5min Maximum round trip time to URLF server: 0/0 millisecs
 Last req round trip time to URLF Server: 0 millisecs

HTTP request logging

To monitor the blocked or allowed HTTP requests, use the log action in the URL filtering policy.
Whenever a HTTP request matching a class with the log action is processed, the router generates
a syslog message. Sample allow and block messages are included below:

%URLF-6-SITE_ALLOWED: (target:class)-(Inside_to_Outside:Web): →
Client 10.17.0.2:46598 accessed server 88.221.36.170:80
%URLF-4-SITE_BLOCKED: (target:class)-(Inside_to_Outside:Web): →
Access denied for the site 'www.linkedin.com', client 10.17.0.2:46600
server 88.221.36.170:80

Complete router configuration

The complete configuration of the test router is included in the following printout

version 12.4
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname rtr
!
logging message-counter syslog
enable secret 5 $1$l./Y$D2OnN1MW/M3UzJQjHmAcK/
!
no aaa new-model
no ip source-route
ip cef
!
!
!
!
ip domain name example.com
!
parameter-map type urlfpolicy local URLFilter
alert off
block-page message "Don't even try to go there"
!
parameter-map type urlf-glob Facebook
pattern facebook.com
pattern *.facebook.com
!
parameter-map type urlf-glob LinkedIn
pattern *.linkedin.com
pattern linkedin.com
!
parameter-map type urlf-glob PermittedSites
pattern *
!
file prompt quiet
archive
log config
hidekeys
path disk0:configs
!
ip ssh logging events
ip ssh version 2
!
class-map type urlfilter match-any SocialNetworking
match server-domain urlf-glob Facebook
match server-domain urlf-glob LinkedIn
class-map type urlfilter match-any PermittedSites
match server-domain urlf-glob PermittedSites
!
class-map type inspect match-any Control
match protocol dns
match protocol icmp
class-map type inspect match-any Web
match protocol http
class-map match-all SecureWeb
match protocol secure-http
class-map type inspect match-all WebSecure
match protocol https
!
!
policy-map type inspect urlfilter SocialNetworking
parameter type urlfpolicy local URLFilter
class type urlfilter SocialNetworking
log
reset
class type urlfilter PermittedSites
allow
log
!
policy-map type inspect InsideToOutside
class type inspect Web
inspect
service-policy urlfilter SocialNetworking
class type inspect Control
inspect
class type inspect WebSecure
inspect
class class-default
drop
!
zone security Inside
zone security Outside
!
zone-pair security Inside_to_Outside source Inside destination Outside
service-policy type inspect InsideToOutside
!
!
interface Loopback0
ip address 10.17.0.20 255.255.255.255
!
interface FastEthernet0/0
description Outside interface
 ip address dhcp
ip nat outside
ip virtual-reassembly
zone-member security Outside
duplex auto
speed auto
no cdp enable
!
interface FastEthernet0/1
description Inside LAN
ip address 10.17.0.1 255.255.255.240
ip nat inside
ip virtual-reassembly
zone-member security Inside
duplex auto
speed auto
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip nat inside source list Inside interface FastEthernet0/0 overload
!
ip access-list standard Inside
permit 10.17.0.0 0.0.0.255
!
snmp-server community Test RO
snmp-server ifindex persist
snmp mib persist cbqos
!
control-plane
!
gatekeeper
shutdown
!
line con 0
exec-timeout 0 0
privilege level 15
stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 0 0
privilege level 15
login local
!
end