01-28-2013 08:54 AM - edited 03-08-2019 06:48 PM
This configuration example is meant to be interpreted with the aid of the official documentation from the configuration guide located here:
The ASA must be running minimum 9.0 code or above to be able to configure ScanSafe feature.
1. IPV6 is not supported
2. Transparent mode is not supported
3. ASA clustering is not supported
4. Clientless SSL VPN is not supported
5. Cloud Web Security is not supported with the ASA CX module
6.The match default-inspection-traffic command does not include the default ports for the Cloud Web Security inspection (80 and 443).
1. Client PC tries to go to linkedin.com
2. This request is received by the ASA and it optionally retrieves the user and/or group information
3. ASA redirects the request to the Scan Safe Towers.
4. ASA acts as a proxy, changes the destination IP address and port in the client requests and adds tower specific HTTP headers and then sends the modified request to the Towers.
5. Based on the policies configured on the Tower, the reqeust is allowed or a blocked page is sent to the client PC.
scansafe general-options
server primary fqdn proxy193.scansafe.net port 8080
server backup fqdn proxy1363.scansafe.net port 8080
retry-count 5
license <license key>
access-list http-traffic extended permit tcp any any eq www
access-list https-traffic extended permit tcp any any eq https
class-map http-class
match access-list http_traffic
class-map https-class
match access-list https_traffic
class-map type inspect scansafe match-any whitelist1
match user user1 group cisco
match user user2
match group group1
match user user3 group group3
policy-map type inspect scansafe http-pmap
parameters
default group httptraffic
http
class whitelist1
whitelist
policy-map type inspect scansafe https-pmap
parameters
default group httpstraffic
https
class whitelist1
whitelist
policy-map inside-policy
class http-class
inspect scansafe http-pmap fail-close
class https-class
inspect scansafe https-pmap fail-close
service-policy inside-policy interface inside
scansafe general-options
server primary fqdn proxy193.scansafe.net port 8080
server backup fqdn proxy1363.scansafe.net port 8080
retry-count 5
license <license key>
!
access-list http-traffic extended permit tcp any any eq www
access-list https-traffic extended permit tcp any any eq https
!
class-map http-class
match access-list http_traffic
class-map https-class
match access-list https_traffic
!
policy-map type inspect scansafe http-pmap
parameters
default group httptraffic
http
class whitelist1
whitelist
policy-map type inspect scansafe https-pmap
parameters
default group httpstraffic
https
class whitelist1
whitelist
!
policy-map inside-policy
class http-class
inspect scansafe http-pmap fail-close
class https-class
inspect scansafe https-pmap fail-close
!
service-policy inside-policy interface inside
1. show scansafe server
ASA# sh scansafe server
Primary: 70.39.176.3 (REACHABLE)*
Backup: 70.39.231.99
2. debug scansafe 255
Great config!
Important note to others (as this happened to us): When you apply the service-policy called "inside-policy" on the inside interface, it will replace the default policy. (the one with a global class, inspecting ftp and other protocols)
A quick fix to this is to simply add the global-class inspections to the newly created "inside-policy"(otherwise things like ftp would break..trim down as needed.):
policy-map inside-policy
class http-class
inspect scansafe http-pmap fail-close
class https-class
inspect scansafe https-pmap fail-close
class global-class
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect xdmcp
inspect dns dynamic-filter-snoop
To add the to access-list configs: If there are http/https destinations in which you do NOT want redirected (such as intranet websites or other speciatly cloud apps that don't play nice with a proxy), you can modify the access lists to include deny statements (effectively, denying redirection, so it routes as normal):
access-list http-traffic remark Do not redirect internal web servers
access-list http-traffic extended deny tcp any object-group internal-web-servers eq www
access-list http-traffic remark Ignore traffic sourced from another internal proxy
access-list http-traffic extended deny tcp host 10.10.10.1 any eq www
access-list http-traffic extended permit tcp any any eq www
access-list https-traffic extended permit tcp any any eq https
I also included an example to deny a source, which would be useful if you currently have a proxy appliance that clients are being redirected to. The current proxy could be ignored, and clients could be gradually moved from the old to the new scan safe redirection. The deny statements should be replicated to the https-traffic ACL as needed.
Hello,
May I ask if there is need to configure the VPN tunnel between ASA acting as proxy for http/https traffic and the ScanSafe towers?
Thank you.
Hello,
Yes, two SSL tunnels leading to two CWS towers are configured as part of establishing communication from ASA to CWS cloud.
These tunnel are not regular SSL VPN tunnels. They are configured using CWS commands on ASA.
Regards,
Tomas
I am running into a problem with ACL whitelisting internal websites:
access-list scansafe-http extended deny tcp any 192.168.253.0 255.255.255.0 eq www
access-list scansafe-http extended permit tcp any any eq www
access-list scansafe-https extended deny tcp any 192.168.253.0 255.255.255.0 eq https
access-list scansafe-https extended permit tcp any any eq https
and I can see the drops the policy:
Global policy:
Service-policy: global_policy
Class-map: inspection_default
Class-map: http-class
Inspect: scansafe http-pmap fail-open, packet 6667, lock fail 0, drop 0, reset-drop 0, v6-fail-close 0
Number of whitelisted connections: 0
Number of connections allowed without scansafe inspection because of "fail-open" config: 0
Number of connections dropped because of "fail-close" config: 0
Number of HTTP connections inspected: 179
Number of HTTPS connections inspected: 0
Number of HTTP connections dropped because of errors: 0
Number of HTTPS connections dropped because of errors: 0
Class-map: https-class
Inspect: scansafe https-pmap fail-open, packet 40703, lock fail 0, drop 6, reset-drop 19, v6-fail-close 0
Number of whitelisted connections: 0
Number of connections allowed without scansafe inspection because of "fail-open" config: 0
Number of connections dropped because of "fail-close" config: 0
Number of HTTP connections inspected: 0
Number of HTTPS connections inspected: 616
Number of HTTP connections dropped because of errors: 0
Number of HTTPS connections dropped because of errors: 0
any clue as to why this is happening ? the traffic is kept on the ASA, i.e. source is on the "inside" and destination is on "DMZ".
config:
class-map http-class
match access-list scansafe-http
class-map https-class
match access-list scansafe-https
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect scansafe https-pmap
parameters
https
policy-map type inspect scansafe http-pmap
parameters
http
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect ftp
inspect icmp
inspect icmp error
class http-class
inspect scansafe http-pmap fail-open
class https-class
inspect scansafe https-pmap fail-open
class class-default
user-statistics accounting
!
Did you ever figure out why it wasn't bypassing internal servers?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: