This document describes a set of recommended practices for securing your AppResponse 11 system against unauthorized access. Practices for physical appliances, VM-hosted systems, and cloud-based systems are covered.

This section describes the simplest measures you can take to secure your AppResponse 11 system, before you begin changing the system’s configuration. Configuration changes that block sophisticated attempts to access the system remotely are imperative, but are rendered superfluous if it’s possible for an unauthorized person to walk up to an appliance and connect to its console port, or if an outdated web browser with a security flaw furnishes a non-obvious attack vector.

When using an AppResponse 11 appliance, make certain to install it in a secure location to which it is possible to restrict physical access to authorized personnel only. Restricting physical access to the appliance reduces the likelihood of forms of tampering such as unauthorized connection to a hardware interface, removing hard disks, and unscheduled reboots.

If your network management tools support the practice, define a network policy that allows access to the AppResponse 11 system only from specific IP addresses and subnets, and denies any access to all others. In this way, you can restrict the visibility and availability of the AppResponse 11 system’s dashboards and configuration exclusively to users of explicitly allowed subnets.

Use the Administration > Authentication page in the AppResponse 11 web UI to define a login banner message that warns users against unauthorized access to the system. This will display a message as each user logs in, formally notifying them of any conditions or requirements associated with their use of the system, as well as any penalties for unauthorized access or deliberate misuse. No default login banner is provided; if you wish to use one, you must define it explicitly.

The following practices furnish additional simple safeguards against unauthorized access:

After you’ve addressed the simplest, least sophisticated ways your AppResponse 11 system can be compromised, you’re ready to begin changing its configuration to secure it against more sophisticated attempts at unauthorized access over the network.

HTTP access to AppResponse 11 is disabled by default. You can enable it using the web UI at Administration > System Settings: General, in the Web Server Settings tab.

SSH access to AppResponse 11 is enabled by default. You can disable it using the no sshd enable CLI command. SSH can be re-enabled using the sshd enable CLI command.

AppResponse 11 does not enable you to restrict SSH, web UI, or REST access by IP address.

If you lock down your network on a port-by-port basis, ensure that the following ports are open between AppResponse 11 and other systems it must communicate with:

AppResponse 11 provides robust support for controlling access by individual users.

Unless you are using SAML (single sign-on), user management is the same across HTTPS, REST, and CLI, through serial, monitor/keyboard, and SSH interfaces.

By default, AppResponse 11 provides a single user account and password: The user name is admin, and the default password is admin. This user account is assigned the built-in role of System Administrator, which provides the admin user account with unrestricted access to all AppResponse 11 features and data.

Change the default password using the web UI by opening the Administration > Account Management: User Administration page. Click the Local Users tab and edit the admin user account. When the Edit User: admin dialog appears, click Change Password. Type the old password (“admin”), then type and re-type the new password. Click Apply to make the change take effect immediately. The next time you log in with the admin account, you will need to type the new password.

Additional user accounts can be created and configured on the Administration > Account Management: User Administration page, also. You should create some user roles, first, though, as the only user role provided by default is System Administrator, which provides unrestricted (“Full Control”) access to all AppResponse 11 features and data.

Role Based Access Control (RBAC) protects AppResponse 11 by assigning different access privileges to different user roles. User roles are then assigned to user accounts as they are created. A user's privileges on the system are determined by which roles the system administrator assigns to their account. Each user account can be assigned one or more roles.

Define user roles using the web UI at: Administration > Account Management: User Administration (Roles and Permissions tab).

A new role begins with “No Access” for each category of functionality; defining a new role is a matter of adding access (either “View Only” or “Full Control”) for specific functionality categories. Changing the access associated with a role changes access for every user account that is assigned that role.

By default, AppResponse 11 has no password policy defined. This means that there are no restrictions or conditions on password length, character requirements, reuse, and other related considerations. To ensure that users define adequately secure passwords, you must define a password policy explicitly. These password policies apply to local user accounts only; when remote authentication or SAML is used, that remote authentication service enforces its own password policies. Password policies affect all access methods (web UI and CLI).

Configure password policies using the web UI at: Administration > Account Management: User Administration (Password Policy tab). The controls on that page enable you to define the requirements that user-defined passwords must meet when they are created or changed. These requirements can include minimum length, minimum number of lowercase and uppercase characters, minimum number of digits, minimum number of symbol characters, minimum number of character changes, maximum number of repeated characters, restriction on including common words, and the number of previous passwords to check to prevent the reuse of old passwords. Take the time to define a prudent set of requirements that ensures that users create strong passwords that cannot be guessed easily or brute force broken.

SAML is described separately in the section that follows this one.

Access the authentication pages in the web UI at Administration > Account Management: Authentication. A tab is provided for configuring each authentication method.

The Authentication page’s General tab provides a section titled, Authentication Types, that enables you to configure the precedence of the authentication methods you have in place.

When RADIUS and TACACS+ authentication servers are configured in AppResponse 11 you can add them to a sequence of authentication types (Local, RADIUS, or TACACS+) to be used when a user logs in. Authentication requests are made from the highest priority authentication type to the lowest. Within each authentication type, requests are made sequentially to the configured servers in the order in which they appear on the RADIUS and TACACS+ tabs. Authentication requests are made until a server accepts or rejects a request, or until the authentication types are exhausted.

If you lock yourself out of the system, contact Riverbed technical support. Riverbed recommends checking that authentication using RADIUS and TACACS+ works successfully before you remove local authentication or clear the "Try next method on reject." check box.

Refer to the AppResonse 11 User’s Guide for complete details.

Click Administration > Account Management: Authentication and click the RADIUS tab to add one or more RADIUS servers to the AppResponse 11 configuration.

Click Administration > Account Management: Authentication and click the TACACS+ tab to add one or more TACACS+ servers to the AppResponse 11 configuration.

AppResponse 11 supports SAML authentication, but you must enable SAML explicitly and configure the SAML IDP. If you enable SAML authentication, RADIUS, TACACS+, and local authentication all will be disabled for the web UI, and only the SAML IDP will authenticate users.

SAML 2.0 authentication is supported to facilitate single sign-on for use with one or more AppResponse 11 systems or other Riverbed SteelCentral products accessed from a single browser session. When SAML 2.0 is enabled, AppResponse 11 relies on a specified SAML identity provider (IDP) for authentication, and does not use local authentication or RADIUS or TACACS+ servers in any combination. (Note that enabling SAML 2.0 authentication on AppResponse 11 disables all other forms of authentication used by the web UI.) If the SAML identity provider is unable to authenticate a user for any reason, that user will not be able to launch an AppResponse 11 web UI session. Note that SAML 2.0 authentication can be disabled via the AppResponse 11 CLI, using the no saml enable command.

When SAML 2.0 is enabled, the first time a user initiates access to an AppResponse 11 system in a browser session, AppResponse 11 will redirect the user to the SAML IDP for authentication. Upon successful authentication, the IDP will redirect the user back to the AppResponse 11 system, and the UI will open. The IDP will send back the user role corresponding to the user name being authenticated, and that user will have permissions in AppResponse 11 as defined by that role. As long as the user keeps that browser session active, any subsequent AppResponse 11 session, even if the user logs out of the system, quits the browser tab, or accesses a new system, will begin immediately without requiring the user re-authenticate. The user will need to re-authenticate with the IDP if they quit the browser session in which they had authenticated earlier.

It's recommended practice to have audit logging enabled so you have a record of exactly who accessed every resource on a system during an attempted breach.

Click Administration > System Status: Audit Trail to view the audit log for the system.

Click Administration > System Settings: System Operations and click the Audit Log Configuration tab to configure the audit log for the system. The Audit Log Configuration tab lists a large set of configuration object changes that can be logged; by default, all configuration objects are selected (enabled) for logging. Deselect one or more configuration objects if you don't feel it's necessary to record changes made to it. Controls are provided that enable you to specify the retention time and size of the log, as well as a control for specifying one or more external recipients of the audit log via Email, SNMP, or Syslog.

Access to the web UI and REST uses a TLS 1.2 encrypted channel, and the two interfaces share the same underlying HTTPS server. Although it is possible to enable SSL3 and TLS 1.0/1.1, this is strongly discouraged.

AppResponse 11 comes with a preconfigured set of enabled ciphers, and you can change the ciphers from the web UI or CLI using a cipher string that conforms to OpenSSL cipher string syntax.

Communication with NetProfiler uses a TLS1.2 encrypted channel. The cipher cannot be changed.

AppResponse 11 can be configured to decrypt the SSL communications of the packets captured from its monitoring ports. To do this, you need to provide AppResponse 11 with the private keys needed to decrypt the communications. The private keys are stored in the Secure Vault, cannot be extracted from the system (they are "write only") and have no relationship with the private key used for the HTTPS web server supporting the ARAppResponse 11 web UI and REST API.

AppResponse 11 supports secure storage of keys and certificates, as well as decryption of secure communications with other entities.

AppResponse 11's Secure Vault feature cryptographically encrypts secret keys and certificates stored on the local disk. The secured data is decrypted (unlocked) in memory after the system boots normally. If the vault cannot be unlocked, due to the system having been compromised, the web UI will be inaccessible. SAML authentication, SSL traffic decryption, and data export to NetProfiler also will not be functional. Administrator account login via SSH will be available for access to CLI commands.

The following pieces of secure information are stored in the Secure Vault:

The default cipher string configuration for HTTPS on AppResponse 11 consists of:

These cipher strings can be modified in the web UI at Administration > System Settings: General in the Web Server Settings tab.

The following SSL ciphers are supported for decoding:

Communication with NetProfiler uses a default certificate; the certificate can be changed using the AppResponse 11 web UI, and the same change should be made on NetProfiler as well. Refer to the respective user guides for detailed instructions.

Make sure that you don’t enable old ciphers or protocols like SSL 3.0 unless it’s necessary for compatibility with older browsers or other products.

SSH ciphers are configurable using the CLI.

RADIUS and TACACS+ are old protocols that don't use strong cryptography when encrypting the credentials that go over the network.

The AppResponse 11 REST API shares a communication channel with the web UI, and uses the same authentication scheme as the web UI, unless you use SAML, in which case the REST API continues to use the normal RADIUS/TACACS/local authentication schemes.

Enable SNMP using the web UI at Administration > System Settings: General, and click the SNMP tab. The Enable SNMP checkbox appears at the top of the tab.Note that SNMP v3 supports the use of user names, privilege levels, and authentication for trap notifications.

Recipients for SNMP traps are defined using the web UI at Definitions > Recipients.

Contact Riverbed technical support to report any security vulnerability that you discover that affects any portion or any operation of the AppResponse 11 system. As much as you’re able to do so, please include all details about the circumstances in which you found the vulnerability, including:

Known vulnerabilities that are addressed by bug fixes in AppResponse 11 are cited as security updates in the release notes for each new AppResponse 11 version.

The CLI command, system reset-factory resets the AppResponse 11 system to its factory default state. This command deletes all configuration, data, and logs from the AppResponse 11 system and resets it to the state it was in when it was powered on the very first time. The command does not perform a secure disk wipe or affect the AppResponse 11 software itself; the installed version and any patches will not be touched.