Goal:
To be able to configure an ISR for content-scan so HTTP and HTTPS requests will be sent out to the scansafe towers and depending on the response received, users will either be allowed or denied loading the sites.
Documentation:
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps6538/ps6540/data_sheet_c78-655324.html
Prerequisite:
ISR should be running a minimum code version 15.2(1)T1 or above.
Available in IOS (universal) images with security feature set (SEC) license.
Platform Supported:
800, 1900, 2900 and 3900 series ISRs
Platforms NOT Supported:
G1's 18xx, 28xx, 38xx
Limitation:
The maximum number of sessions that can be handled is 32K, irrespective of platform.
Step by Step:
Configure the parameter-map (required):
parameter-map type content-scan global
server scansafe primary ipv4 80.254.146.211 port http 8080 https 8080
server scansafe secondary ipv4 80.254.145.147 port http 8080 https 8080
license 0 <license key>
user-group ciscogroup username ciscouser
source interface g0/0
The license key here is actually called an authentication key that you get for your site (one per company) from scan safe. Depending on the geographical location of the sites, scansafe provides the tower IP addresses. One is the primary and the other is the secondary tower. When one goes down the other one automatically takes over.
In this case the router when proxying the HTTP and HTTPS requests to scansafe towers, it will use the g0/0 interface IP for the source of those packets.
If the router has multiple internet facing interfaces or route tracking enabled, either of the interfaces may be the active interface. In that case, it is may be a good idea to source the traffic from a loopback interface or from the inside interface for which either this router or another device should provide translation if the ip address used is an RFC 1918 address space.
User-group is optional. Based on the policies setup on the tower, end users will be filtered and scanned for content.
Apply content-scan to the egress interface (required):
interface g0/2
content-scan out
Whitelisting (optional):
One could use ACL, parameter-map type regex for whitelisting purpose
parameter-map type regex allowed-pattern
pattern cisco
pattern aol
You can exempt traffic from this internal subnet from being sent out to the towers. These IPs can browse freely without any restrictions.
ip access-list extended inside-nw
permit ip 192.168.10.0 0.0.0.255 any
content-scan whitelisting
whitelist notify-tower
whitelist header host regex allowed-pattern
whitelist acl inside-nw
Show commands:
Verify the scansafe towers:
kusankar-881#sh content sum
Primary: 70.39.231.19 (Up)*
Secondary: 80.254.156.99 (Up)
Interfaces:
The "*" next to the IP address shows that the 70.39.231.19 primary tower and the 80.254.156.99 is the secondary tower.
Quick Statistics:
kusankar-881#sh content-scan statistics
Current HTTP sessions: 28
Current HTTPS sessions: 1
Total HTTP sessions: 51540
Total HTTPS sessions: 358
White-listed sessions: 12150
Time of last reset: never
Checking active connections:
kusankar-881#sh content-scan session active
Protocol Source Destination Bytes Time
HTTP 172.16.1.4:2361 205.188.60.65:80 (6649:1565) 00:00:47
URI: b.aol.com
Username/usergroup(s): /
HTTP 172.16.1.4:2377 72.14.204.120:80 (436:346) 00:00:11
URI: ssl.gstatic.com
Username/usergroup(s): /
HTTP 172.16.1.4:2378 74.125.113.106:80 (1389:355) 00:00:11
URI: www.google.com
Username/usergroup(s): /
HTTP 172.16.1.4:2379 74.125.113.106:80 (1393:355) 00:00:11
URI: www.google.comDebugs:
debug content-scan events
debug ontent-scan packet path
debug content-scan errors
debug l4f packet all
