Chapter 11: Switching Secured Content

Cisco Press

You will learn how to configure content switching for the following security protocols in this chapter:

  • Secure Sockets Layer (SSL) Termination—You can configure your content switch to terminate SSL connections on behalf of clients.

  • Firewall Load Balancing (FWLB)—You can configure your content switch to distribute client traffic across multiple firewalls.

  • Virtual Private Network (VPN) Load Balancing (FWLB)—You can configure your content switch to distribute client traffic across multiple VPN concentrators.

  • SYN-Cookies for SYN-Flood Protection—You will learn how the CSM uses SYN-cookies to prevent SYN-flood attacks from flooding the CSM's connection table.

In Chapter 10, "Exploring Server Load Balancing," you learned how to configure content switching to accelerate your applications through the use of server load balancing. In this chapter, you'll learn four popular ways to accelerate secure content delivery by using content switching:

  • SSL Termination—You learned about the operation of the SSL protocol in Chapter 8, "Exploring the Application Layer." Here, you will learn how content switches can off-load SSL computations from your origin servers to dedicated SSL devices and modules.

  • Firewall Load Balancing—As you learned in Chapter 4, "Exploring Security Technologies and Network Infrastructure Designs," firewalls provide stateful packet inspection and maintain the context within and across TCP and UDP connections. In this chapter, you will learn how to load balance your traffic across multiple stateful firewalls.

  • VPN Load Balancing—VPN devices can provide site-to-site or remote access for your corporate users. Content switches can also provide load balancing across multiple VPN concentrators.

  • SYN-Flood Protection—The Content Switching Module (CSM) uses SYN-cookies to prevent SYN-floods from flooding its connection table.

SSL Termination

With SSL termination, a dedicated SSL termination device terminates the SSL connection, offloading CPU-intensive SSL computations from your origin servers. SSL termination devices have special hardware that can perform the SSL operations.

SSL termination also enables the content switch to parse cleartext application headers to intelligently load balance SSL requests. To provide SSL offloading, you can configure your content switch and SSL termination device to decrypt SSL traffic and forward the cleartext traffic to non-SSL real servers, as Figure 11-1 illustrates.

figure 11.1

Figure 11-1

SSL Offloading

Because the content switch sees the request in cleartext, you can configure Layers 5–7 load balancing with SSL termination. Also, because the SSL module forwards traffic in cleartext to real servers, you should make sure that you secure your server farm switches to prevent sniffing of the cleartext traffic.


Note - To encrypt traffic from your SSL termination device to your back-end real servers, you can configure Back-End Encryption on your Content Services Switch (CSS) and CSM. Refer to your product documentation on Cisco.com for more information on Back-End Encryption.


Based on Figure 11-1, a client's SSL transaction flows through the content network as follows:

  1. The client generates a TCP SYN segment to initiate a TCP connection to the SSL port (443) on the content switch. The content switch receives the TCP segment, issues an HTTPS virtual server lookup, and opens the TCP connection with the client. The client generates a cleartext SSL Client Hello packet and forwards it to the content switch.


  2. Note - Refer to Figure 8-11 in Chapter 8 for more information on the SSL four-way handshake.


  3. The content switch receives the SSL Client Hello and load balances the request to an available SSL termination device. If you configure SSL-sticky on the content switch, the content switch stores the Session ID associated with the connection. The SSL termination device then processes the Client Hello and completes the SSL four-way handshake with the client to establish an encrypted transport session.


  4. Note - If you have multiple SSL devices, you should configure SSL-sticky to ensure that each connection from within the SSL session is load-balanced to the same SSL device. This would be beneficial for clients who want to resume idle SSL sessions, as you learned previously from Figure 8-12 in Chapter 8.


  5. The client generates an HTTPS application request and forwards it to the content switch over the encrypted SSL transport session. The content switch in turn forwards the encrypted request to the appropriate SSL termination device, based on the entry for the existing TCP connection in the content switch's connection table.

  6. The SSL termination device receives the encrypted application request.

  7. The SSL termination device decrypts the application request, optionally rewrites the URL or any HTTP headers in the request, and forwards it back to the content switch.


  8. Note - You will learn about URL and HTTP Header rewriting later in this chapter.


  9. The content switch receives the cleartext application request, issues an HTTP virtual server lookup, stores any cleartext sticky information (for example, HTTP cookies and source IP addresses) that you configure, and load balances the request to an available real server. The content switch also performs destination Network Address Translation (NAT) on the packet to the real server IP address.

  10. The real server processes the cleartext request and sends the HTTP 200 OK cleartext response to the content switch.

  11. The content switch receives the HTTP 200 OK cleartext response and forwards it to the SSL termination device, based on the connection information in the content switch's connection table, thus overriding normal TCP/IP routing to the client source IP address. The content switch also reverses the destination NAT performed in Step 6.

  12. The SSL termination device encrypts the response and forwards it to the content switch, again preserving the source and destination IP addresses.

  13. The content switch routes the encrypted SSL packet to the client.

To configure SSL Termination, you can use either:

  • CSS with an SSL Module—Recall from Chapter 10 that you can install an SSL encryption module in the CSS 11503 or 11506 or obtain a CSS 11501 with an embedded SSL module.

  • CSM with SSL Daughter Card Module (CSM-S)—You can also obtain a CSM-S for terminating SSL connections. The daughter card module is not field upgradeable—you cannot purchase the daughter card separately for an existing CSM installation.

Configuring Your CSS for SSL Termination

To configure your CSS to offload your SSL connections to an SSL termination device, you must first load your keys and certificates to the SSL termination device. If you are already using public-key infrastructure (PKI) on your real servers and want to upgrade your system with SSL termination, you can import your existing private keys and server certificates to the SSL termination device. Otherwise, you can generate private/public key pairs and Certificate Signing Requests on the SSL termination device and request a server certificate from a Certificate Authority (CA). Once you enroll with a CA and receive the server certificate, you can import the server certificate to your SSL termination device.


Note - You can also use your own private CA to enroll certificates with Cisco CSSs and CSMs. For more information on configuring automatic certificate enrollment with private CAs, see your product documentation on Cisco.com.


Creating and Importing Keys and Certificates on the CSS

You learned about the SSL module that is available for the CSS in Chapter 10. To import pre-existing keys and certificates to your CSS SSL module, you can use the command:

copy ssl [protocol] ftp_record [import filename [format] "password" {"passphrase"}

The passphrase is the existing phrase created with the certificate for encrypting/decrypting. This phrase must be used anywhere you use the certificate, not just on the CSS. You must also create a new password as a second layer of security that the CSS will use to encrypt the imported certificate. This password is local to the CSS and prevents unauthorized administrators from accessing the certificate on the CSS. Before issuing this command, you should first create an FTP record where your certificate and private key is located. You can use the ftp-record command to create a record called import-ssl. You must include your FTP username, your password to the FTP server, and the home directory where the certificate and private key is located on the server. For example:

ftp-record import-ssl 10.1.1.1 cisco "cisco123" /home/sdaros

You can use the following copy ssl command to import a PEM file containing an existing server certificate and private key, called sitecert.pem and sitekey.pem, respectively:

copy ssl sftp import-ssl import sitecert.pem PEM "sanfran" "sanfran"
copy ssl sftp import-ssl import sitekey.pem PEM "sanfran" "sanfran"

You must indicate to the CSS whether the imported files contain a private key or a certificate by using the ssl associate commands:

ssl associate cert mycontentcert sitecert.pem
ssl associate rsakey mycontentkey sitekey.pem

Note - Make sure that you import your CA's root certificate. Additionally, if your CA issues you a chained certificate, make sure you also import any intermediary certificates within the chain.


Instead of importing existing keys, you can generate an Rivest, Shamir, and Adelman (RSA) public/private key pair for asymmetric encryption on the CSS using the following command:

ssl genrsa filename numbits "password"

This command stores both the private and public key in a single file that you must associate with a certificate name. For example, to generate a key called mycontentkey, use the following commands:

ssl genrsa mycontentkeyfile 1024 "sanfran"
ssl associate rsakey mycontentkey mycontentkeyfile

To generate a CSR for the key pair, use the following command in Example 11-1.

Example 11-1 Generating a CSR on the CSS

(config)# ssl gencsr mycontentkey
You are about to be asked to enter information
that will be incorporated into your certificate
request. What you are about to enter is what is
called a Distinguished Name or a DN.
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [US]US
State or Province (full name) [SomeState]California
Locality Name (city) [SomeCity]San Jose
Organization Name (company name) [Acme Inc]Cisco Systems, Inc.
Organizational Unit Name (section) [Web Administration]Network Engineering
Common Name (your domain name) [http://www.acme.com]http://www.cisco.com
Email address [webadmin@acme.com]admin@cisco.com

-----BEGIN NEW CERTIFICATE REQUEST-----
MIctCMtmZONOY+ybEHl/mX0RdqXFnivLBgNVBAYTAlVTMRAwDgYDVQQIEwdHZW9y
DQ kW6Pa6mbjeUV1wffn2dtbKsmz7DnK2BVbml2ZXJzaXR5IG9 yRPs36ywGwDK3
aWExNTAzBgNVBAsTLFVuaXZlcnNpdHkgQ29tcHV0aW5nIGFuZCBOZXR3b3JraW5n
IFNlcnZpY2VzMRYwFAYDVQQDEw13d3ctcy51Z2EuZWR1MIGdMA0GCSqGSIb3DQEB
AQUAA4GLADCBhwKBgQDh3yRPs36ywGwDK3ZS3qaOoNraOFHkSNTsielHUMHxV1/G
N1E43/bifEQJUvSw/nrkOQf3Ync8O/39lelUTJeP6QZkX9Hg1XtuSUov3ExzT53l
vbctCMtmZONOY+ybEHl/mX0RdqXFnivLpXohr7dJ5A1qHfjww/SLW8J/7UXj1QIB
A6AAMA0GCSqGSIb3DQEBBAUAA4GBAIEu35zoGmODCcwwNrTqZk3JQAjyONJxjjtd
uQ+QLQcckO4aghBpcqsgLckW6Pa6mbjeUV1wffn2dtbKsmz7DnK2fwnyaBtxXMvi
CC4o9uvW11i5TjdorfOdRI1lR0FrNAzf+3GQUl1S2a83wagvFjo12yUCukrxBgyU
bXbmNuJpkdsjdkjfkdjfkdfjdkfjdkfjdkfj
-----END NEW CERTIFICATE REQUEST-----

To apply for a server certificate, you must send the CSR to a CA of your choice. Most well-known CAs allow you to cut and paste your CSR to their websites and will issue you a server certificate via e-mail within a few business days. Once you receive your server certificate (called sitecert.pem in this example), you can import it using the copy ssl command that you learned previously:

copy ssl sftp import-ssl import sitecert.pem PEM "sanfran" "sanfran"
ssl associate cert mycontentcert sitecert.pem

Note - Make sure you keep track of when your certificates expire. You will need to obtain new certificates before they expire. Otherwise, clients will receive an error when they attempt to download the expired certificate.


Terminating SSL on the CSS

Now that you have a server certificate and a private key on your CSS, you can configure your CSS to terminate SSL connections on behalf of your real servers, as illustrated in Example 11-2.


Note - Note that there is no IP addressing and server destination-Network Address Translationing (DNATing) involved when configuring the CSS SSL module.


Example 11-2 Configuring Your CSS to Terminate SSL Connections

ssl-proxy-list ssl_proxy
 ssl-server 1
 ssl-server 1 vip address 10.1.10.1
 ssl-server 1 port 443
 ssl-server 1 rsacert mycontentcert
 ssl-server 1 rsakey mycontentkey
 ssl-server 1 cipher TLS_RSA_WITH_RC4_128_MD5 10.1.10.100 80 weight 5
 ssl-server 1 cipher TLS_RSA_WITH_RC4_128_SHA 10.1.10.100 80 weight 10
 ssl-server 1 http-header session
 ssl-server 1 urlrewrite 1 http://www.cisco.com
 active

service ssl-serv1
 type ssl-accel
 add ssl-proxy-list ssl_proxy
 slot 5
 keepalive type none
 active

service ssl-serv2
 type ssl-accel
 add ssl-proxy-list ssl_proxy
 slot 6
 keepalive type none
 active

service web01
 ip address 10.1.10.10 
 active

service web02
 ip address 10.1.10.11 
 active

owner cisco
 content https-vip
 vip address 10.1.10.100
 protocol tcp
 port 443
 add service ssl-serv1
 add service ssl-serv2
 active

content http-vip
 vip address 10.1.10.100
 protocol tcp
 port 80
 add service web01
 add service web02
 active
Related:
1 2 3 4 Page 1
Page 1 of 4
SD-WAN buyers guide: Key questions to ask vendors (and yourself)