Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
2416
Views
20
Helpful
1
Comments

Deploying ASA with CX module as a Cisco Cloud Web Security (CWS) Connector

csaxena
Cisco Employee
Cisco Employee

‎06-26-2014 08:19 AM - edited ‎03-08-2019 06:55 PM

Introduction

This document describes how to use Cisco Adaptice Security Appliance (ASA) with Context Aware (CX) module, also termed as Next Generation firewall, and Cisco Cloud Web Security (CWS) Connector.

 

Components Used / Scope

This example shows the following areas of technology and products:

  1. Cisco ASA 5500-X Series Adaptive Security Appliances provides internet edge firewall security and intrusion prevention.
  2. Cisco Cloud Web Security provides granular control over all web content that is accessed.

Use Case

ASA CX module has the capability to support both Content Security and Intrution Prevention requirement depending on the license features enabled on ASA-CX. Cloud Web Security is not supported with the ASA CX module. If you configure both the ASA CX action and Cloud Web Security inspection for the same traffic flow, the ASA only performs the ASA CX action. In order to leverage the CWS features for Web Security, we need to ensure the traffic is bypassed in the match statement for ASA CX. Typically, in such a scenario, customers will use CWS for Web Security and AVC (port 80 and 443) and CX module for all other ports.

 

Pre-requisites

  1. 3DES/AES License on ASA (Free license)
  2. Valid CWS service / License to use CWS for the required number of users
  3. Access to ScanCenter Portal to generate the Authentication Key

Key Understanding

  1. The match default-inspection-traffic command does not include the default ports for the Cloud Web Security inspection (80 and 443).
  2. Actions are applied to traffic bidirectionally or unidirectionally depending on the feature. For features that are applied bidirectionally, all traffic that enters or exits the interface to which you apply the policy map is affected if the traffic matches the class map for both directions. When you use a global policy, all features are unidirectional; features that are normally bidirectional when applied to a single interface only apply to the ingress of each interface when applied globally. Because the policy is applied to all interfaces, the policy will be applied in both directions so bidirectionality in this case is redundant.
  3. For TCP and UDP traffic (and ICMP when you enable stateful ICMP inspection), service policies operate on traffic flows, and not just individual packets. If traffic is part of an existing connection that matches a feature in a policy on one interface, that traffic flow cannot also match the same feature in a policy on another interface; only the first policy is used.
  4. Interface service policies take precedence over the global service policy for a given feature.
  5. The maximum number of policy maps is 64, but you can only apply one policy map per interface.

Network Diagram

network diagram

 

Traffic Flow for ASA & CWS

  1.  User requests URL via the web browser
  2. Traffic is sent to ASA to go out the internet. ASA performs required NAT and based on the protocol HTTP/HTTPS, matches to inside interface policy and gets redirected to Cisco CWS.
  3. CWS analyzes the request based on the configuration done in the ScanCenter portal and if policy permits, forwards the request to to approved  sites
  4. CWS inspects the returned traffic and redirects the same to ASA
  5. Based on the session flow maintained, ASA sends traffic back to all users

 

Traffic Flow for ASA & CX

  1. All traffic other than HTTP and HTTPS, is configured to match ASA CX for inspection and is redirected to CX over the ASA backplane
  2. ASA CX inspects traffic based on the policies configured and takes required allow/block/alert action

 

Configuration

  • Access list to match all internet bound web (tcp/80) traffic and exclude all internal traffic
!ASA CWS HTTP Match
access-list cws-www extended deny ip any4 10.0.0.0 255.0.0.0 
access-list cws-www extended deny ip any4 172.16.0.0 255.240.0.0 
access-list cws-www extended deny ip any4 192.168.0.0 255.255.0.0 
access-list cws-www extended permit tcp any4 any4 eq www
  •  Access list to match all internet bound https (tcp/443) traffic and exclude all internal traffic 
!ASA CWS HTTPS Match
access-list cws-https extended deny ip any4 10.0.0.0 255.0.0.0 
access-list cws-https extended deny ip any4 172.16.0.0 255.240.0.0 
access-list cws-https extended deny ip any4 192.168.0.0 255.255.0.0 
access-list cws-https extended permit tcp any4 any4 eq https
  •  Access list to match all internal traffic, exclude all internet bound Web & HTTPS traffic and all other ports
!ASA CX Match
access-list asa-cx extended permit tcp any4 10.0.0.0 255.0.0.0 eq 80  
access-list asa-cx extended permit tcp any4 172.16.0.0 255.240.0.0 eq 80 
access-list asa-cx extended permit tcp any4 192.168.0.0 255.255.0.0 eq 80
access-list asa-cx extended deny tcp any4 any4 eq www 
access-list asa-cx extended permit tcp any4 10.0.0.0 255.0.0.0 eq 443   
access-list asa-cx extended permit tcp any4 172.16.0.0 255.240.0.0 eq 443  
access-list asa-cx extended permit tcp any4 192.168.0.0 255.255.0.0 eq 443
access-list asa-cx extended deny tcp any4 any4 eq https 
access-list asa-cx extended permit ip any4 any4
  • Class Map configuration to match traffic for both CWS and CX
! Match HTTPS traffic for CWS
class-map cmap-https
 match access-list cws-https

! Match HTTP traffic for CWS
class-map cmap-http
 match access-list cws-www

! Match traffic for ASA CX
class-map cmap-ngfw-cx
 match access-list asa-cx
  • Policy Map configuration to associate actions with class maps created above
!Inspection policy map to configure essential parameters for the rules and optionally !identify the whitelist for HTTP traffic
policy-map type inspect scansafe http-pmap
 parameters
  default group cws_default
  http

!Inspection policy map to configure essential parameters for the rules and optionally !identify the whitelist for HTTPS traffic
policy-map type inspect scansafe https-pmap
 parameters
  default group cws_default
  https

! Interface policy local to Inside Interface
policy-map cws_policy
 class cmap-http
  inspect scansafe http-pmap fail-open 
 class cmap-https
  inspect scansafe https-pmap fail-open 

! Global Policy with Inspection enabled using ASA CX 
policy-map global_policy
 class inspection_default
 <SNIP>
 class cmap-ngfw-cx
  cxsc fail-open
 class class-default
  user-statistics accounting
  •  Activate policy globally for CX and CWS on the interface.
service-policy global_policy global
service-policy cws_policy inside

[Note: In this example, we have assumed web traffic to originate only from inside security zone. We can use interface policies on all interfaces where we expect web traffic or use the same classes within the global policy. This is just to demonstrate the functioning of CWS and use of MPF to support our requirement]

 

  • Enable CWS on ASA (no difference)
scansafe general-options
 server primary ip x1.x1.x1.x1 port 8080
 server backup ip x2.x2.x2.x2 port 8080
 retry-count 5
 license xxxxxxxxxxxx/ encrypted
!

 

To ensure that all connections use the new policy, you need to disconnect the current connections so they can reconnect using the new policy. See the clear conn or clear local-host commands.

 

Verify

 

  • Use the command "show scansafe statistics" to verify the service to be enabled and ASA redirecting traffic. Subsequent tries will show increment in session counts, current sessions and bytes transfered  
    csaxena-cws-asa# sho scansafe statistics 
Current HTTP sessions : 0
Current HTTPS sessions : 0
Total HTTP Sessions : 1091
Total HTTPS Sessions : 5893
Total Fail HTTP sessions : 0
Total Fail HTTPS sessions : 0
Total Bytes In : 473598 Bytes
Total Bytes Out : 1995470 Bytes
HTTP session Connect Latency in ms(min/max/avg) : 10/23/11
HTTPS session Connect Latency in ms(min/max/avg) : 10/190/11
  • Use the command "show service-policy" to see the increments in packets inspected
csaxena-cws-asa# show service-policy         
Global policy: 
  Service-policy: global_policy
    Class-map: inspection_default
     <SNIP>
     <SNIP>
    Class-map: cmap-ngfw-cx
      CXSC: card status Up, mode fail-open, auth-proxy disabled
        packet input 275786624, packet output 272207060, drop 0, reset-drop 36, proxied 0
    Class-map: class-default
      Default Queueing	Packet recieved 150146, sent 156937, attack 2031

Interface inside:
  Service-policy: cws_policy
    Class-map: cmap-http
      Inspect: scansafe http-pmap fail-open, packet 176, lock fail 0, drop 0, reset-drop 0, v6-fail-close 0
    Class-map: cmap-https
      Inspect: scansafe https-pmap fail-open, packet 78, lock fail 0, drop 13, reset-drop 0, v6-fail-close 0

 

Troubleshoot  

 

In order to troubleshoot any issues related to the above configuration and to understand the packet flow :

csaxena-cws-asa(config)# packet-tracer input inside tcp 10.0.0.1 80 1.1.1.1 80 det

Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Config:
Additional Information:
<SNIP>
<This phase will show up if you are capturing same traffic as well>

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  <SNIP>

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         via x.x.x.1, outside
<Confirms egress interface selected. We need to ensure we have CWS connectivity via the same interface>

Phase: 4
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in   10.0.0.0        255.255.254.0   via 10.0.0.0.1, inside

Phase: 5
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_in in interface inside
access-list inside_in extended permit ip any any 
Additional Information:
<SNIP>

Phase: 6
Type: NAT
Subtype: 
Result: ALLOW
Config:
object network obj-inside_to_outside
 nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 10.0.0.1/80 to x.x.x.1/80
 Forward Flow based lookup yields rule:
 in <SNIP>

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in <SNIP>

Phase: 8
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  <SNIP>

Phase: 9
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map cmap-http
 match access-list cws-www
policy-map inside_policy
 class cmap-http
  inspect scansafe http-pmap fail-open 
service-policy inside_policy interface inside
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fff2cd3fce0, priority=72, domain=inspect-scansafe, deny=false
	hits=8, user_data=0x7fff2bb86ab0, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
	src ip/id=10.0.0.11, mask=255.255.255.255, port=0, tag=0
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, tag=0, dscp=0x0
	input_ifc=inside, output_ifc=any
<Verify the configuration, port, domain, deny fields>

Phase: 10
Type: CXSC
Subtype: 
Result: ALLOW
Config:
class-map ngfw-cx
 match access-list asa-cx
policy-map global_policy
 class ngfw-cx
  cxsc fail-open
service-policy global_policy global
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fff2c530970, priority=71, domain=cxsc, deny=true
	hits=5868, user_data=0x7fff2c931380, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, tag=0, dscp=0x0
	input_ifc=inside, output_ifc=any

Phase: 11
Type: 
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out <SNIP>

Phase: 12
Type: 
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out <SNIP>

Phase: 13
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out <SNIP>
<In this example, IDFW is not configured>

Phase: 14
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  <SNIP>

Phase: 15
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in <SNIP>

Phase: 16
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 out <SNIP>

Phase: 17
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 3855350, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_inline_tcp_mod
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_inline_tcp_mod
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

 

Related Infomration   

Labels:
Comments
deeshar22
Community Member
‎11-19-2014 08:53 AM

Very Helpful document ...Thanks !!!

Getting Started

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:

Customers Also Viewed These Support Documents