The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter provides an overview of the configuration used in testing to validate the functionality of the Cisco WSA. This chapter is not intended to provide step-by-step procedures to configure the Cisco WSA because of the variability in network architectures and the potential impact on device configuration. However, this chapter discusses specific items related to FactoryTalk applications, their interaction with the Cisco WSA, and the steps required to help ensure that they will interoperate with the Cisco WSA and efficiently complete their functions.
From an out-of-box state, the most efficient way to complete the setup of the Cisco WSA is to use the System Setup Wizard. While this design guide does not describe in detail the System Setup Wizard, it does provide important information to be aware of during this phase of Cisco WSA deployment. Important items from the System Setup Wizard that affect the functionality of the Cisco WSA and FactoryTalk Applications are defined in the sections following Table 3-1 .
Note When you use the Web Security Appliance in a network that contains another proxy server, it is recommended that you place the Web Security Appliance downstream from the proxy server, closer to the clients. A system with multiple proxies was not tested and validated as a part of this design guide.
You can use the host name specified here when connecting to the appliance management interface (or in browser proxy settings if M1 [Management] is used for proxy data), but you must register it in your organization’s DNS.
Note If you enable “Use M1 port for management only”, this configuration section will have separate configuration options for management and data traffic; otherwise one joint configuration section will be shown.
Note By default, the Cloud Connector is deployed in transparent mode, which requires a connection to a Layer 4 switch or a version 2 WCCP router. The version 2 WCCP router was tested and validated as a part of this design guide.
The Cisco WSA that was tested and validated was configured in a dual-homed type of architecture (Figure 3-1). Overall three interfaces and IP addresses were dedicated to the device:
This is intended for management of the Cisco WSA only and should be out-of-band.
This interface resides in the same subnet as the firewall interface in the Industrial Zone and should be Layer 2 accessible from the IDMZ firewall. All WCCP traffic is forwarded to this interface.
This interface resides in the IDMZ and is the internet facing interface of the Cisco WSA. Once traffic has been analyzed and approved, it is sent via P2.
Once the three interfaces are configured and defined, routing tables for each interface can be configured to ensure that the desired connectivity is achieved. Typically, a default route on the P2 or IDMZ interface is used to help ensure that cloud and web traffic can reach its destination on the internet.
Figure 3-1 Cisco WSA Network Architecture
The configuration of the proxy stays in a mostly default state and can be accessed and viewed by navigating to Security Services -> Web Proxy. The HTTP ports that are to be proxied by the Cisco WSA can be defined in the configuration. Additionally, a proxy mode must be selected depending on the type of deployment that will be used with the Cisco WSA. The types of deployment, Transparent and Forward, were defined and discussed in Chapter2, “CPwE Cloud Connectivity Design Considerations” Transparent and Forward proxy modes were both tested and validated, however there is a difference in the overall configuration of the network and end devices between the two proxy modes. This chapter focuses on Transparent Mode configuration, but notes which configurations are not required for Forward Mode deployments. Figure 3-2 shows the Web Proxy Settings that were used during testing.
Caching is a feature that is typically used to attempt to reduce traffic and resources used on the network by saving a version of the webpage and providing it to clients. For testing and validation purposes, the caching feature was enabled but is not required.
The HTTPS proxy feature is a separate configuration that is required for use with most cloud applications. This configuration is located under Security Services -> HTTPS Proxy. Once this feature is enabled, a port (443 by default) must be entered to inform the Cisco WSA which HTTPS traffic to proxy. This value should remain 443 as shown in Figure 3-3 unless a solution is being implemented that changes the HTTPS traffic default port.
Figure 3-3 HTTPS Proxy Settings
Additional configuration relating to the HTTPS proxy includes decryption options and certificate related options.
Decryption options include those shown in Table 3-7 , which are left in the default state for testing and validation.
There are two parts to the certificate configuration options, including Invalid Certificate and Online Certificate Status Protocol (OSCP). These options can generally be uniformly applied to most architectures, but some are application-dependent. If internal or not well-known certificate authorities (CA) are in use (such as Rockwell Automation CA), the Unrecognized Root Authority/Issuer option needs to be set to Monitor instead of Drop. During the testing and validations outlined in this design guide, these options remained set to Monitor. OSCP is an internet protocol used for obtaining the revocation (validity) status of X.509 digital certificates and is defined in RFC 6960.
Since cloud applications and most web traffic typically use TLS or other forms of encrypted traffic to send data, the Cisco WSA must act as a man-in-the-middle (MiTM) to allow for the decryption, inspection, and re-encryption of traffic passing through it. To allow for this MiTM process to take place, the Cisco WSA must have a valid certificate to present to a requesting client, which must be trusted by that client. This can be a self-signed certificate generated by the Cisco WSA or from another certificate authority (CA). During the HTTPS Proxy configuration, the certificate that the Cisco WSA presents to the client is configured using either method. For testing and validation, a certificate generated by the Cisco WSA (self-signed) was used to decrypt traffic.
This is completed by using the Generate New Certificate and Key process located in the configuration section. Some information is then provided, such as common name, organization and expiration date and entered into the certificate in case a requesting user must verify. This information is shown in Figure 3-4.
After the certificate has been generated, the Download Certificate link can be used to download and distribute the certificate. The usage of this certificate is described in Windows Certificates, which describes the configuration of the EWS machines.
Figure 3-4 Certificate Details
Once the certificate has been exported/downloaded or the signing request had been completed, the certificate will be used on individual client computers or devices.
When using transparent redirection on the Cisco WSA, a method must be used to send web traffic from the infrastructure to the Cisco WSA. Typical redirection methods were described in Chapter2, “CPwE Cloud Connectivity Design Considerations” For testing and validation, the WCCP v2 router redirection method was selected as shown in Figure 3-5.
Once the WCCP v2 redirection method has been selected, the WCCP v2 services must be defined. These services, described in “CPwE Cloud Connectivity Design Considerations,” allow for the group of WCCP v2 devices to send specific traffic types to the Cisco WSA. In our test case, a custom service ID of 90 was used to define both HTTP (Port 80) and HTTPS (Port 443) traffic. This service ID is then used throughout the infrastructure devices to allow for adjacency between the infrastructure and the Cisco WSA.
The configuration of the WCCP v2 services has several items that must be defined as shown in Figure 3-6.
Figure 3-6 WCCP Service Profile
Once web traffic (HTTP or HTTPS) is received by the Cisco WSA, policies and rules exist to restrict, decrypt, monitor, or pass-through the traffic. The purpose and definition of each of these actions is defined in Table 3-8 . Additionally, Figure 3-6 defines the logical flow of data as well as the various lists and technologies that are processed during the flow of traffic.
Figure 3-7 Cisco WSA Logical Flow
A few items shown in Figure 3-7 are defined below; not all items are defined since some were not used or did not affect the testing and validation:
– This is used for applications or web traffic that may have issues being sent to a proxy or if there is a specific application that would not need to be inspected by the Cisco WSA. Items that are within the Bypass List are allowed through the Cisco WSA without additional examination.
– Custom URL Categories are used to websites that may not be well-known enough to fall into one of the existing pre-defined URL Categories. The Rockwell Automations website falls under the Business and Industry category and does not require a Custom URL category.
– All transactions resulting in unmatched categories are reported on the Reporting -> URL Categories page as uncategorized URLs. Many uncategorized URLs are generated from requests to websites within the internal network. Cisco, Panduit, and Rockwell Automation recommend using custom URL categories to group internal URLs and allow all requests to internal websites.
– WBRS is an innovative method that analyzes the behavior and characteristics of a web server and provides the latest defense in the fight against spam, viruses, phishing, and spyware threats.
– WBRS uses real-time analysis on a vast, diverse, and global dataset in order to detect URLs that contain some form of malware. It is a critical part of the Cisco security database, which helps protect from blended threats from email or web traffic.
– WBRS differs from a traditional URL blacklist or whitelist because it analyzes a broad set of data and produces a highly granular score of -10 to +10, instead of the binary good or bad categorizations of most malware detection applications. This granular score offers administrators increased flexibility; different security policies can be implemented based on different WBRS scoring ranges.
– Decryption policies define the handling of HTTPS traffic within the web proxy:
– You can create decryption policies to handle HTTPS traffic in the following ways:
– The category that a URL falls into is determined by a filtering categories database. The Web Security Appliance collects information and maintains a separate database for each URL filtering engine. The filtering categories databases periodically receive updates from the Cisco update server.
– The URL categories database includes many different factors and sources of data internal to Cisco and from the internet.
The decryption policy configuration of the Cisco WSA is dependent on the types of applications and software that may be sending HTTP and HTTPS traffic throughout the infrastructure. For testing and validation, the focus was to help ensure that Rockwell Automation software and applications continued to function while the proxy was in place and providing inspection. Based on the testing of current offerings that offer cloud connectivity by Rockwell Automation, the following software was tested:
– Lifecycle status information
– Activation retrieval, renewal, and rehosting
– Lifecycle status information
– Firmware and release notes downloads
The Rockwell Automation software mentioned above reaches out to rockwellautomation.com as the primary domain name for all requests. The rockwellautomation.com domain name is a known good domain name and is categorized under the Business and Industry URL category. Any subdomain such as api.rockwellautomation.com would also fall under this URL category. For minimal access the following decryption policy can be set to Decrypt, Monitor, or Pass-Through as shown in Figure 3-8.
In the previous sections WCCP v2 was described as the method of redirection that would be used for HTTP and HTTPS traffic within the infrastructure. For Cisco IOS devices, the configuration for WCCP v2 is standard, but specific device documentation should be cross-referenced with the configurations outlined in this design guide. The configuration for WCCP v2 in this section is shown both from Command Line Interface (CLI) as well as Cisco ASDM. This generally will allow the application of WCCP v2 redirection to Cisco ASA and route and switch devices. This allows the user to have multiple choices where redirection could be applied depending on network architecture and traffic flow.
For WCCP, the device chooses the highest reachable IP address configured on an interface and uses that as the router ID. This is the same process that Open Shortest Path First (OSPF) follows for the router ID. When the device redirects packets to the proxy the device sources the redirect from the router ID IP address (even if it is sourced out another interface) and encapsulates the packet in a GRE header.
The GRE connection is unidirectional. The device encapsulates redirected packets in GRE and sends them to the proxy. The device does not process any GRE-encapsulated responses from the proxy. The proxy must communicate directly to the inside host.
Note If using WCCP on a Cisco ASA, the commands below should exlude ip. For example, ip wccp web-cache on the Cisco ASA would be wccp web-cache.
Enable privileged EXEC mode. Enter your password if prompted.
Enters global configuration mode.
Step 3 ip wccp version {1 | 2 }
Specifies which version of WCCP to configure on a device. WCCPv2 is the default running version.
Step 4 ip wccp {web-cache | service-number} [group-address multicast-address] [redirect-list access-list] [group-list access-list] [password password [0 | 7 ] ]
Specifies a web-cache or dynamic service to enable on a device, specifies the IP multicast address used by the service group (optional), specifies any access lists to use, specifies whether to use MD5 authentication, and enables the WCCP service.
Note The password length must not exceed eight characters.
Targets an interface number for which the web cache service will run and enters interface configuration mode.
Step 6 ip wccp {web-cache | service-number} redirect {in}
Enables packet redirection on an outbound or inbound interface using WCCP. As indicated by the out and in keyword options, redirection can be specified for outbound interfaces or inbound interfaces.
Exits interface configuration mode.
Targets an interface number on which to exclude traffic for redirection and enters interface configuration mode.
Step 9 ip wccp redirect exclude in
(Optional) Excludes traffic on the specified interface from redirection.
The redirect access-list allows you to control which traffic should be redirected and is used with the ip wccp command. It is recommended to add deny statements to the redirect list for RFC 1918 addresses such as 10.0.0./8, 172.16.0.0/12, and 192.168.0.0/16 to help ensure that local traffic is not forwarded to the proxy. The following example shows how to redirect traffic only from subnet 10.1.1.0:
To achieve better security, you can use a standard access-list to notify the redirecting device about the IP addresses that are valid addresses for the Cisco WSA attempting to register with the current device. The following example shows a standard access-list configuration session where the access-list number is 10 for some sample hosts. When this access-list is applied to the ip wccp command, only proxies that are listed in the access-list will be added to the group.
Step 1 Choose Configuration -> Device Management -> Advanced -> WCCP -> Service Groups (Figure 3-9).
Step 2 Do any of the following (Figure 3-10):
Figure 3-10 WCCP Service Group
Step 3 In the Add/Edit Service Group dialog box, configure the following options (Figure 3-11).
– Web Cache—The standard service, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the WCCP-enabled device. This exludes TCP port 443 HTTPS traffic.
– Dynamic Service Number—The Cisco WSA device defines the services associated with this dynamic service number (0-254); on the ASA, you are simply associating the number with this group. For testing and validation, the dynamic service number of 90 was used.
Step 5 Click Apply to save your changes.
To configure packet redirection on the ingress of an interface using WCCP, perform the following steps:
Step 1 Choose Configuration -> Device Management -> Advanced -> WCCP -> Redirection.
Step 2 Do any of the following (Figure 3-12):
Step 3 In the Add/Edit WCCP Redirection dialog box, configure the following options (Figure 3-13):
Figure 3-13 WCCP Redirection Interface
Step 5 Click Apply to save your changes. Be sure to save the startup configuration once complete.
With the Cisco WSA and WCCP v2 configuration complete, the workstations that are intended to use the proxy must be configured. Depending on the proxy configuration, transparent or explicit, the configuration varies slightly. However, both methods still require the importation of certificates generated by the Cisco WSA.
This section focuses on the Windows Operating System (Windows 7) and its associated web browsers and certificate stores. Once the certificate has been imported, a trust is created between the workstation and the Cisco WSA.
No workstation configuration besides the importation of the certificates is needed to help ensure the success of the transparent proxy deployment. With this in mind, there is no subsection listed for Transparent Redirection.
As previously mentioned, the Cisco WSA providing TLS proxy services must have the ability to decrypt the data coming from the application or EWS. To provide this service, a certificate that is used (generated by the Cisco WSA or a root CA) on the Cisco WSA must be stored on each EWS that wishes to send traffic to the cloud through the Cisco WSAs TLS proxy service. Based on testing and validation it is recommended to add the Cisco WSA certificate to each pertinent web browser and the Microsoft certificate store. This can be accomplished manually or through Group Policy; for testing this was completed manually.
Step 1 Start -> Run. Type MMC.exe.
Step 2 Click File -> Add/Remote Snap-in.
Step 3 In the Available snap-ins list, click Certificates and click Add (Figure 3-14).
Figure 3-14 Add or Remove Snap-ins
Step 4 Depending on security posture and how the application is being used, select My User Account, Computer Account, or Service Account and click Next.
Generally, for a single user computer, My User Account is the acceptable choice.
Step 5 Once finished, click OK.
Step 6 In the MMC window, click Certificates then right-click Trusted Root Certification Authorities -> All Tasks -> Import… (Figure 3-15).
This opens the Certificate Import Wizard where the certificate downloaded from the Cisco WSA in the previous section should be selected.
Step 7 Once the wizard is launched, click Next for the first prompt and then the File to Import window displays prompting for a file name (Figure 3-16).
Figure 3-16 Certificate Import Wizard
When browsing for the certificate using this method, it is important to note that the certificate that was downloaded from the Cisco WSA is a.pem file extension. By default, the browse feature in the certificate import wizard is looking for X.509. To locate the.pem certificate from the Cisco WSA, the file type in the browse window must be adjusted and set to All files (*.*) (Figure 3-17).
Figure 3-17 Select Certificate
Step 8 Once the certificate has been selected, click Next to display the Certificate Store screen (Figure 3-18).
Step 9 On this screen ensure that the Place all certificates in the following store is set to Trusted Root Certification Authorities, then click Next.
Step 10 Verify the settings on the final screen and click Finish.
A window displays indicating that the import was successful (Figure 3-19).
Note It is also required that each web browser in use in the system (including Internet Explorer, even if not used for browsing) also has the same certificate imported into the browser as a certificate authority. Because there are various web browsers with different interfaces, this design guide does not detail the process.
Explicit redirection of web traffic follows similar setup requirements as the WCCP transparent redirection method. The explicit redirection method does not require the dual-homed approach that was described in Interface Configuration. Explicit redirection only requires a single interface (besides management) and can exist solely in the IDMZ. The certificate must be imported to the various locations as descried in Windows Certificates. The biggest difference between the two redirection methods is that the explicit redirection requires the user to configure each web browser to explicitly redirect to the Cisco WSA proxy. As with the certificate importation, each browser has a different method to access the proxy settings and each browser is required to be set up to point to the Cisco WSA. The example below of the proxy configuration was taken from FireFox (Figure 3-20).
Figure 3-20 FireFox Connection Settings
Some important items to note in the above configuration: