With regarding to security on a Steelhead appliance, the following aspects can be considered:
Access security, how to secure management access to the Steelhead appliance.
Data security, how the data stored on the Steelhead appliance is secured.
Network security, how data transmitted between Steelhead appliances is secured.
The management interfaces of the Steelhead appliance can be accessed via the CLI, either via SSH or via Telnet, and via the GUI, either via HTTP or via HTTPS. Further data can be retrieved from the device via the SNMP service.
Traffic transmitted via the Telnet protocol is transmitted in clear text. By default, the telnet service is not enabled on the Steelhead.
Figure 5.160. Telnet service is not enabled on this Steelhead appliance
SH (config) # no telnet-server enable SH (config) # show telnet-server Telnet server enabled: no
Traffic transmitted via the Secure Shell protocol is encrypted. By default the SSH service is enabled on the Steelhead appliance.
It can be used for interactive traffic or for batch transfers with the scp command, however the access to the device via scp is limited to specific directories.
By default, the SSH service accepts the SSH version 1 and SSH version 2 protocols, but it can be configured to use the SSH version 2 protocol only.
Not all SSH ciphers are enabled anymore in the later RiOS versions.
PuTTY version 0.59 and before and SecureCRT are known to not to
like this. See the command
show ssh server allow-ciphers
for the list of supported ciphers on the Steelhead appliance.
The SSH service by default listens for connections on all interfaces but it can be configured to listen only on specific interfaces.
As a bonus point the SSH service can be told to listen to a different TCP port. For Steelhead appliance configured with a public IP address and is directly accessible from the public Internet, this is a must to prevent dictionary attacks against the SSH service. However, Steelhead appliances managed by the CMC cannot use any other TCP port the default.
Figure 5.161. Secure SSH configuration
SH (config) # ssh server listen enable SH (config) # ssh server listen interface primary SH (config) # ssh server v2-only enable SH (config) # ssh server port 8022 SH (config) # show ssh server allow-ciphers SSH server allowed ciphers: --------------------------- aes128-cbc aes192-cbc aes256-cbc SH (config) # show ssh server SH server enabled: yes SSH server listen enabled: yes SSH port: 8022 SSH v2 only: yes Listen Interfaces: Interface: primary
Traffic transported via the HTTP protocol is transmitted in clear text, while traffic transported via the HTTPS protocol is encrypted. The HTTP and HTTPS services are both enabled by default.
The HTTP and HTTPS services by default listen for connections on all interfaces, but they can be configured to listen only on specific interfaces.
The HTTP and HTTPS services can be moved from the default TCP port 80 and TCP port 443 to different ports.
The SSL ciphers used for the HTTPS server can be configured with the standard Apache SSLCipherSuite statement options.
Figure 5.162. HTTP and HTTPS security configuration
SH (config) # no web http enable SH (config) # web httpd listen enable SH (config) # web httpd listen interface primary SH (config) # web http port 8080 SH (config) # web https enable SH (config) # web https port 8443 SH (config) # web ssl cipher ALL:!ADH:RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv2:!EXPORT SH (config) # show web Web-based management console enabled: yes HTTP enabled: no HTTP port: 80 HTTPS enabled: yes HTTPS port: 8443 SOAP server enabled: no SOAP server port: 9001 Configure Mode TRAP: yes Inactivity timeout: 120 minutes Session timeout: 60 minutes Session renewal threshold: 30 minutes Timeout during report auto-refresh: yes SSLv2 enabled: no SSLv3 enabled: yes TLSv1 enabled: yes Listen enabled: yes Listen Interfaces: Interface: primary SH (config) # show web ssl cipher Apache SSL cipher string: ALL:!ADH:RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv2:!EXPORT
SNMP is an UDP based protocol. For the versions 1 and 2, the authentication is done via a shared secret known as the community string, which is transmitted in the clear. For version 3 the authentication is done via a challenge response mechanism.
The SNMP MIBs for the Riverbed appliances can be obtained from the Riverbed Support website under the documentation section or from the appliance itself under the Support tab in the GUI. There are several different MIB files, one for each appliance:
RBT-MIB: The Riverbed specific MIB which links the individual appliance MIBs towards the enterprises MIB. This one is required for all other MIBs.
STEELHEAD-MIB: The Steelhead appliance specific MIB.
STEELHEAD-EX-MIB: The Steelhead EX appliance specific MIB.
CMC-MIB: The CMC appliance specific MIB.
CONTROLLER-MIB: The Steelhead Mobile Controller appliance specific MIB.
INTERCEPTOR-MIB: The Interceptor appliance specific MIB.
The SNMP service on the Steelhead appliance can only be used to read data from the appliance, it cannot be used to write data to it or to enable features.
The SNMP service by default listens for connections on all interfaces, but it can be configured to listen only on specific interfaces.
Figure 5.163. SNMP security configuration
SH (config) # snmp-server listen enable SH (config) # snmp-server listen interface primary SH (config) # no snmp-server listen interface primary SH (config) # snmp-server listen interface primary SH (config) # show snmp SNMP enabled: yes System location: System contact: Engine ID: 0x8000430b80bfb2484edda91d Read-only community: Traps enabled: yes Interface listen enabled: yes Trap interface: primary Persistent ifindex: no Listen Interfaces: Interface: primary No trap sinks configured.
The SNMP version 1 implementation on the Steelhead appliance only supports one community string. If the community string is correct, then the Steelhead appliance will send the response. If the community string is incorrect, then the Steelhead appliance will not respond. There is no view on the data to limit the MIB tree that can be accessed via SNMP version 1.
Figure 5.164. SNMPv1 request for system.sysName.0
SH # tcpdump -ni primary -v -X -s 1600 port snmp tcpdump: listening on primary, link-type EN10MB (Ethernet), capture size 1600 bytes 07:39:15.699362 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 71 \ ) 10.0.1.1.39643 > 10.0.1.5.161: { SNMPv1 { GetRequest(28) R=18892990 .1.3.6.1.2.1.1.5 \ .0 } } 0x0000: 4500 0047 0000 4000 3a11 103d 0a00 0101 E..G..@.:..=.... 0x0010: 0a00 0105 9adb 00a1 0033 88ab 3029 0201 .........3..0).. 0x0020: 0004 0670 7562 6c69 63a0 1c02 0401 2048 ...public......H 0x0030: be02 0100 0201 0030 0e30 0c06 082b 0601 .......0.0...+.. 0x0040: 0201 0105 0005 00 ....... 07:39:15.699484 IP (tos 0x0, ttl 64, id 36, offset 0, flags [DF], proto UDP (17), length 7 \ 3) 10.0.1.5.161 > 10.0.1.1.39643: { SNMPv1 { GetResponse(30) R=18892990 .1.3.6.1.2.1.1. \ 5.0="SH" } } 0x0000: 4500 0052 0024 4000 4011 0a0e 0a00 0005 E..R.$@.@....... 0x0010: 0a00 0101 00a1 9adb 003e 30b9 3034 0201 .........>0.04.. 0x0020: 0004 0670 7562 6c69 63a2 2702 0401 2048 ...public.'....H 0x0030: be02 0100 0201 0030 1930 1706 082b 0601 .......0.0...+.. 0x0040: 0201 0105 0004 0253 48 .......SH
As can be seen, the community string used here is public,
The SNMP version 3 implementation on the Steelhead appliance supports multiple users and views. A user is a username and password combination, a view is a part of the MIB tree. Together they define what an SNMPv3 client can see.
In this example the username is "shtest" is allowed to see the view "system", which includes the MIB tree .1.3.6.1.2.1.1, which is the system MIB ".iso.org.dod.internet.mgmt.mib-2.system".
Figure 5.165. SNMPv3 configuration for the user "shtest" to the system MIB
snmp-server acl group shtest security-level noauth read-view system snmp-server engine-ID "0x8000430b80bfb2484edda91d" snmp-server group shtest security-model usm security-name shtest snmp-server user shtest password encrypted 0x54e42e390606150a0dcb67fa5b6775ca auth-protoco \ l MD5 snmp-server view system included ".1.3.6.1.2.1.1"
The SNMPv3 request will look like this on the wire:
Figure 5.166. SNMPv3 request for system.sysName.0
SH (config) # tcpdump -ni primary -v -X -s 1600 port snmp tcpdump: listening on primary, link-type EN10MB (Ethernet), capture size 1600 bytes 12:25:01.539068 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 92 \ ) 10.0.1.1.35409 > 10.0.1.5.161: { SNMPv3 { F=r } { USM B=0 T=0 U= } { ScopedPDU E= C= \ { GetRequest(14) R=383165213 } } } 0x0000: 4500 005c 0000 4000 3a11 1028 0a00 0101 E..\..@.:..(.... 0x0010: 0a00 0105 8a51 00a1 0048 23f9 303e 0201 .....Q...H#.0>.. 0x0020: 0330 1102 0424 9448 2702 0300 ffe3 0401 .0...$.H'....... 0x0030: 0402 0103 0410 300e 0400 0201 0002 0100 ......0......... 0x0040: 0400 0400 0400 3014 0400 0400 a00e 0204 ......0......... 0x0050: 16d6 a31d 0201 0002 0100 3000 ..........0. 12:25:01.539478 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 13 \ 4) 10.0.1.5.161 > 10.0.1.1.35409: { SNMPv3 { F= } { USM B=32 T=631 U= } { ScopedPDU E= 0 \ x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { Report(31) R=383165213 .1.3.6.1. \ 6.3.15.1.1.4.0=1 } } } 0x0000: 4500 0086 0000 4000 4011 09fe 0a00 0105 E.....@.@....... 0x0010: 0a00 0101 00a1 8a51 0072 30ed 3068 0201 .......Q.r0.0h.. 0x0020: 0330 1102 0424 9448 2702 0300 ffe3 0401 .0...$.H'....... 0x0030: 0002 0103 041d 301b 040c 8000 430b 80bf ......0.....C... 0x0040: b248 4edd a91d 0201 2002 0202 7704 0004 .HN.........w... 0x0050: 0004 0030 3104 0c80 0043 0b80 bfb2 484e ...01....C....HN 0x0060: dda9 1d04 00a8 1f02 0416 d6a3 1d02 0100 ................ 0x0070: 0201 0030 1130 0f06 0a2b 0601 0603 0f01 ...0.0...+...... 0x0080: 0104 0041 0101 ...A.. 12:25:01.710160 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 13 \ 7) 10.0.1.1.35409 > 10.0.1.5.161: { SNMPv3 { F=r } { USM B=32 T=631 U=shtest } { ScopedP \ DU E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetRequest(28) R=383165214 \ .1.3.6.1.2.1.1.5.0 } } } 0x0000: 4500 0089 0000 4000 3a11 0ffb 0a00 0101 E.....@.:....... 0x0010: 0a00 0105 8a51 00a1 0075 99c2 306b 0201 .....Q...u..0k.. 0x0020: 0330 1102 0424 9448 2802 0300 ffe3 0401 .0...$.H(....... 0x0030: 0402 0103 0423 3021 040c 8000 430b 80bf .....#0!....C... 0x0040: b248 4edd a91d 0201 2002 0202 7704 0673 .HN.........w..s 0x0050: 6874 6573 7404 0004 0030 2e04 0c80 0043 htest....0.....C 0x0060: 0b80 bfb2 484e dda9 1d04 00a0 1c02 0416 ....HN.......... 0x0070: d6a3 1e02 0100 0201 0030 0e30 0c06 082b .........0.0...+ 0x0080: 0601 0201 0105 0005 00 ......... 12:25:01.710314 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto UDP (17), length 13 \ 9) 10.0.1.5.161 > 10.0.1.1.35409: { SNMPv3 { F= } { USM B=32 T=631 U=shtest } { ScopedPD \ U E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetResponse(30) R=383165214 \ .1.3.6.1.2.1.1.5.0="SH" } } } 0x0000: 4500 0094 0001 4000 4011 09ef 0a00 0105 E.....@.@....... 0x0010: 0a00 0101 00a1 8a51 0080 30fb 3076 0201 .......Q..0.0v.. 0x0020: 0330 1102 0424 9448 2802 0300 ffe3 0401 .0...$.H(....... 0x0030: 0002 0103 0423 3021 040c 8000 430b 80bf .....#0!....C... 0x0040: b248 4edd a91d 0201 2002 0202 7704 0673 .HN.........w..s 0x0050: 6874 6573 7404 0004 0030 3904 0c80 0043 htest....09....C 0x0060: 0b80 bfb2 484e dda9 1d04 00a2 2702 0416 ....HN......'... 0x0070: d6a3 1e02 0100 0201 0030 1930 1706 082b .........0.0...+ 0x0080: 0601 0201 0105 0004 0b53 48 .........SH
The first two packets are a handshake between the SNMP client and the SNMP server, the next two packets are the actual request.
There are several failure situations here:
Unknown user name
No access to a MIB tree
In case of an unknown username, the answer will be a Report instead of a GetResponse:
Figure 5.167. SNMPv3 request with an unknown username
11:24:52.269466 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 13 \ 7) 10.0.1.1.43166 > 10.0.1.5.161: { SNMPv3 { F=r } { USM B=26 T=275 U=shtest } { ScopedP \ DU E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetRequest(28) R=794705738 \ .1.3.6.1.2.1.1.5.0 } } } 11:24:52.269731 IP (tos 0x0, ttl 64, id 5, offset 0, flags [DF], proto UDP (17), length 14 \ 0) 10.0.1.5.161 > 10.0.1.1.43166: { SNMPv3 { F= } { USM B=26 T=276 U=shtest } { ScopedPD \ U E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { Report(31) R=794705738 .1. \ 3.6.1.6.3.15.1.1.3.0=3 } } }
The SNMPv3 configuration allows views to a part of the MIB tree. If the user is not configured to any part of the MIB tree, it will return an authorizationError:
Figure 5.168. SNMPv3 request for an unconfigured view
11:29:56.037463 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 13 \ 6) 10.0.1.1.45142 > 10.0.1.5.161: { SNMPv3 { F=r } { USM B=28 T=78 U=shtest } { ScopedPD \ U E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetRequest(28) R=1322240049 \ .1.3.6.1.2.1.1.5.0 } } } 11:29:56.037671 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto UDP (17), length 13 \ 6) 10.0.1.5.161 > 10.0.1.1.45142: { SNMPv3 { F= } { USM B=28 T=78 U=shtest } { ScopedPDU \ E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetResponse(28) R=1322240049 \ authorizationError[errorIndex==0] .1.3.6.1.2.1.1.5.0= } } }
If the user is not allowed to see a certain part of the MIB tree, it will return a noSuchObject:
Figure 5.169. SNMPv3 request for a disallowed view
12:05:52.867922 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 13 \ 7) 10.0.1.1.40284 > 10.0.1.5.161: { SNMPv3 { F=r } { USM B=28 T=2234 U=shtest } { Scoped \ PDU E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetRequest(28) R=11416833 \ 94 .1.3.6.1.2.1.2.1.0 } } } 12:05:52.868041 IP (tos 0x0, ttl 64, id 25, offset 0, flags [DF], proto UDP (17), length 1 \ 37) 10.0.1.5.161 > 10.0.1.1.40284: { SNMPv3 { F= } { USM B=28 T=2234 U=shtest } { ScopedP \ DU E= 0x800x000x430x0B0x800xBF0xB20x480x4E0xDD0xA90x1D C= { GetResponse(28) R=11416833 \ 94 .1.3.6.1.2.1.2.1.0=[noSuchObject] } } }
With regarding to data security on the Steelhead appliance, there is data store encryption and there is the Secure Vault.
The data store on the Steelhead appliance can be encrypted with the AES_128, AES_192 or AES_256 algorithms. The expected performance hit depends on workload and disk intensity, but about a 10% slower data store I/O should be expected.
After a restart of the optimization service with the Clear the data store option enabled, the data store will be recreated and data will be written in an encrypted format:
Figure 5.171. Recreation of an encrypted data store
SH cli[10962]: [cli.INFO]: user admin: Executing command: restart clean SH cli[10962]: [cli.INFO]: user admin: Command restart clean authorized [...] SH sport[11423]: [sport.INFO] - {- -} Stage 1 initialization starting... SH sport[11423]: [segstore/DatastoreDiskOffset.INFO] - {- -} Initialized Special disk offs \ et [...] SH sport[11423]: [segstore/peertable.INFO] - {- -} Peer table. Num peers : 4096 Groups : 1 \ 024 Pages : 9 Min Disconnect time : 86400 SH sport[11423]: [segstore.INFO] - {- -} Starting Persistent Store, config: diskpolicy li \ near cachepgs 1250000 hashbits 59 nblocks 4096 replacement_policy RVBDLRU w_behind 102 \ 4 r_ahead 1 w_queue_depth 128 encryption_type AES_128 clean_start 1 [...] SH sport[11423]: [segstore/checker.NOTICE] - {- -} Creating a new data store. All existing \ data will be erased. [...] SH sport[11423]: [sport.NOTICE] - {- -} Sport ready. [...] SH mgmtd[12237]: [mgmtd.INFO]: Exiting bypass mode SH mgmtd[12237]: [mgmtd.INFO]: Traffic is now being optimized.
If some experimenting has been done with data store encryption and a data store has not been cleaned, the following message will be printed and the optimization service will not start:
Figure 5.172. After a move from AES_128 encryption to no encryption
SH sport[15692]: [segstore.INFO] - {- -} Starting Persistent Store, config: diskpolicy li \ near cachepgs 1250000 hashbits 59 nblocks 4096 replacement_policy RVBDLRU w_behind 102 \ 4 r_ahead 1 w_queue_depth 128 encryption_type NONE clean_start 0 [...] SH sport[15692]: [segstore/drive/0 [/dev/md0].ERR] - {- -} Encryption level mismatch. C \ urrently configured for: NONE but datastore is encrypted with: AES_128 SH sport[15692]: [mgmt.INFO] - {- -} Sending datastore alarm to true SH sport[15692]: [segstore/drive/0 [/dev/md0].ERR] - {- -} Segment store header invalid r \ etry the dup header SH sport[15692]: [segstore.ERR] - {- -} no good drives SH sport[15692]: [segstore/drive/0 [/dev/md0].INFO] - {- -} destroying pending i/o stats SH sport[15692]: [segstore.ALERT] - {- -} HALT Unable to initialize persistent store! [...] SH sport[15692]: [mgmt.WARN] - {- -} A corruption was found in the datastore. The datastor \ e may not have been cleaned after the encryption type was changed. SH sport[15692]: [mgmt.INFO] - {- -} Notifying management system that the datastore is cor \ rupt. SH sport[15692]: [mgmt.INFO] - {- -} Notifying management system that the service is stayi \ ng down.
The Secure Vault is an encrypted partition which contains the encrypted data store key and the SSL certificates and SSL private keys used for Secure Peering and SSL pre-optimization.
By default, the Secure Vault has been locked with a standard password which the Steelhead appliance can use to open the Secure Vault during its startup process. If this password is changed, the startup process cannot open the Secure Vault and the optimization service will not start until the Secure Vault is unlocked. The unlocking can be done either via the GUI or the CLI or automatically by the CMC.
Figure 5.173. Secure Vault is not unlocked yet
SH mgmtd[12258]: [mgmtd.INFO]: EVENT: /rbt/discovery/event/sport_mgmt_disc_init_done SH statsd[16376]: [statsd.NOTICE]: Alarm triggered for falling error for event secure_vaul \ t_unlocked SH mgmtd[12258]: [mgmtd.INFO]: EVENT: /stats/event/alarm_activity SH mgmtd[12258]: [mgmtd.INFO]: EVENT: /rbt/health/event/activity SH mgmtd[12258]: [mgmtd.INFO]: EVENT: /stats/events/secure_vault_unlocked/falling/error SH mgmtd[12258]: [mgmtd.INFO]: Secure vault must be unlocked SH mgmtd[12258]: [mgmtd.INFO]: SSL acceleration and the secure datastore cannot be used un \ til the secure vault has been unlocked. To unlock the secure vault, please visit: htt \ ps://SH/mgmt/gui?p=setupVault SH mgmtd[12258]: [mgmtd.INFO]: EVENT: /secure_vault/event/unlock_needed
By default, the inner channel of the optimized TCP sessions is not encrypted. There are two ways to encrypt the inner channel: Via the IPsec Secure Peering feature, on which the IP packets with the inner channel gets transported via an IPsec tunnel over the WAN, or via the SSL Secure Peering feature, where the TCP session with the inner channel gets SSL encrypted.
The configuration of the IPsec tunnels is symmetric, which means that the configuration on all the Steelhead appliances in the field which need secure peering between each other need to be in sync: Encryption policy, authentication policy and the shared secret. One incompatible mismatch between two IPsec peering configurations and all traffic is passed through unoptimized.
IPsec Secure Peering configuration is based on the IP addresses of the remote peer. If a renumbering of an in-path IP address happens or an additional in-path interface gets enabled, all peering Steelhead appliances need to be reconfigured to make sure that all optimized traffic towards this server stays encrypted.
Assume there is no IPsec tunnel setup towards the remote Steelhead appliance yet:
After the auto-discovery phase the inner channel gets setup: First the IPsec tunnel will be established towards the remote Steelhead appliance. Then the OOB Splice and Connection Pool will be setup over that IPsec tunnel. One of the TCP sessions of the inner channel will be converted into an inner channel and the inner channel is encrypted.
When the IPsec Secure Peering is configured on only one side of the inner channel, the client-side Steelhead appliance will try to setup an IPsec tunnel towards the server-side Steelhead appliance but fail. At the third TCP SYN packet from the client, the optimization service will pass-through the TCP session unoptimized.
Figure 5.174. IPsec negotiation fails between two Steelhead appliances because the other side isn't configured for IPsec Secure Peering
CSH racoon: 2012-06-16 10:10:45: INFO: IPSec-SA request for 192.168.1.6 queued due to no p \ hase1 found. CSH racoon: 2012-06-16 10:10:45: INFO: initiate new phase 1 negotiation: 10.0.1.6[500]<=>1 \ 92.168.1.6[500] CSH racoon: 2012-06-16 10:10:45: INFO: begin Identity Protection mode. CSH racoon: 2012-06-16 10:11:16: ERROR: phase2 negotiation failed due to time up waiting f \ or phase1. ESP 192.168.1.6[500]->10.0.1.6[500] CSH racoon: 2012-06-16 10:11:16: INFO: delete phase 2 handler. CSH racoon: 2012-06-16 10:11:45: ERROR: phase1 negotiation failed due to time up. f2763262 \ b03147b0:0000000000000000
Figure 5.175. Tcpdump shows that the IPsec service on the remote Steelhead appliance is not enabled
CSH # tcpdump -ni wan0_0 port 500 or icmp tcpdump: WARNING: wan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 300 bytes 10:29:37.907488 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident 10:29:38.040176 IP 192.168.1.6 > 10.0.1.6: ICMP 192.168.1.6 udp port 500 unreachable, leng \ th 140
The ICMP Port Unreachable message shows that the IPsec service on the remote Steelhead appliance is not operational.
The IPsec options can be depending on the model. For example the 50, 100, 200 and 300 models can only do encryption with the DES algorithm and cannot do encryption with the 3DES, AES or AES256 algorithms. When they setup an IPsec tunnel towards a Steelhead appliance which does not permit the low-level encryption algorithms, the setup of the IPsec tunnel will fail:
Figure 5.176. Incompatible options in the IPsec configuration
CSH sport[6467]: [splice/client.INFO] 914 {10.0.1.1:58923 192.168.1.1:25} init client 10.0 \ .1.1:58923 server 192.168.1.1:25 cfe 10.0.1.6:7801 sfe 192.168.1.6:7800 client connect \ ed: no CSH racoon: 2012-06-16 10:34:45: INFO: IPsec-SA request for 192.168.1.6 queued due to no p \ hase1 found. CSH racoon: 2012-06-16 10:34:45: INFO: initiate new phase 1 negotiation: 10.0.1.6[500]<=>1 \ 92.168.1.6[500] CSH racoon: 2012-06-16 10:34:45: INFO: begin Identity Protection mode. CSH racoon: 2012-06-16 10:34:45: INFO: received Vendor ID: DPD CSH racoon: 2012-06-16 10:34:46: INFO: ISAKMP-SA established 10.0.1.6[500]-192.168.1.6[500 \ ] spi:59b96bb1d3f8513c:42bfd4b628b8d2ee CSH racoon: 2012-06-16 10:34:46: INFO: initiate new phase 2 negotiation: 10.0.1.6[500]<=>1 \ 92.168.1.6[500] CSH sport[6467]: [splice/client.ERR] 914 {10.0.1.1:58923 192.168.1.1:25} (clnt: 10.0.1.1:5 \ 8923 peer: 192.168.1.6:7800 serv: 192.168.1.1:25) Error connecting to peer: Resource t \ emporarily unavailable. trpy: TRPY_NONE CSH sport[6467]: [splice/client.INFO] 914 {10.0.1.1:58923 192.168.1.1:25} fini client 10.0 \ .1.1:58923 server 192.168.1.1:25 cfe 10.0.1.6:0 sfe 192.168.1.6:7800 app TCP SSH sport[7137]: [splice/probe.INFO] 0 {- -} (locl: 192.168.1.6:0 clnt: 10.0.1.1:58923 ser \ v: 192.168.1.1:25) init SSH racoon: 2012-06-16 10:18:56: INFO: respond new phase 1 negotiation: 192.168.1.6[500]<= \ >10.0.1.6[500] SSH racoon: 2012-06-16 10:18:56: INFO: begin Identity Protection mode. SSH racoon: 2012-06-16 10:18:56: INFO: received Vendor ID: DPD SSH racoon: 2012-06-16 10:18:57: INFO: ISAKMP-SA established 192.168.1.6[500]-10.0.1.6[500 \ ] spi:59b96bb1d3f8513c:42bfd4b628b8d2ee SSH sport[7137]: [splice/probe.INFO] 0 {- -} (locl: 192.168.1.6:40302 clnt: 10.0.1.1:58923 \ serv: 192.168.1.1:25) fini SSH racoon: 2012-06-16 10:19:27: INFO: purging ISAKMP-SA spi=59b96bb1d3f8513c:42bfd4b628b8 \ d2ee. SSH racoon: 2012-06-16 10:19:27: INFO: purged ISAKMP-SA spi=59b96bb1d3f8513c:42bfd4b628b8d \ 2ee. SSH racoon: 2012-06-16 10:19:27: ERROR: unknown Informational exchange received. SSH racoon: 2012-06-16 10:19:28: INFO: ISAKMP-SA deleted 192.168.1.6[500]-10.0.1.6[500] sp \ i:59b96bb1d3f8513c:42bfd4b628b8d2ee SSH racoon: 2012-06-16 10:19:32: ERROR: unknown Informational exchange received. SSH racoon: 2012-06-16 10:19:37: ERROR: unknown Informational exchange received. SSH racoon: 2012-06-16 10:19:42: ERROR: unknown Informational exchange received. SSH racoon: 2012-06-16 10:19:47: ERROR: unknown Informational exchange received. SSH racoon: 2012-06-16 10:20:31: INFO: respond new phase 1 negotiation: 192.168.1.6[500]<= \ >10.0.1.6[500] SSH racoon: 2012-06-16 10:20:31: INFO: begin Identity Protection mode. SSH racoon: 2012-06-16 10:20:31: INFO: received Vendor ID: DPD SSH racoon: 2012-06-16 10:20:31: INFO: ISAKMP-SA established 192.168.1.6[500]-10.0.1.6[500 \ ] spi:0ecac81771e26077:144dc771e6186531 SSH racoon: 2012-06-16 10:20:32: INFO: respond new phase 2 negotiation: 192.168.1.6[500]<= \ >10.0.1.6[500] SSH racoon: 2012-06-16 10:20:32: WARNING: trns_id mismatched: my:3DES peer:DES SSH racoon: 2012-06-16 10:20:32: ERROR: not matched SSH racoon: 2012-06-16 10:20:32: ERROR: no suitable policy found. SSH racoon: 2012-06-16 10:20:32: ERROR: failed to pre-process packet.
Figure 5.177. Tcpdump shows that there are incompatible values in the configuration
CSH # tcpdump -ni wan0_0 port 500 or icmp tcpdump: WARNING: wan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 300 bytes 10:34:45.517507 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident 10:34:45.678227 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 1 R ident 10:34:45.706988 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident 10:34:45.849801 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 1 R ident 10:34:45.927267 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident[E] 10:34:46.209888 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 1 R ident[E] 10:34:46.209971 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 2/others R inf[E] 10:34:46.210702 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 2/others I inf[E] 10:34:51.342009 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 2/others R inf[E]
When the IPsec shared secret doesn't match, the setup of the IPsec tunnel will fail.
Figure 5.178. Incorrect shared secret
CSH sport[6467]: [splice/client.INFO] 987 {10.0.1.1:65379 192.168.1.1:25} init client 10.0 \ .1.1:65379 server 192.168.1.1:25 cfe 10.0.1.6:7801 sfe 192.168.1.6:7800 client connect \ ed: no CSH racoon: 2012-06-16 10:58:55: INFO: IPsec-SA request for 192.168.1.6 queued due to no p \ hase1 found. CSH racoon: 2012-06-16 10:58:55: INFO: initiate new phase 1 negotiation: 10.0.1.6[500]<=>1 \ 92.168.1.6[500] CSH racoon: 2012-06-16 10:58:55: INFO: begin Identity Protection mode. CSH racoon: 2012-06-16 10:58:56: INFO: received Vendor ID: DPD CSH sport[6467]: [splice/client.ERR] 987 {10.0.1.1:65379 192.168.1.1:25} (clnt: 10.0.1.1:6 \ 5379 peer: 192.168.1.6:7800 serv: 192.168.1.1:25) Error connecting to peer: Resource t \ emporarily unavailable. trpy: TRPY_NONE CSH sport[6467]: [splice/client.INFO] 987 {10.0.1.1:65379 192.168.1.1:25} fini client 10.0 \ .1.1:65379 server 192.168.1.1:25 cfe 10.0.1.6:0 sfe 192.168.1.6:7800 app TCP SSH racoon: 2012-06-16 10:48:17: INFO: respond new phase 1 negotiation: 192.168.1.6[500]<= \ >10.0.1.6[500] SSH racoon: 2012-06-16 10:48:17: INFO: begin Identity Protection mode. SSH racoon: 2012-06-16 10:48:17: INFO: received Vendor ID: DPD
Figure 5.179. Tcpdump shows that the IPsec negotiation fails because of an incorrect shared secret
CSH # tcpdump -ni wan0_0 port 500 or icmp tcpdump: WARNING: wan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 300 bytes 10:58:55.948616 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident 10:58:56.082075 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 1 R ident 10:58:56.093290 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident 10:58:56.237696 IP 192.168.1.6.500 > 10.0.1.6.500: isakmp: phase 1 R ident 10:58:56.249238 IP 10.0.1.6.500 > 192.168.1.6.500: isakmp: phase 1 I ident[E]
SSL Secure Peering is the encryption of the inner channel of an optimized TCP session via the Secure Sockets Layer protocol. Unlike IPsec Secure Peering where the IP packets of the inner channel got tunneled, with SSL Secure Peering it is only encrypting the TCP payload of the inner channel.
The advantages of this method are:
The encryption starts after a TCP session of the Connection Pool has been converted into an inner channel. This makes it possible to use the Secure Peering feature for only certain protocols. This also makes it possible to fall-back to no encryption if the remote peer has not been configured properly.
With IPsec Secure Peering all IP traffic from the Steelhead appliance towards the remote Steelhead appliance went through the IPsec tunnel, including ICMP traffic. With SSL Secure Peering only the optimized TCP session gets encrypted.
With IPsec Secure Peering all traffic is seen as UDP traffic on UDP port 500, with SSL Secure Peering the inner channel is still visible on the WAN, making it possible to use a different WAN visibility to the TCP session and to apply QoS to the TCP session.
With SSL Secure Peering, the dependency on knowing the IP addresses of the in-path interfaces of the remote Steelhead appliance is gone, the identification now happens on the SSL certificate of the remote Steelhead appliance.
The SSL Secure Peering can be enabled for SSL protocols only (via an in-path rule which has SSL pre-optimization enabled), for secure protocols (SSL, encrypted MAPI, encrypted Lotus Notes, encrypted Citrix) or for all protocols.
Before two Steelhead appliances setup a SSL session between them, they need to trust each other. This can be done via three methods:
SSL Peering certificates from unknown Steelhead appliances are stored in the SSL Peering Gray list. If the unknown Steelhead appliance is considered to be trusted, you can move it to the SSL Peering White list and SSL Secure Peering can be performed towards that Steelhead appliance. If the unknown Steelhead appliance is considered not to be trusted, you can move it to the SSL Peering Black list and SSL Secure Peering will never be performed towards that Steelhead appliance. This is extensive manual labour of the order O(N!) but available to the Steelhead appliance without the need for external software. Using a CMC will make his much easier.
The SSL Peering feature can be configured with a trusted CA certificate. As such, this Steelhead appliance will trust SSL peering certificates signed by this CA. This is an one time configuration per Steelhead appliance making it an issue of the order O(N) but an external certificate authority is required.
There is also the Mobile Trust feature, which is the same approach but specifically for the SSL Peering CA certificates for Mobile Steelhead Mobile Controllers.
Support for the Simple Certificate Enrollment Protocol, which allows the importing of the SSL Certificate generated by an automated Certificate Authority.
The auto-discovery phase and the setup of the OOB Splice and Connection Pool are the same as a normal deployment. During the conversion from the TCP session of the Connection Pool to an inner channel, the request for an secure inner channel gets added. Once the SSL session has been setup, the inner channel data gets transported over it.
In case the SSL peering certificate of a remote Steelhead appliance does not exist in the SSL Peering White list, the setup of the SSL session will fail with these messages:
Figure 5.180. Failure due to an unknown SSL peering certificate
CSH sport[13790]: [splice/client.INFO] 26 {10.0.1.1:15092 192.168.1.1:25} init client 10.0 \ .1.1:15092 server 192.168.1.1:25 cfe 10.0.1.6:7801 sfe 192.168.1.6:7800 client connect \ ed: yes CSH sport[13790]: [splice/client.INFO] 26 {10.0.1.1:15092 192.168.1.1:25} Splice client si \ de initializing: No protocol port = 25 protocol id = TCP(0) transport = TRANSPORT_ID_S \ SLINNER CSH sport[13790]: [splice/client.INFO] 26 {10.0.1.1:15092 192.168.1.1:25} Start flowing, l \ port 40336, rport 7800, OPOL_NORMAL, NAGLE_ALWAYS, PREOPT_NONE, LATOPT_AUTO, TRANSPORT \ _ID_SSLINNER, TPTOPT_NONE(0x0) CSH sport[13790]: [ssl.WARN] - {- -} Failure in certificate verification: error num: 18 e \ rror string: self signed certificate depth: 0 subject name: /CN=Steelhead A17WT000628B \ C/O=Riverbed Technology, Inc./L=San Francisco/ST=California/C=-- CSH sport[13790]: [keystore/0x9bdaa80.WARN] - {- -} Failure in certificate verification, s \ ubject: "/CN=Steelhead A17WT000628BC/O=Riverbed Technology, Inc./L=San Francisco/ST=Ca \ lifornia/C=--" CSH sport[13790]: [keystore/0x9bdaa80.WARN] - {- -} Failed with error num: 18, error strin \ g: "self signed certificate", depth: 0 CSH sport[13790]: [sslinnerchan/CliConnect.WARN] 26 {10.0.1.1:15092 192.168.1.1:25} The se \ rver-side steelhead at ip address: 192.168.1.6 couldn't verify this steelhead's peerin \ g certificate. Perhaps the peering trust list on server-side steelhead is misconfigure \ d CSH sport[13790]: [sslinnerchan/CliConnect.WARN] 26 {10.0.1.1:15092 192.168.1.1:25} SSL co \ nnection to an untrusted Steelhead appliance at IP address: 192.168.1.6 while attempti \ ng to optimize the end-to-end SSL connection between client: 10.0.1.1:15092 and server \ : 192. CSH sport[13790]: [sslinnerchan/CliConnect.WARN] 26 {10.0.1.1:15092 192.168.1.1:25} 168.1. \ 1:25 CSH sport[13790]: [mgmt.INFO] - {- -} mgmtd notified that ssl peer 192.168.1.6 failed hand \ shake CSH mgmtd[3768]: [mgmtd.INFO]: EVENT: /rbt/sport/ssl/event/peer_info CSH mgmtd[3768]: [mgmtd.NOTICE]: Peer 192.168.1.6 is created/updated in the gray list. SSH sport[10600]: [splice/probe.INFO] 0 {- -} (locl: 192.168.1.6:0 clnt: 10.0.1.1:15092 se \ rv: 192.168.1.1:25) init SSH sport[10600]: [splice/server.INFO] 1 {- -} init cfe 10.0.1.6:40336 sfe 192.168.1.6:780 \ 0 SSH sport[10600]: [splice/server.INFO] 1 {- -} sock 41 id 548627 client 10.0.1.1:15092 se \ rver 192.168.1.1:25 remote inner port 7800 trpy TRPY_NONE SSH sport[10600]: [splice/probe.INFO] 0 {- -} (locl: 192.168.1.6:40268 clnt: 10.0.1.1:1509 \ 2 serv: 192.168.1.1:25) acquired SSH sport[10600]: [splice/probe.INFO] 0 {- -} (locl: 192.168.1.6:40268 clnt: 10.0.1.1:1509 \ 2 serv: 192.168.1.1:25) fini SSH sport[10600]: [splice/server.INFO] 1 {- -} Splice server side initializing: No protoco \ l port = 25 transport = TRANSPORT_ID_SSLINNER SSH sport[10600]: [splice/server.INFO] 1 {10.0.1.1:15092 192.168.1.1:25} Start flowing, lp \ ort 7800, rport 40336, OPOL_NORMAL, NAGLE_ALWAYS, PREOPT_NONE, LATOPT_AUTO, TRANSPORT_ \ ID_SSLINNER, TPTOPT_NONE(0x0) SSH sport[10600]: [ssl.WARN] - {- -} Failure in certificate verification: error num: 18 e \ rror string: self signed certificate depth: 0 subject name: /CN=Steelhead A41SU00085F1 \ 3/O=Riverbed Technology, Inc./L=San Francisco/ST=California/C=-- SSH sport[10600]: [keystore/0x9bda9a0.WARN] - {- -} Failure in certificate verification, s \ ubject: "/CN=Steelhead A41SU00085F13/O=Riverbed Technology, Inc./L=San Francisco/ST=Ca \ lifornia/C=--" SSH sport[10600]: [keystore/0x9bda9a0.WARN] - {- -} Failed with error num: 18, error strin \ g: "self signed certificate", depth: 0 SSH sport[10600]: [sslinnerchan/SrvAccept.WARN] 1 {10.0.1.1:15092 192.168.1.1:25} SSL conn \ ection from an untrusted Steelhead appliance at IP address: 10.0.1.6 while attempting \ to optimize the end-to-end SSL connection between client: 10.0.1.1:15092 and server: 1 \ 92.168 SSH sport[10600]: [sslinnerchan/SrvAccept.WARN] 1 {10.0.1.1:15092 192.168.1.1:25} .1.1:25 SSH sport[10600]: [mgmt.INFO] - {- -} mgmtd notified that ssl peer 10.0.1.6 failed handsha \ ke SSH sport[10600]: [sslinnerchan/SrvAccept.WARN] 1 {10.0.1.1:15092 192.168.1.1:25} Informin \ g the client-side steelhead about failure to verify its peering certificate, so that f \ uture connections are temporarily bypassed. SSH mgmtd[4019]: [mgmtd.INFO]: EVENT: /rbt/sport/ssl/event/peer_info SSH mgmtd[4019]: [mgmtd.NOTICE]: Peer 10.0.1.6 is created/updated in the gray list.
The list of entries in the Secure Peering Gray list can be found
with the command
show secure-peering gray-lst-peers
.
This output does only contain the IP address of the in-path interface
and the hostname while the log files only contain the IP address
of the in-path interface and the Steelhead appliance serial number.
Figure 5.181. Output of the command "show secure-peering gray-lst-peers"
CSH # show secure-peering gray-lst-peers IP Hostname Exp Date --------------- ----------------------------------- ------------------------ 192.168.1.6 SSH Nov 29 03:44:24 2012 GMT SSH # show secure-peering gray-lst-peers IP Hostname Exp Date --------------- ----------------------------------- ------------------------ 10.0.1.6 CSH Jun 20 01:42:12 2013 GMT
Use the command
secure-peering gray-lst-peer <IP address> trust
to move an entry from the Secure Peering Gray list to the Secure
Peering White list. After the move, new TCP connections should be
optimized with a secure inner channel, this can be seen with the
transport option set to TRANSPORT_ID_SSLINNER:
Figure 5.182. Optimized TCP session with an encrypted inner channel
CSH sport[25745]: [splice/client.INFO] 1 {10.0.1.1:44130 192.168.1.1:25} init client 10.0. \ 1.1:44130 server 192.168.1.1:25 cfe 10.0.1.6:7801 sfe 192.168.1.6:7800 client connecte \ d: yes CSH sport[25745]: [splice/client.INFO] 1 {10.0.1.1:44130 192.168.1.1:25} Splice client sid \ e initializing: No protocol port = 25 protocol id = TCP(0) transport = TRANSPORT_ID_SS \ LINNER CSH sport[25745]: [splice/client.INFO] 1 {10.0.1.1:44130 192.168.1.1:25} Start flowing, lp \ ort 40269, rport 7800, OPOL_NORMAL, NAGLE_ALWAYS, PREOPT_NONE, LATOPT_AUTO, TRANSPORT_ \ ID_SSLINNER, TPTOPT_NONE(0x0)
When a remote Steelhead appliance does not have a valid SSL license, the secure inner channel cannot be setup and the following message will be displayed in the logs:
Figure 5.183. Remove Steelhead appliance does not have a valid SSL license
SH sport[994]: [splice/client.WARN] 482649 {10.0.1.1:2800 192.168.1.1:135} SSL license is \ either absent or invalid on peer Steelhead appliance with IP address: 192.168.1.6 SH sport[994]: [splice/client.NOTICE] 482649 {10.0.1.1:2800 192.168.1.1:135} Together, loc \ al and peer steelhead appliance at: 192.168.1.6:7800 request encryption of secure appl \ ication traffic over WAN. And this connection between client: 10.0.1.1 and SH sport[994]: [splice/client.NOTICE] 482649 {10.0.1.1:2800 192.168.1.1:135} server: 192. \ 168.1.1. 201:135 belongs to a secure application protocol: EPM(4) But one (or both) o \ f them is missing a valid enhanced cryptographic license.