Authentication, Security, Operations, and Monitoring
  
Authentication, Security, Operations, and Monitoring
This chapter describes how to configure RADIUS or TACACS+ authentication for the SteelHead, including best practices for securing the SteelHead, and provides information about operations and flow data monitoring.
This chapter includes the following sections:
•  Overview of Secure Transport
•  Overview of Authentication
•  Authentication Features
•  Configuring a RADIUS Server
•  Configuring a TACACS+ Server
•  Securing SteelHeads
•  REST API Access
•  Capacity Planning
•  Overview of Exporting Flow Data
•  SNMP Monitoring
•  Configuring SNMPv3 Authentication and Privacy
Overview of Secure Transport
Today’s enterprises are embracing hybrid networking. Key features of the hybrid network are leveraging multiple paths between sites to achieve diversity across a variety of networks and to deliver application traffic over the most efficient path. However, as new network models are built, the security of traffic on the path is a concern.
RiOS 9.0 working together with SCC 9.0 introduces the secure transport feature. Secure transport is integrated with path selection and provides a way to configure and enable encryption services for traffic over a path. Functionality is separated into the management plane, control plane, and data plane. You configure the management plane on the SCC, in which you also configure and distribute the path selection policy.
When a network is marked as securable (Networking > Network Services: Sites & Networks page), it indicates that the SteelHead will join a group of other SteelHeads that can encrypt traffic. The SCC pushes that policy to all the SteelHeads, and you can also select one of the available SteelHeads to be the secure transport controller (the controller) for the control plane. Over the control plane, the SteelHead selected as the controller communicates with the SteelHeads in the group and coordinates the encryption keys to use over the data plane. Traffic is secured on the data plane for the path marked as securable. The SteelHeads use the encryption keys received from the controller and the Path Selection policy received from the SCC.
Secure transport uses standards-based IPSec with the highest level of commercially available security based on AES-256 and SHA-2 to secure traffic over a path. The control plane between the SteelHead acting as controller and other SteelHeads performing encryption is secured using SSL over TCP port 9443. The management plane from the SCC is secured using SSL and SSH.
One key advantage of secure transport is that management of encryption services is done centrally through the SCC, which serves as the user interface for configuration of secure transport.
For further configuration details, see the SteelCentral Controller for SteelHead User’s Guide and the SteelCentral Controller for SteelHead Deployment Guide.
Note: In RiOS 9.0, IPSec secure peering and the secure transport service are mutually exclusive. The secure transport service is enabled by default. Before you enable IPSec secure peering, you must disable the secure transport service. Also, SSL secure peering and secure transport traffic can coexist.
Overview of Authentication
You can log in to a SteelHead with a RADIUS or TACACS+ authentication system for administrative and monitoring purposes. The following methods for user authentication are provided with the SteelHead:
•  Local
•  RADIUS
•  TACACS+
For information about per-command authorization and per-command accounting, see the Riverbed Command-Line Interface Reference Manual.
The order in which authentication is attempted is based on the order specified in the AAA method list. The authentication list provides backup authentication methods in case one method fails to authenticate the server. If the first server is unavailable, the next server in the list is contacted depending on the RADIUS/TACACS+ settings.
If there are multiple servers within a method (assuming the method is contacting authentication servers) and a server time-out is encountered, the next server in the list is tried. If the current server being contacted issues an authentication reject, another server is contacted according to the RADIUS/TACACS+ setting. If none of the methods validate a user, the user is not allowed access to the server.
The SteelHead does not have the ability to set a per interface authentication policy. The same default authentication method list is used for all interfaces. You cannot configure authentication methods with subsets of the RADIUS or TACACS+ servers specified (that is, there are no server groups).
For information about Windows domain authentication for encrypted MAPI and SMB signed CIFS traffic see the SteelHead Deployment Guide - Protocols.
Authentication Features
RiOS 5.0.x or later supports the following features (available only through the CLI):
•  Per-command Authorization - Your TACACS+ server can authorize all CLI commands with the aaa authorization per-command default command. The methods available for per-command authorization are local (default) and TACACS+.
To use TACACS+ for per-command authorization, configure the SteelHead for TACACS+ and define the users and commands authorized to run on your TACACS+ server. For information about how to configure your TACACS+ server, see the TACACS+ server documentation.
Per-command authorization applies to the CLI only.
If you do not have a TACACS+ server, use role-based accounts locally on the SteelHead to limit the Management Console and CLI commands available to users.
For more information about configuring TACACS+ on the SteelHead, see Configuring a TACACS+ Server. For details, see how to restrict user roles on Best Practices for Securing Access to SteelHeads.
•  Per-command Accounting - You always enable per-command accounting locally. You must specifically enable the command for TACACS+ by defining the TACACS+ method using the aaa accounting per-command default command. TACACS+ per-command accounting is always sent to all the configured TACACS+ servers. The local method logs the command in the system logs.
•  TACACS+ Server First Hit - When the server first hit CLI command (tacacs-server first-hit) is enabled, the SteelHead rejects authentication after the first rejection received from a TACACS+ server rather than continuing through all the TACACS+ servers in the list. This feature applies to user authentication and per-command authorization.
•  Fallback - The fallback option decides how the successive authentication methods are tried. When you enable fallback, if authentication fails, the system continues through all authentication methods (TACACS+, RADIUS, local) in the order you configure them in the authentication method list. Fallback is enabled by default. When you enable conditional fallback (aaa authentication cond-fallback) you can configure the system to only proceed beyond TACACS+ or RADIUS if the servers are unreachable. Conditional fallback enables you to reject the login once the first method rejects the attempt, instead of proceeding to the next method in the authentication method list.
•  Remote and Console Method Lists - There are two method lists: remote (ssh, web UI) and console (serial, terminal, SteelHead, telnet). The console method requires a local method to be present, but the remote list does not. You enable the remote method using the aaa authentication login default command. You enable the console method using the aaa authentication console-login default command.
Configuring a RADIUS Server
This section describes how to configure a RADIUS server for the SteelHead. This section includes the following topics:
•  Configuring a RADIUS Server with FreeRADIUS
•  Configuring RADIUS Authentication in the SteelHead
•  Configuring RADIUS CHAP Authentication
Configuring a RADIUS Server with FreeRADIUS
On a per-user basis, you can specify a different local account mapping by using a vendor-specific attribute. This section describes how to configure the FreeRADIUS server to return an attribute (which specifies the local user account as an ASCII string). The file paths are the default values. If the RADIUS server installation has been customized, the paths might differ.
Dictionary files are stored in the directory /usr/local/share/freeradius. You can define RADIUS attributes in this directory. Assuming the vendor does not have an established dictionary file in the FreeRADIUS distribution, begin the process by creating a file called dictionary.<vendor> in this directory.
The contents of the dictionary.<vendor> file define a vendor identifier (which should be the Structure of Management Information [SMI] Network Management Private Enterprise Code of the Vendor) and any vendor-specific attributes.
In the following example, the Vendor Enterprise Number for Riverbed is 17163 and the Enterprise Local User Name Attribute is 1. These numbers specify that a given user is an admin or monitor user in the RADIUS server (instead of using the SteelHead default for users not named admin and monitor).
These instructions assume you are running FreeRADIUS v.1.0, which is available from http://www.freeradius.org. You can also find more details in the SteelHead Management Console User’s Guide.
To install FreeRADIUS on a Linux computer
1. Download FreeRADIUS from http://www.freeradius.org.
2. At your system prompt, enter the following commands:
tar xvzf freeradius-$VERSION.tar.gz
cd freeradius-$VERSION
./configure
make
make install #as root
To add acceptance requests on the RADIUS server
1. In a text editor, open the /usr/local/etc/raddb/clients.conf file.
2. To create the key for the RADIUS server, add the following text to the clients.conf file:
client 10.0.0.0/16 {
secret = testradius
shortname = main-network
nastype = other
}
The secret you specify here must also be specified in the SteelHead when you set up RADIUS server support.
3. In a text editor, create a /usr/local/share/freeradius/dictionary.rbt file for Riverbed.
4. Add the following text to the dictionary.rbt file.
VENDOR RBT 17163
ATTRIBUTE Local-User 1 string RBT
5. Add the following line to the /usr/local/share/freeradius/dictionary:
$INCLUDE dictionary.rbt
6. Add users to the RADIUS server by editing the /usr/local/etc/raddb/users file, for example:
“admin” Auth-Type := Local, User-Password == "radadmin"
Reply-Message = "Hello, %u"
"monitor" Auth-Type := Local, User-Password == "radmonitor"
Reply-Message = "Hello, %u"
"raduser" Auth-Type := Local, User-Password == "radpass"
Local-User = "monitor", Reply-Message = "Hello, %u"
7. Start the server using /usr/local/sbin/radiusd. Use the -X option if you want to debug the server.
Note: The raduser is the monitor user as specified by Local, User-Password.
Configuring RADIUS Authentication in the SteelHead
This section describes the basic steps for configuring RADIUS authentication in the SteelHead. For details, see the SteelHead Installation and Configuration Guide and the SteelHead Management Console User’s Guide.
You prioritize RADIUS authentication methods for the system and set the authorization policy and default user.
Note: Put the authentication methods in the order in which you want authentication to occur. If authorization fails on the first method, the next method is attempted, and the order is continued until all the methods have been attempted.
Perform the following basic steps to configure RADIUS support.
To configure RADIUS support
1. Add the IP address of the RADIUS server and specify the key used when you added the device to the ACS server:
(config)# radius-server host 192.168.1.200 key rvbd
2. Enable AAA.
3. Define the authentication method.
The following configuration attempts to use RADIUS and then local:
(config)# aaa authentication login default radius local
Configuring RADIUS CHAP Authentication
In RiOS 8.0 or later you can configure RADIUS CHAP authentication through the CLI or, in RiOS 8.5 or later, the SteelHead Management Console. Choose which method to use based on the appropriate risk mitigation strategy provided by either option. For example, CHAP transmits the password in a more secure manner, but various RADIUS servers can store the password in an unencrypted format.
radius-server host 192.168.198.136 auth-type chap timeout 3 retransmit 1 key testradius
To configure CHAP authentication in the SteelHead Management Console, configure the RADIUS server (Administration > Security: RADIUS).
Figure: RADIUS CHAP Authentication
After you add the server, include RADIUS in the order of authentication methods. A best practice to ensure that you can still perform authentication in the absence of the RADIUS server is to:
•  use the RADIUS server first for authentication, but
•  fall back to the SteelHead username and password database if the RADIUS server is unavailable.
Figure: RADIUS Authentication
Configuring a TACACS+ Server
This section describes how to configure a TACACS+ server for the SteelHead. This section includes the following topics:
•  Configuring TACACS+ with Cisco Secure Access Control Servers
•  Configuring TACACS+ Authentication in the SteelHead
Configuring TACACS+ with Cisco Secure Access Control Servers
This task requires that you are running a Cisco Secure Access Control Server (ACS) and you want to configure it for TACACS+.
The TACACS+ Local User Service is rbt-exec. The Local User Name Attribute is local-user-name. This attribute controls whether a user who is not named admin or monitor is an administrator or monitor user (instead of using the SteelHead default value). For the SteelHead, the users listed in the TACACS+ server must have PAP authentication enabled.
Use the following procedures to configure TACACS+ with Cisco Secure ACS.
•  To configure TACACS+ with Cisco ACS 4.x, go to http://supportkb.riverbed.com/support/index?page=content&id=S14831.
•  To configure TACACS+ with Cisco ACS 5.x, go to http://supportkb.riverbed.com/support/index?page=content&id=S:S16158.
Configuring TACACS+ Authentication in the SteelHead
This section describes the basic steps for configuring TACACS+ authentication in the SteelHead. You prioritize TACACS+ authentication methods for the system and set the authorization policy and default user.
For more information and detailed procedures, see the SteelHead Installation and Configuration Guide and the SteelHead Management Console User’s Guide.
Note: Put the authentication methods in the order in which you want authentication to occur. If authorization fails on the first method, the next method is attempted, and the order is continued until all the methods have been attempted.
Perform the following basic steps to configure TACACS+ support.
To configure TACACS+ support
1. Add the IP address of the ACS server and specify the key used when you added the device to the ACS server.
(config)# tacacs-server host 192.168.1.200 key rvbd
2. Enable AAA.
3. Define the authentication method.
The following configuration attempts to use TACACS+ and then local:
(config)# aaa authentication login default tacacs+ local
Securing SteelHeads
This section describes security features you can use to harden your network, including ways to secure the SteelHeads and some common sense security policies. This section includes the following topics:
•  Overview of Securing SteelHeads
•  Best Practices for Securing Access to SteelHeads
•  Best Practices for Enabling SteelHead Security Features
•  Best Practices for Policy Controls
•  Best Practices for Security Monitoring
•  Configuring SSL Certificates for Web User Interface
Overview of Securing SteelHeads
Organizations have typically focused attention on securing their networks by providing security for and preventing attacks against hosts. Unfortunately, there are also many security risks associated with networking devices. Attacks against such devices can be used to gather valuable information. For example, an attacker could use tools to fill up the MAC address tables of Ethernet switches, causing the switches to flood packets. These packets might contain passwords that can easily be captured.
The SteelHead has been certified and subsequently deployed for internal use by several highly security-conscious organizations, including military, government, and financial organizations. However, SteelHeads are complex network-facing systems and must be treated accordingly.
Note: Because security requirements vary by organization, consider these recommendations with your particular security goals in mind. Before implementing any security measure described in this section, you must have a thorough understanding of its impact. For example, you do not want to disable access to a SteelHead by mistake and not be able to undo the change because you inadvertently blocked your own access.

If you have a specific security concern, Riverbed recommends that you consult with Riverbed Professional Services.
Best Practices for Securing Access to SteelHeads
This section describes best practices for securing access to your SteelHeads. These practices are not requirements, but Riverbed recommends that you consider these suggestions as implementing them can enforce a secure deployment:
•  Restrict physical access - You must restrict physical access to any network device. An unauthorized user can easily gain access to a SteelHead if that person has physical access. Every device has the ability to recover lost passwords. By acquiring physical access to a device, an attacker can gain control by using the lost password recovery procedures. Even without breaking into the SteelHead software, it is possible to gain access to the contents of disks by gaining access to the SteelHead itself. You should treat the SteelHead as comparable in value to the servers or clients that hold sensitive data. For example, if servers are in locked rooms, Riverbed recommends the SteelHeads also be in those locked rooms.
Someone with physical access could also remove the SteelHead without authorization, allowing an attacker to gain access to confidential data. In general, SteelHeads are less valuable to an attacker than application servers or file servers because of an intrinsic scrambling of the RiOS data store. SteelHeads also support encryption of the RiOS data store to further reduce the likelihood of a successful attack, and SteelCentral Controller for SteelHead Mobile likewise allows the use of file encryption for the RiOS data store on a Window PC.
Physical access increases the susceptibility of the networking device to denial-of-service attacks. A disgruntled employee could conceivably power the SteelHead down, disarrange the cabling, swap hard drives, or even steal the SteelHead.
•  Use an appropriate login message - The login message appears on the Management Console Home page. You must display a login message that reinforces your organization access and security policies. Have your organization legal council approve an appropriate login message.
Typical login messages include, but are not limited to:
–  statements pertaining to authorized access only
–  consequences of unauthorized access
–  elimination of right to privacy
–  acknowledgment that the user might be monitored
The default login message is “Welcome to the Management Console for SteelHead_name!” You can change this message by navigating to the Administration > System Settings: Announcements page in the Management Console and specifying another message. You can also use the CLI as shown in the following example.
Syntax:
[no] banner login <message-string>
Example:
banner login. "This computer system is the property of Company XYZ Inc. Disconnect NOW if you have not been expressly authorized to use this system. Unauthorized use is a criminal offence under the Computer Misuse Act 1990.
Communications on or through Company XYZ Inc. computer systems may be monitored or recorded to secure effective system operation and for other lawful purposes.”
•  Allow management only from the primary interface - Limiting SSH and HTTPS access to the Primary interface allows administrators to restrict who can access the SteelHeads by the use of filters or Access Control Lists. These filters are typically based on the source IP addresses of hosts and are applied on network devices like routers, Layer-3 switches, or firewalls. Limiting remote management access to SteelHeads helps prevent unauthorized user access.
Syntax:
[no] web httpd listen enable
[no] web httpd listen interface <interface>
[no] ssh server listen enable
[no] ssh server listen interface <interface>
Example:
web httpd listen enable
web httpd listen interface primary
ssh server listen enable
ssh server listen interface primary
•  Use SSH version 2 - SSH version 2 is more secure than previous versions of SSH. The major differences between SSH1 and SSH2 fall into two main categories: technical and licensing. SSH2 uses different encryption and authentication algorithms.
SSH1 offers four encryption algorithms (DES, 3DES, IDEA, and Blowfish); however, SSH2 dropped support for DES and IDEA but added three algorithms. SSH1 also uses the RSA authentication algorithm; however, SSH2 uses the Digital Signature Algorithm (DSA). These changes were designed to increase the base level of security in SSH2 by using stronger algorithms.
Syntax:
[no] ssh server v2-only enable
Example:
ssh server v2-only enable
•  Disable unencrypted communication protocols such as Telnet and HTTP - An attacker can easily gain access to usernames and passwords by sniffing network communications. You might consider a switched Ethernet environment secure because packets are only forwarded out ports based on the destination MAC address; however, this is not necessarily the case.
Several hacking tools are available that can generate large amounts of bogus MAC addresses. These packets flood the switch's MAC address table in an attempt to overflow the table. A switch typically floods packets out all ports if it does not have an entry in its MAC address table. Therefore, after the MAC address table for the switch is filled, the switch floods packets out all ports.
The attacker can now use a packet-capturing application to capture the flooded packets and can then look for remote management connections. After the attacker discovers remote management connections, the attacker can reset those TCP connections, causing the user to log in again allowing the attacker to capture the username and password.
If only HTTPS and SSH are used, the attacker cannot obtain the usernames and passwords because they are encrypted.
Syntax:
[no] telnet-server enable
[no] web http enable
Example:
no telnet-server enable
no web http enable
In RiOS 8.5 or later, you can configure the SteelHead to redirect HTTP access to HTTPS access with the web http redirect command. Riverbed recommends this method unless your security policy requires the SteelHead to not listen to HTTP.
•  Use TLS only for the Management Console - Only permit TLS between the browser and the Management Console.
Syntax:
web ssl protocol tlsv1
no web ssl protocol sslv3
web ssl protocol tlsv1.1
web ssl protocol tlsv1.2
•  Restrict user roles - Be sure to restrict the roles of users. For example, if a Help desk administrator is supposed to only view statistics and generate reports, their account restricts them to those roles.
Syntax:
[no] rbm user <username> role <role> permissions <permissions>
[no] rbm role <role> primitive <primitive>
Refer to the Riverbed Command-Line Interface Reference Manual for more information about this command.
•  Remove the default username from the web preference settings - The default username in the login field is admin. Do not display a default username because it gives an attacker an example of a username against which to wage a brute-force password attack. Brute-force attacks typically go through an extensive list of words (for example, a dictionary attack) in an attempt to guess the password.
Syntax:
web prefs login default
Example:
web prefs login default ""
•  Change settings for SOAP server - Disable the Simple Object Access Protocol (SOAP) server if it is not in use. You can use the SOAP server to send configuration commands to the SteelHead. Riverbed recommends that you change the port (default TCP port 9001), if you want to enable the SOAP server.
Syntax:
[no] web soap-server enable
Example:
no web soap-server enable
Syntax:
[no] web soap-server port <port>
Example:
web soap-server port 1234
•  Disable unused default accounts - Disable any default accounts that are not in use.
The monitor account is disabled by default, unless you upgrade the SteelHead from an earlier release in which the monitor account was enabled. The monitor account is a read-only account that allows you to view all settings, but does not allow you to make any changes.
The shark account allows SteelCentral Packet Analyzer to remotely access TCP dumps on the SteelHead. The shark account allows you to view of all traffic traversing the SteelHead.
Syntax:
[no] username <user-id> disable
Example:
username monitor disable
username shark disable
•  Change all default passwords and community strings - Be sure to change the default password for the administrator, shark, and monitor accounts.
The most common problem with SNMP is that it uses the default community string of public. Change the default to something different.
Syntax:
username <user-id> password 0 <cleartext-password>
Example:
username admin password 0 o2fMu5TS!
username monitor password 0 o2fMu5TD!
username shark password 0 o2fMu5TP!
Syntax:
[no] snmp-server community <name>
[no] snmp-server trap-community <trap-community-name>
Example:
snmp-server community o2fMu5TS!
•  Use strong passwords - Strong passwords typically include combinations of letters, numbers, special characters, and combinations of uppercase and lowercase letters with at least eight characters in length. Strong passwords reduce the likelihood of a successful brute-force attack because they are not found in dictionaries and exponentially increase the complexity of the passwords.
An example of a strong password is o2fMu5TS!
•  Use AAA authentication - One of the challenges with using local usernames and passwords is that when an employee leaves an organization, an administrator must touch every device that has a username and password configured for that former employee.
By leveraging TACACS+, you gain the advantage of having a single location for configuring usernames and passwords. When a person leaves your organization, you can simply disable that single account thereby preventing the user from access to all of the network devices configured to use TACACS+. Another benefit of TACACS+ is the ability to lock out an account after several unsuccessful login attempts.
TACACS+ also provides greater reporting capabilities regarding who is accessing which devices at what time. With a global username and password, you have no idea which administrator actually logged in at a specific time. These reports can be invaluable for tracking network changes and identifying who is making changes. Therefore, it is a critical tool for change management controls.
Refer to Riverbed Command-Line Interface Reference Manual and the SteelHead Management Console User’s Guide for more detailed information about how to configure AAA.
•  Configure the CLI session time-out - By default, the SteelHead closes the SSH session to the command line after 15 minutes. You can configure this interval to be more or less with the following command:
Syntax:
cli default auto-logout *
Example:
cli default auto-logout 10
This command only affects new SSH sessions. If you want to modify the time-out session only for the current session (and not affect the default settings), use the following command:
Syntax:
cli session auto-logout *
You can disable the auto-logout feature with the following command:
no cli default auto-logout
This command changes both the current and the default settings.
You can display the current auto-logout settings with the following command:
show cli
•  Use strong SSL ciphers for management communications - Be sure to use strong encryption ciphers for any HTTPS management communications. The cipher is the key that encrypts management communications to the SteelHead. An attacker could still use the hacking tools to crack the encrypted username and password if the encryption ciphers are too weak. An example of a weak cipher is only 56 or 64 bits. A strong cipher is greater than 128 bits.
Syntax:
web ssl cipher
Example:
web ssl cipher "HIGH:-aNULL:-kKRB5:-MD5"
•  Set an inactivity timer for console, SSH, and HTTPS sessions - Be sure to set a proper inactivity time-out value for management sessions. Do not set a console inactivity time-out value to 0. This setting could allow an attacker to take over a previous management session if the previous administrator did not manually log off.
Syntax:
[no] web auto-logout <minutes>
[no] cli default auto-logout <minutes>
Example:
web auto-logout 10
cli default auto-logout 10
•  Ensure SNMP is listening on the management interface only - To prevent unauthorized SNMP access, Riverbed recommends enabling SNMP access on the Primary interface only. This configuration allows administrators to control who can access SteelHeads through SNMP by way of using filters applied to routers, Layer-3 switches, or firewalls.
Syntax:
[no] snmp-server listen enable
[no] snmp-server listen interface <interface>
Example:
snmp-server listen enable
snmp-server listen interface Primary
•  Enable link state alarms - Enable the link state alarms, which are disabled by default. These alarms can alert you to any attempt to modify the cabling on the SteelHeads by inserting a tap for illegal sniffing functions.
Syntax:
[no] stats alarm <type> <options>
Example:
stats alarm linkstate enable
•  Disable the auto-discover SCC feature - By default, all SteelHeads try to register with the SCC using the default hostname riverbedscc. If you do not have an SCC, disable this feature.
Syntax:
[no] cmc enable
Example:
no cmc enable
If you do have an SCC, Riverbed recommends that you use it to manually discover SteelHeads, thereby reducing the possibility that an attacker could compromise the DNS environment and change the IP address of the riverbedscc A record to a rogue SCC.
•  Configure a password policy in the SteelHead - In RiOS 8.0 or later, you can configure user accounts on the SteelHead with a password policy to enforce minimum security standards for passwords, number of password attempts, and password expiration. The following password policies are predefined in the SteelHead:
–  Strong security template - Corresponds to the typical recommendations in Federal password guidelines.
–  Basic security template - Provides a minimal set of standards.
For more information about the type of accounts, how to configure role-based accounts, and information about the options for the password policy, see the SteelHead Management Console User’s Guide.
•  Use a BIOS password - Enable a password for BIOS, which prevents admin password recovery without the supervisor password. To configure a BIOS password:
–  Connect a null modem cable to a SteelHead.
–   Open up a terminal on your host to the SteelHead.
–   Power up the SteelHead.
–   Press F4 to enter BIOS.
–   Navigate to the Security tab.
–   Specify a supervisor password.
–   Make sure that the user password option is set to OFF.
–   Save your configuration and continue to boot the SteelHead.
•  Use a boot loader password - When you reboot the SteelHead, you can select from one of the two RiOS images on the menu. You can perform password recovery at this point by pressing the E key for edit. Pressing E alters the boot sequence to change the administrative password. Using the following commands, you can enable the boot loader to lock the password recovery process until a password is entered.
Steelhead (config) # boot bootloader password test1234
Steelhead (config) # write memory
Steelhead (config) # reload
...
-------------------------------------------------------------------
0: Riverbed Steelhead Software v. 5.5.3 (64bit)
1: Riverbed Steelhead Software v. 5.5.3 (64bit)
-------------------------------------------------------------------
 
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS or 'p' to enter a
password to unlock the next set of features.
Press 'P'
Password: *******
•  SSL Issues with Internet Explorer 6 and Oracle R12 - Previously, RiOS fixed a vulnerability found in CBC-based ciphers prior to versions 0.9.6e by inserting an empty frame on the wire to avoid a Chosen Plaintext Attack on cipher-block chaining (CBC) ciphers. Some versions of client and server applications do not understand the insertion of empty frames into the encrypted stream and close the connection when they detect these frames. Therefore, RiOS no longer inserts empty frames by default. Examples of applications that close the connection when they detect these empty frames are IE6 and Oracle R12. SharePoint under IIS has also exhibited this behavior.
The failure occurs when the SSL application fails to understand the data payload when either the client or server is using a block cipher using CBC mode as the chosen cipher. This failure can be with DES, AES, or 3DES using CBC. Note that when SteelHeads are deployed, the chosen cipher can be different than when the client is negotiating directly with the SSL server.
Note: Because current web browsers do not protect themselves from this vulnerability, SteelHeads are no less secure than other vendor’s appliances. From a security perspective, fixing this vulnerability is the responsibility of a server, not a patched client.
To determine whether the SteelHeads are inserting empty frames to avoid an attack, capture TCP dumps on the server-side SteelHead LAN interface and look at the Server Hello message that displays the selected cipher. Verify that DES, AES, or 3DES is the cipher. Also, check for the existence of 32-byte length SSL application data (this is the empty frame) on the LAN traces, followed by an SSL Alert.
To change the default and insert empty frames, enter the CLI command no protocol ssl bug-work-around dnt-insrt-empty.
Best Practices for Enabling SteelHead Security Features
The following best practices enable important security features provided by RiOS. These best practices are not requirements, but Riverbed recommends that you follow these suggestions as implementing them can enforce a secure deployment:
•  Use peering rules to control enhanced autodiscovery - Enhanced autodiscovery is a feature that allows SteelHeads or SteelHead Mobiles to discover other SteelHeads using TCP options. This feature greatly reduces the complexities and time it takes to deploy SteelHeads. It works so seamlessly that it can occasionally have the undesirable effect of peering with SteelHeads on the internet that are not in your organization's management domain.
Another scenario could be that your organization has a decentralized management approach where different business units might make their own purchasing and management decisions. You might not want SteelHeads from two or more business units to peer with one another.
In these situations, Riverbed recommends using peering rules. Peering rules determine which connections your SteelHead optimizes connections with, based on the source and destination IP addresses or TCP ports. This feature lets you deny peering with any unwanted connections. Another option is to create an Accept peering rule for your corporate network that allows peering from your own IP addresses, and denies it otherwise.
For more information about using peering rules, see the SteelHead Management Console User’s Guide.
For more information about the in-path peering rule command, see the Riverbed Command-Line Interface Reference Manual.
•  Enable a secure inner channel between SteelHeads when using the SMB-signing proxy feature - When sharing files, Windows provides the ability to sign CIFS messages to prevent man-in-the-middle attacks. Each CIFS message has a unique signature which prevents the message from being tampered with. This security feature is called SMB signing.
SMB signing is mandatory on all CIFS connections to domain controllers. Therefore, any CIFS connection to a domain controller must use SMB-signed packets.
You can enable the RiOS SMB signing feature on the server-side SteelHeads communicating with servers that have SMB signing set to Required. This features alleviates latency in file access with CIFS acceleration while maintaining message security signatures. With SMB signing on, the SteelHead optimizes CIFS traffic by providing bandwidth optimization (RiOS SDR and LZ), TCP optimization, and CIFS latency optimization—even when the CIFS messages are signed.
However, because there is no packet signing taking place between the SteelHeads for these connections, Riverbed recommends that you configure a secure inner channel to encrypt the traffic between the SteelHeads.
•  Enable a secure inner channel between SteelHeads when using Exchange 2007 encryption - Outlook 2007 has encryption enabled by default. The SteelHeads are able to decrypt this traffic; however, the connections between the SteelHeads are unencrypted by default. Configure a secure inner channel to encrypt all MAPI traffic between the SteelHeads.
•  Enable a secure inner channel to encrypt all optimized traffic between SteelHeads - When you enable a secure inner channel, all data between the client-side and the server-side SteelHeads is sent over the secure inner channel. You configure the peer SteelHead as SSL peers so that they are trusted entities. The SteelHeads authenticate each other by exchanging certificates as part of the encrypted inner-channel setup. After the SteelHeads establish the secure inner channel, you can encrypt and optimize all optimized traffic between SteelHeads using the channel. The trust between the SteelHeads is bidirectional; the client-side SteelHead trusts the server-side SteelHead, and vice versa.
•  Authenticate WCCP service groups - By default, WCCP peers in a WCCP group do not use authentication when registering. This default setting could allow an attacker to join a WCCP group and potentially cause a denial of service attack. Also an administrator could accidentally misconfigure a router to use a WCCP group that already is in use. Authentication controls would prevent these rogue devices from peering, thereby preventing possible network outages or degradation of performance.
Syntax:
[no] wccp service-group <service-id> {routers <routers> | assign-scheme [either | hash | mask]
| src-ip-mask <mask> | dst-ip-mask <mask> | src-port-mask <mask> | dst-port-mask <mask>} {protocol [tcp | icmp] | encap-scheme [either | gre | l2] | dst-ip-mask <mask> flags <flags> | password <password> | ports <ports> | priority <priority> | weight <weight> | assign-scheme [either | hash | mask] | src-ip-mask <mask> | dst-ip-mask <mask> | src-portmask <mask> | dst-port-mask <mask>}
Example:
wccp service-group 91 routers x.x.x.x password S3cuRity!
•  Encrypt the RiOS data store - RiOS SDR takes all TCP traffic and segments using a rolling data-driven computation. The segmentation produced is not readily predictable without running the computation, so an attacker interested in reconstructing a particular file does not know how many segments are involved or what the file boundaries are within the segments. The segmentation is stable, so that two identical bit sequences produce the same segmentation. Each new segment identified is written to the RiOS data store, because each previously seen segment is reused.
Even though there is inherent security in the obfuscation of the RiOS data store, Riverbed still provides a mechanism for enabling strong encryption of the RiOS data store. Encrypting the RiOS data store significantly limits the exposure of sensitive data in the event a SteelHead is compromised by loss, theft, or other types of security violations. The secured data is impossible for a third party to retrieve.
Syntax:
[no] datastore encryption type {none |aes_128 | aes_192 | aes_256}
Example:
datastore encryption type aes_256
Next, select Clear the Data Store on Reboot and reboot the SteelHead.
•  Change the secure vault - The secure vault contains sensitive information from your SteelHead configuration, including SSL private keys and the RiOS data store encryption key. These configuration settings are encrypted on the disk at all times using AES 256-bit encryption.
Initially, the secure vault is keyed with a default password known only to RiOS. This allows the SteelHead to automatically unlock the vault during system startup. You can change the password, but the secure vault does not automatically unlock on start up. To optimize SSL connections or to use RiOS data store encryption, the secure vault must be manually unlocked if the SteelHead is rebooted.
Therefore, Riverbed recommends using this feature only in conjunction with an SCC. The SCC can automatically unlock the Secure Vault when the SteelHead connects to the SCC after a reload.
Syntax:
secure vault {new-password <password> | reset-password <old-password> | unlock <password>}
Example:
Secure vault unlock o2fMu5TS!
•  Disable unused features - Disable any features that are not in use. For example, MAPI Exchange is on by default. If your organization uses Lotus Notes, Riverbed recommends that you disable Exchange optimization.
Refer to the Riverbed Command-Line Interface Reference Manual or the SteelHead Management Console User’s Guide for the specific features you might want to disable.
•  Disable automatic email notification - This feature proactively sends email notification of critical issues on the SteelHead (such as significant alarms and events) to Riverbed Support. Your organization might not want to send these automatic notifications.
Syntax:
[no] email autosupport enable
Example:
no email autosupport enable
•  Disable SteelHead reporting - This feature proactively reports some very basic information back to Riverbed Support once a week. This reporting is initially disabled, however, if the user configures name server IP addresses for the SteelHead it is automatically enabled. Your organization might not want to send this report.
Syntax:
[no] support uptime-report enable
Example:
no support uptime-report enable
•  Delete the preconfigured NTP servers - If your organization has NTP configured internally, Riverbed recommends removing the preconfigured NTP servers.
Syntax:
[no] ntp server {<hostname | ip-address>} [version <number>]
Example:
no ntp server 66.187.224.4
•  Configure Network Time Protocol (NTP) settings - Riverbed recommends that you synchronize the SteelHead to an NTP server of your choice. By default, the appliance uses the Riverbed-provided NTP server. Time is a critical function for the SteelHead and other network devices. Networks rely on accurate time determination for managing, securing, planning, and debugging. Tampering with time sources or posing as a rogue time server can lead to critical issues such as network authentication, or less critical issues such as conflicting log message time stamps.
RiOS 8.0 or later supports MD5-based NTP authentication at the CLI, and RiOS 8.5 or later supports both MD5-based and SHA-based NTP authentication on the CLI and Management Console.
•  Disable any interfaces not in use - Be sure to disable any interfaces that are not being used. Examples include the Auxiliary interface and any unused in-path interfaces.
Syntax:
[no] interface <interface name> <options>
Example:
interface inpath0_1 shutdown
For more information about SteelHead security, see the SteelHead Management Console User’s Guide.
Best Practices for Policy Controls
Follow these best practices for implementing secure policy controls:
•  Use the Simple Certificate Enrollment Protocol (SCEP) - In RiOS 5.5.2 or later, SCEP allows SteelHeads to request signed certificates for enrollment and reenrollment from the certificate server.
•  Use a Certificate Revocation List (CRL) - In RiOS 5.5.2 or later, SteelHeads can download CRL lists that contain revoked certificates from certificate servers through LDAP. Revoked certificates are considered invalid and are not used by the SteelHead.
For more information about SCEP and CRL, see the SteelHead Deployment Guide - Protocols.
Best Practices for Security Monitoring
After implementing security measures for your organization, Riverbed recommends enabling the following security monitoring features:
•  Enable Logging - Be sure to enable logging and log to a syslog server. At a minimum, set logging to the notice level to capture failed login attempts. You can also change the default logging facility (CLI only) (system=local0, user=local1, and per-process=local2). Use the logging facility user local# system <local-facility> perprocess <local-facility> command to configure the syslog facility.
Example—A failed login attempt:
Apr 13 05:19:49 BRANCH webasd[6004]: [web.NOTICE]: web: Attempt to Authenticate admin
Apr 13 05:19:49 BRANCH webasd(pam_unix)[6004]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=admin
Apr 13 05:19:49 BRANCH webasd[6004]: [web.NOTICE]: web: Failed to authenticate user admin: You must provide a valid account name and password.
After you enable syslog and log to a server, remember to review the logs daily.
RiOS 6.0 also includes several SNMP traps to notify you of SteelHead configuration changes, successful logins, and system dump initiation. For more information, see the SteelHead Management Console User’s Guide.
Syntax:
[no] logging <ip-address> [trap <log-level>]
Example:
logging x.x.x.x trap notice
•  Email alerts - Be sure to enable email alerts internally.
Syntax:
[no] email mailhub <hostname | ip-address>
[no] email notify events enable
[no] email notify failures enable
[no] email notify events recipient <email-address>
[no] email notify failures recipient <email-address>
Example:
email mailhub x.x.x.x
email notify events enable
email notify failures enable
email notify events recipient helpdesk@companyxyz.com
email notify failures recipient helpdesk@companyxyz.com
Refer to the Riverbed Command-Line Interface Reference Manual for more information about configuring email alerts.
•  Register with the Riverbed forums - Riverbed has several forums that enable you to receive advanced notifications for:
–  general announcements and updates
–  software releases
–  features
To register with Riverbed forums, go to https://splash.riverbed.com/welcome.
Configuring SSL Certificates for Web User Interface
The SteelHead automatically generates and uses a self-signed certificate to provide HTTPS access to the web UI to manage the appliance.
This certificate is separate from the SSL feature set. Management of SSL certificates for the web UI pertains to the SSL certificate used by the appliance's web UI when HTTPS is used.
You can replace the self-signed certificate with one created by the administrator or generated by a third-party certificate authority.
To upload a key or certificate
•  Connect to the SteelHead CLI and enter the following command:
web ssl cert import pem <pem text>
Do not enter more than one certification and more than one key. Because neither is required, you can opt to update only the certificate.
To generate a new certificate for the existing key for use with HTTPS on the SteelHead
•  Connect to the SteelHead CLI and enter the following command:
web ssl cert update
The new certificate is authorized for one year (365 days).
To generate a brand new self-signed certificate and key pair for use with HTTPS management on the SteelHead
•  Connect to the SteelHead CLI and enter the following command:
web ssl cert generate
This command overwrites the existing certificate and key pair regardless of whether the previous one was self-signed or user added. This command generates a self-signed certificate that is authorized for one year (365 days).
REST API Access
You enable access to the Riverbed REST API in the Administration > Security > REST API Access page. Representational State Transfer (REST) is a framework for API design. REST builds a simple API on top of the HTTP protocol. It is based on generic facilities of the standard HTTP protocol, including the six basic HTTP methods (GET, POST, PUT, DELETE, HEAD, INFO) and the full range of HTTP return codes. You can discover REST APIs by navigating links embedded in the resources provided by the REST API, which follow common encoding and formatting practices.
You can invoke the REST API to enable communication from one Riverbed appliance to another through REST API calls. For example:
•  A NetProfiler communicating with a NetShark.
A NetProfiler retrieving Layer-7 application mapping information from a SteelHead.
•  A NetProfiler appliance retrieving a QoS configuration from a SteelHead.
Note: There is an incompatibility between RiOS 9.0 and NetProfiler 10.0 preventing the QoS reporting functionality in NetProfiler from working. If you want to use NetProfiler QoS reporting, you must use a previous version than RiOS 9.0.
For all uses you must preconfigure an access code to authenticate communication between parties and to authorize access to protected resources.
For more information about the SteelHead REST API, see the SteelHead Management Console User’s Guide and the SteelHead REST API Guide.
Capacity Planning
This section describes capacity planning for the SteelHead. This section includes the following topics:
•  Model Characteristics
•  Admission Control
Model Characteristics
This section describes the characteristics of the optimization resources available for the SteelHeads. These resources are the primary determining factors for supported WAN capacity, maximum number of optimized TCP connections, and RiOS data store capacity. For example, the amount of hard drive space and RAM determine how large the RiOS data store can be.
This section includes the following topics:
•  TCP Connections
•  WAN Capacity Limits
•  RiOS Data Store Size
•  Disk Performance
For more information about individual model specs, go to http://www.riverbed.com/products-solutions/products/.
TCP Connections
Each SteelHead model has a maximum number of optimized TCP connections. The larger the SteelHead, the more CPU, memory, and disk resources are available, increasing the amount of supportable connections. This is one of the primary considerations you use for sizing branch offices. Typically, Riverbed recommends a guideline of 5-10 connections per user. Sizing for data center SteelHeads must take in account all optimized connections coming into the data center. For planning purposes, use the high end numbers for these types of connections. Large amounts of active connections (connections that are actively transmitting data), such as HTTP, have more impact on the SteelHead resources.
To view the connection history use the show stats connection <timeframe> command.
You can see the average and maximum number of connections for the time frame entered. These numbers are useful to determine if the current SteelHead is properly sized for the number of connections. You can also use this command to review when adding addition users or applications that can increase the number of optimized connections.
WAN Capacity Limits
WAN capacity limit is the amount of optimized traffic that is sent outbound from a SteelHead. This is also commonly used for sizing branch office SteelHeads. For data center SteelHeads, the WAN capacity is a recommendation on how much typical data throughput a SteelHead can process. Model CX7055M and below are limited to the rated outbound capacity (outbound after optimization). No rate limit or hard restriction is applied to throughput for a data center SteelHead CX7055H, though excessive amounts of certain types of traffic can strain the resources available on the SteelHead.
RiOS Data Store Size
RiOS data store size is the amount of disk space, in GB, available for SDR use. The data center SteelHeads use RAID 10 or FTS 7050 for disk redundancy and optimal performance.
Disk Performance
Take disk performance into account for high-end data center deployments. Certain types of data put more load on the disk systems and can be monitored if performance issues are suspected. High throughput data replication deployments typically use dedicated SteelHeads.
Monitor the disk systems with the following OID.
OID
Description
1.3.6.1.4.1.17163.1.1.4.0.8
RAID Errors
Use the following Data Store Disk Load report in the Management Console to monitor disk performance.
If the Disk Load report is showing 80 to 90% for a sustained amount of time or multiple times a day that coincide with periods of lower performance and average RiOS data store cost greater than 5000, the disk load might be impacting overall performance.
Admission Control
This section describes admission control and includes the following topics:
•  Connection Limits
•  Memory Limits
Admission control prevents the SteelHead from processing traffic when overloaded. It also controls the connection count limits. Admission control stops the interception of connections for optimization but still allows the connections to pass through without optimization. Admission control is in one of two states:
•  Flowing - In the flowing state, connections are intercepted as normal. Every 30 seconds or every 20 connections, admission control reevaluates whether the system is within limits. If the system exceeds certain limits, admission control moves into the paused state.
•  Paused - In the paused state, the SteelHead does not intercept connections. The connections currently intercepted continue to be optimized, although new connections are passed through. Every 30 seconds or every 20 connections, admission control reevaluates whether the system falls below certain limits. If so, admission control moves back into the flowing state.
Connection Limits
Each model contains connection limits to limit the total number of connections that is accepted into the system. The connection limits have rising and falling thresholds. The rising threshold is the cutoff limit. While the system is in flowing state, if the connection count rises above this threshold, admission control moves to the paused state. The falling threshold is the enable limit. While the system is in the paused state, until the connection count falls below this threshold, admission control keeps the system in the paused state.
Some leeway is given for connection limits before admission control is triggered. The minimum number of additional allowed connections before entering admission control on any model is 10. For example, a SteelHead with a rating of 30 connection does not enter admission control until it passes 40 connections. The SteelHead does not exit admission control until the number of connections falls back below the rated limit. Using the same example, a SteelHead entering admission control at 40 connections does not start optimizing new connections again until it is back down below 30 connections (rated limit).
The SteelHead sends out a SNMP alert, called Admission Control Error, to the SNMP host that you define. It alerts you that the licensed optimization limit is reached. You can purchase a bigger SteelHead that can take all the optimized TCP connections; or you can limit the type of traffic to be optimized with in-path rules configuration, and ensure maximum optimization benefits are limited only to most critical traffic or specific traffic that is hogging the WAN bandwidth.
Trap and OID
SteelHead State
Text
Description
admissionConnError
(enterprises.17163.1.1.4.0.11)
Control Admission
Admission control connections alarm has been triggered.
The SteelHead has entered admission control due to the number of connections and is unable to handle the amount of connections going over the WAN link. During this event, the SteelHead continues to optimize existing connections, but new connections are passed through without optimization. The alarm clears automatically when the traffic has decreased and no other action is needed.
Riverbed recommends polling the number of optimized connections periodically, so you can take proactive steps before all the optimized TCP connections are consumed. The following table shows the SNMP MIB for the number of optimized connections.
Trap and OID
SteelHead State
Text
Description
optimizedConnections (enterprises. 17163.1.1.5.2.1.0)
 
Current total number of optimized connections.
The optimized connections count is the total of half opened, half closed, and established/flowing connections.
Memory Limits
Each SteelHead model contains memory limits to limit the total amount of memory that is used. The memory limits have rising and falling thresholds. The rising threshold is the cutoff limit. While the system is in flowing state, if the memory usage rises above this threshold, admission control moves to the paused state. The falling threshold is the enable limit. When the system is in the paused state, until memory usage falls below this threshold, admission control keeps the system in the paused state.
Trap and OID
SteelHead State
Text
Description
admissionMemError
(enterprises.17163.1.1.4.0.10)
Admission Control
Admission control memory alarm has been triggered.
The SteelHead has entered admission control due to memory consumption. The SteelHead is optimizing traffic beyond its rated capability and is unable to handle the amount of traffic passing through the WAN link. During this event, the SteelHead continues to optimize existing connections, but new connections are passed through without optimization. The alarm clears automatically when the traffic has decreased and no other action is needed.
Note: Use the show admission command to display the cutoff and enable settings for your SteelHead.
For additional information about admission control, see the Riverbed Knowledge Base article Understanding Admission Control at https://supportkb.riverbed.com/support/index?page=content&id=s15140.
Overview of Exporting Flow Data
NetFlow and other Flow Data Collectors gather network statistics about network hosts, protocols and ports, peak usage times, and traffic logical paths. The flow data collectors update flow records with information pertaining to each packet traversing the specified network interface.
The flow data components are as follows:
•  Exporter - When you enable flow data support on a SteelHead, it becomes a flow data Exporter. The SteelHead exports raw flow data records to a flow data collector. You only need one SteelHead with flow data enabled to report flow records.
•  Collector - A server or appliance designed to aggregate the data the SteelHead exports. The Cascade Profiler or Cascade Gateway are examples of flow data collectors, which process and present this data in a meaningful way to the administrator. The collector captures:
–  enough information to map the outer-connection to its corresponding inner-connection.
–  the byte and packet reduction for each optimized connection.
–  information about which SteelHead interface optimized the connection, including which peer it used during optimization.
•  Analyzer - A collection of tools used to analyze the data and provide relevant data summaries and graphs. Flow data analyzers are available for free or from commercial sources. An analyzer is often provided in conjunction with a collector.
For smaller networks, the flow data collector and analyzer are typically combined into a single device. For larger networks, a more distributed architecture might be used. In a distributed design, multiple flow data exporters export their data to several flow data collectors which in turn send data back to the flow data analyzer.
Some environments configure NetFlow on the WAN routers to monitor the traffic traversing the WAN. However, when the SteelHeads are in place, the WAN routers only see the inner-channel traffic and not the real IP addresses and ports of the client and server. By enabling flow data on the SteelHead, this becomes a nonissue altogether. The SteelHead can export the flow data instead of the router without compromising any functionality. By doing so, the router can spend more CPU cycles on its core functionality: routing and switching of packets.
Before you enable flow data support in your network, consider the following:
•  Generating flow data can use large amounts of bandwidth, especially on low bandwidth links and thereby impact SteelHead performance.
•  To reduce the amount of data exported, you can export only optimized traffic.
For information about SteelHead MIB and SNMP traps, see the SteelHead Management Console User’s Guide.
SNMP Monitoring
This section describes the SNMP traps. It does not list the corresponding clear traps. Every SteelHead supports SNMP traps and email alerts for conditions that require attention or intervention. An alarm triggers for most (but not every) event and subsequently, the related trap is sent. For most events, when the condition is fixed, the system clears the alarm and sends out a clear trap. The clear traps are useful in determining when an event has been resolved.
RiOS 5.0 supports the following protocols:
•  SNMPv1
•  SNMPv2c
RiOS 6.0 or later supports the following protocols:
•  SNMPv3, which provides authentication through the User-based Security Model (USM).
•  View-based Access Control Mechanism (VACM), which provides richer access control.
RiOS 7.0 or later supports the SNMPv3 authentication with AES 128 and DES encryption described in the following table. Riverbed recommends the following OIDs as a good starting point from which to monitor your deployment. Additional variables can be added or removed as needed.
Note: The following OIDs are for xx55 SteelHeads only.
OID
Object Type
Description
1.3.6.1.4.1.17163.1.1.5.2.1.0
optimizedConnections
Current total number of optimized connections
1.3.6.1.4.1.17163.1.1.5.2.2.0
passthroughConnections
Current total number of pass-through connections
1.3.6.1.4.1.17163.1.1.5.2.3.0
halfOpenedConnections
Current total number of half-opened (optimized) connections
1.3.6.1.4.1.17163.1.1.5.2.4.0
halfClosedConnections
Current total number of half-closed (optimized) connections
1.3.6.1.4.1.17163.1.1.5.2.5.0
establishedConnections
Current number of established (optimized) connections
1.3.6.1.4.1.17163.1.1.5.2.6.0
activeConnections
Current number of active (optimized) connections
1.3.6.1.4.1.17163.1.1.5.2.7.0
totalConnections
Total number of connections
1.3.6.1.4.1.17163.1.1.5.1.1.0
cpuLoad1
1-minute CPU load in hundredths
1.3.6.1.4.1.17163.1.1.5.1.2.0
cpuLoad5
5-minute CPU load in hundredths
1.3.6.1.4.1.17163.1.1.5.1.3.0
cpuLoad15
15-minute CPU load in hundredths
1.3.6.1.4.1.17163.1.1.5.1.4.0
cpuUtil1
Percentage CPU utilization, aggregated across all CPUs, rolling average over the past minute
1.3.6.1.4.1.17163.1.1.5.1.5.1.1.1
cpuIndivIndex
A synthetic number numbering the CPUs
1.3.6.1.4.1.17163.1.1.5.1.5.1.2.1
cpuIndivId
Name of the CPU, also serves as the Index for the table
1.3.6.1.4.1.17163.1.1.5.1.5.1.3.1
cpuIndivIdleTime
Idle time for this CPU
1.3.6.1.4.1.17163.1.1.5.1.5.1.4.1
cpuIndivSystemTime
System time for this CPU
1.3.6.1.4.1.17163.1.1.5.1.5.1.5.1
cpuIndivUserTime
User time for this CPU
1.3.6.1.4.1.17163.1.1.4.0.8
raidError
RAID errors
 
In multiple CPU systems, the last digit corresponds to the CPU number.
The following table summarizes SNMP traps that represent serious issues and Riverbed recommends that you address them immediately.
Trap and OID
SteelHead State
Text
Description
procCrash
(enterprises.17163.1.1.4.0.1)
 
A procCrash trap signifies that a process managed by PM has crashed and left a core file. The variable sent with the notification indicates which process crashed.
A process crashed and subsequently restarted by the system. The trap contains the name of the process that crashed. A system snapshot associated with this crash is created on the SteelHead and is accessible through the CLI or the Management Console. Riverbed Support might need this information to determine the cause of the crash. The crashed process automatically restarts and no other action is required on the SteelHead.
procExit
(enterprises.17163.1.1.4.0.2)
 
A procExit trap signifies that a process managed by PM has exited unexpectedly, but not left a core file. The variable sent with the notification indicates which process exited.
A process unexpectedly exited and subsequently restarted by the system. The trap contains the name of the process. The process might have exited automatically due to other process failures on the SteelHead. Review the release notes for known issues related to this process exit. If none exist, Contact Riverbed Support to determine the cause of this event. The crashed process automatically restarts and no other action is required on the SteelHead.
bypassMode
(enterprises.17163.1.1.4.0.7)
Critical
The SteelHead has entered bypass (failthru) mode.
The SteelHead entered bypass mode and passes through all traffic unoptimized. This is the result of the optimization service locking up or crashing. It can also happen when the system is first turned on or turned off. If this trap is generated on a system that was previously optimizing and is still running, contact Riverbed Support.
storeCorruption
(enterprises.17163.1.1.4.0.9)
Critical
The RiOS data store is corrupted.
Corruption is detected in the RiOS data store. Contact Riverbed Support immediately.
haltError
(enterprises.17163.1.1.4.0.12)
Critical
The service is halted due to a software error.
The optimization service halts due to a serious software error. Check to see if a core dump or sysdump was created. If so, retrieve the information and contact Riverbed Support immediately.
serviceError
(enterprises.17163.1.1.4.0.13)
Degraded
There has been a service error. Consult the log file.
The optimization service encountered a condition that might degrade optimization performance. Consult the system log for more information.
licenseError
(enterprises.17163.1.1.4.0.57)
Critical
The main SteelHead license has expired, been removed, or become invalid.
A license on the SteelHead has been removed, has expired, or is invalid. The alarm clears when a valid license is added or updated.
hardwareError
(enterprises.17163.1.1.4.0.58)
Either Critical or Degraded, depending on the state
Hardware error detected.
Indicates that the system has detected a problem with the SteelHead hardware. These issues trigger the hardware error alarm:
•  the SteelHead does not have enough disk, memory, CPU cores, or NIC cards to support the current configuration
•  the SteelHead is using a memory Dual In-line Memory Module (DIMM), a hard disk, or a NIC that is not qualified by Riverbed
•  other hardware issues
The alarm clears when you add the necessary hardware, remove the unqualified hardware, or resolve other hardware issues.
lanWanLoopError
(enterprises.17163.1.1.4.0.63)
Critical
LAN-WAN loop detected. System will not optimize new connections until this error is cleared.
A LAN-WAN network loop has been detected between the LAN and WAN interfaces on a SteelHead (virtual edition). This can occur when you connect the LAN and WAN virtual NICs to the same vSwitch or physical NIC. This alarm triggers when a SteelHead (virtual edition) starts up, and it clears after you connect each LAN and WAN virtual interface to a distinct virtual switch and physical NIC (through the vSphere Networking tab) and then reboot the SteelHead (virtual edition).
optimizationServiceStatusError
(enterprises.17163.1.1.4.0.64)
Critical
Optimization service currently not optimizing any connections.
The optimization service has encountered an optimization service condition. The message indicates the reason for the condition:
•  optimization service is not running
This message appears after a configuration file error. For more information, review the SteelHead logs.
•  in-path optimization is not enabled
This message appears if an in-path setting is disabled for an in-path SteelHead. For more information, review the SteelHead logs.
•  optimization service is initializing
This message appears after a reboot. The alarm clears on its own; no other action is necessary. For more information, review the SteelHead logs.
•  optimization service is not optimizing
This message appears after a system crash. For more information, review the SteelHead logs.
•  optimization service is disabled by user
This message appears after entering the no service enable command or shutting down the optimization service from the Management Console. For more information, review the SteelHead logs.
•  optimization service is restarted by user
This message appears after the optimization service is restarted from either the CLI or Management Console. You might want to review the SteelHead logs for more information.
storageProfSwitchFailed
(enterprises.17163.1.1.4.0.73)
Either Critical or Needs Attention, depending on the state
 
Storage profile switch failed
An error has occurred while repartitioning the disk drives during a storage profile switch. A profile switch changes the disk space allocation on the drives, clears the Granite and VSP data stores, and repartitions the data stores to the appropriate sizes.
You switch a storage profile by entering the disk-config layout CLI command at the system prompt or by choosing Administration > System Settings: Disk Management on an EX or EX+Granite SteelHead and selecting a storage profile.
These reasons can cause a profile switch to fail:
•  RiOS cannot validate the profile.
•  The profile contains an invalid upgrade or downgrade.
•  RiOS cannot clean up the existing VDMKs. During clean up RiOS uninstalls all slots and deletes all backups and packages.
When you encounter this error, try to switch the storage profile again. If the switch succeeds, the error clears. If it fails, RiOS reverts the SteelHead to the previous storage profile.
•  If RiOS is unable to revert the SteelHead to the previous storage profile, the alarm status becomes critical.
•  If RiOS successfully reverts the SteelHead to the previous storage profile, the alarm status displays needs attention.
flashProtectionFailed
(enterprises.17163.1.1.4.0.75)
Critical
Flash disk hasn't been backed up due to not enough free space on /var filesystem.
Indicates that the USB flash drive has not been backed up because there is not enough available space in the /var filesystem directory.
Examine the /var directory to see if it is storing an excessive amount of snapshots, system dumps, or TCP dumps that you could delete. You could also delete any RiOS images that you no longer use.
datastoreNeedClean
(enterprises.17163.1.1.4.0.76)
Critical
The data store needs to be cleaned.
You need to clear the RiOS data store. To clear the data store, choose Administration > Maintenance: Services and select the Clear Data Store check box before restarting the appliance.
Clearing the data store degrades performance until the system repopulates the data.
If an error condition exists, there are several alarms that are generated along with the SNMP traps. If the email feature is configured, you receive an email notification in addition to the alarms.
To limit the number of alarms generated over a given period of time, use the stats alarm <alarm-name> rate-limit count <thresholds> <count> command.
There are three sets of thresholds: short, medium, and long. Each threshold has a window, which is several seconds, and a maximum count. If, for any threshold, the number of alarms exceeds the maximum during the window, an alarm is not generated and emails are not sent.
For more information about configuring SNMP and other important traps, see the SteelHead Management Console User’s Guide.
Configuring SNMPv3 Authentication and Privacy
RiOS 7.0 or later includes privacy to the SNMPv3 feature to support authentication and privacy encryption of SNMPv3 messages. You can use AES 128 and DES to send an SNMPv3 encryption for GET action.
All SNMPv3 passwords (authentication/privacy) are stored as hashed (MD5/SHA), and they are all master keys, even if you provide plain text password during configuration.
An SNMP agent runs in every SteelHead that supports SNMP GET request action. Among the techniques to secure SNMP traffic, such as access control lists, you can use SNMPv3 to provide authentication and privacy. The main benefit for SNMPv3 authentication is to ensure the integrity of SNMP traffic, while privacy provides encryption protecting data from being seen by a third party.
Configuring an SNMPv3 GET request encryption is a two-part process:
•  Configure USM user
The user corresponds with the authentication and privacy mechanism that a management station uses to access the SteelHead.
•  Configure ACLs
To configure the ACLs, you need to add or edit a group, view and access policy. You cannot add an access policy with a group and a view. Security names are not supported by SNMPv3. To restrict SNMPv3 USM users from polling a specific subnet, use the RiOS ACL feature on the Administration > Security: Management ACL page.
Views represent the OIDs a management station is allowed to access. You can create multiple views and restrict specific OIDs. A view starts with the highest level OID that you specify, and you can view all OIDs further down in the hierarchy, unless you specifically restrict them. You can only view OIDs in the hierarchy.
You must associate a group with a view. After you associate a group with a view, you can define an access policy to link the user, group, and view together.
The following procedure shows an example of a user named Cascade created with SHA authentication and AES encryption for privacy.
To configure a USM user
1. From the SteelHead Management Console, choose Administration > System Settings: SNMPv3.
2. Select Add a New User.
Figure: Add a New USM User
3. Select the Use Privacy Option check box.
4. Select AES or DES from the Privacy Protocol drop-down list.
5. Select any of the options in the Privacy drop-down list and complete any corresponding steps.
Figure: Add a New USM User shows Supply a Password and the corresponding password.
6. Click Add.
The following procedure shows an example of a group NetProfiler created, and then user Cascade is associated with the group Profiler.
To configure SNMP ACLs
1. From the SteelHead Management Console, choose Administration > System Settings: SNMP ACLs.
2. Select the Add a New Group tab.
Figure: Add a New Group
3. Specify a group name.
4. Select usm and select the user you created in To configure a USM user.
5. Click Add.
6. Select the Add a New View tab.
Figure: Add a New View
7. Specify a view name.
8. Specify the OIDs to include and exclude from the view.
9. Click Add.
10. Select Add a New Access Policy.
Figure: Add a New Access Policy
11. Select the group name you created from the Group Name drop-down list.
12. Select AuthPriv from the Security Level drop-down list.
13. Select the view you created from the Read View drop-down list.
14. Click Add.
You can verify your configuration in Wireshark. Make sure the SNMP PDUs are encrypted.
Figure: Wireshark Verification
To decrypt the SNMP packets for further troubleshooting
1. From the Wireshark menu, choose Edit > Preferences > Protocols > SNMP.
2. Select the Edit for the SNMP Users window.
Figure: SNMP Users Window
3. Complete the information in the SNMP Users window.
The engine ID is available on the SteelHead through the show snmp command or near the end of the running-configuration. The username, authentication model, password, privacy protocol, and privacy password are the same settings you configured for the SNMPv3 user on the SteelHead.
4. Click OK.
Wireshark decrypts the SNMP encrypted packets and you can analyze further for troubleshooting.