This section describes some simple measures you should perform to secure Portal before you begin changing the system’s configuration. Configuration changes that block sophisticated attempts to access the system remotely are imperative, but they are rendered superfluous if it’s possible for an unauthorized person to walk up to a hardware host and connect to its console port, or if an outdated web browser with a security flaw supplies an inconspicuous attack vector.

When using Portal, install it on a secure host that you can restrict physical access to authorized personnel only. Restricting physical access to a host reduces the likelihood 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 Portal 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 Portal’s dashboards and configuration exclusively to users of explicitly allowed subnets.

The following practices provide additional simple safeguards against unauthorized access:

After you’ve addressed the simple ways Portal 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 Portal is disabled by default. You can enable it by choosing Administration > System Settings: General in the web UI and selecting the Web Server Settings tab.

You can disable SSH on Portal using the no sshd enable CLI command. SSH can be reenabled using the sshd enable CLI command.

Portal does not allow 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 Portal and other devices it must communicate with:

Portal 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, Portal provides a single user account and password: The username is admin, and the default password is admin. The system assigns this user account the built-in role of System Administrator, which provides the admin user account with unrestricted access to all Portal features and data.

Perform these steps to change the default password using the web UI:

You can create and configure additional user accounts in the Administration > Account Management: User Administration page. 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 Portal features and data.

By default, Portal provides six built-in roles:

These built-in roles range in privilege from unrestricted access to all Portal features and data (System Administrator) to tightly restricted access that permits only the customization of the home screen and read-only drill-down access to data screens (Dashboards User), with the other four roles falling between those two opposites, providing varying amounts of nuanced access.

Refer to the Alluvio Portal User Guide for complete descriptions of these roles. If you find that the six built-in roles do not meet your exact needs, you can explicitly define additional custom user roles.

Role Based Access Control (RBAC) protects Portal by assigning different access privileges to different user roles. You then assigned user roles to user accounts as you create them. A user's privileges in Portal are determined by which roles the system administrator assigns to their account. You can assign each user account one or more roles.

To define user roles, choose Administration > Account Management: User Administration and select the 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, Portal 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 explicitly define a password policy. 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 both web UI and CLI access methods.

To configure password policies, choose Administration > Account Management: User Administration and select the Password Policy tab. The controls on that page enable you to define the requirements that user-defined passwords must meet. 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 easily guessed or brute force attacked.

By default, Portal supports the use of local user accounts, which Portal authenticates using passwords that are configured and stored in it. Portal supports the use of four authentication methods in addition to local user accounts: LDAP, RADIUS, TACACS+, and SAML. If you use one or more of these authentication methods, you must explicitly configure them.

To access the authentication pages, choose Administration > Account Management: Authentication. A tab is provided for configuring each authentication method.

Once authenticated, a remote user can be assigned a role (authorized) either by the authentication server or identity provider, or by a default role configured in Portal. If authentication and authorization succeed, the system logs in the user. If either authentication or authorization fails, the appliance displays an error message and records an unsuccessful login attempt in the audit logs.

When using remote authorization:

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

When LDAP, RADIUS, and TACACS+ authentication servers are configured in Portal, you can add them to a sequence of authentication types (LDAP, RADIUS, TACACS+, or local) to be used when a user signs in. Authentication requests are made from the highest priority authentication type (1) to the lowest. For RADIUS and TACACS+ authentication types, requests are sequentially made to the configured servers in the order they appear on the RADIUS and TACACS+ tabs. Authentication requests are made until a server accepts or rejects a request or the authentication types are exhausted.

Be careful that you don’t lock yourself out of Portal by doing either of the following:

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

Portal supports LDAP authentication, but you must explicitly configure one or more LDAP authentication servers.

You can configure up to two LDAP authentication servers—one primary and one secondary—using the CLI, not the web UI. Portal uses the primary LDAP server by default, and, if there is a connection failure, Portal contacts the secondary LDAP server. To ensure a seamless switchover from primary to secondary, configure the same bind credentials and LDAP data in Portal for both servers.

When you enable or disable LDAP, it is automatically added to or removed from the authentication sequence.

Portal supports RADIUS authentication, but you must explicitly configure one or more RADIUS authentication servers.

Choose Administration > Account Management: Authentication and select the RADIUS tab to add one or more RADIUS servers to the Portal configuration.

Portal supports TACACS+ authentication, but you must explicitly configure one or more TACACS+ authentication servers.

Choose Administration > Account Management: Authentication and select the TACACS+ tab to add one or more TACACS+ servers to the Portal configuration.

Portal supports SAML authentication, but you must explicitly enable SAML and configure the SAML identity provider (IDP).

SAML 2.0 authentication facilitates single sign-on for use with one or more Portal systems or other Alluvio products accessed from a single browser session. When SAML 2.0 is enabled, Portal relies on a specified SAML IDP for authentication. The home page shows a button for the user to log in through SAML. If a user wants to log in through local authentication, the user can still do so from the login screen. If the SAML identity provider is unable to authenticate a user for any reason, that user is not able to log in through SAML to launch a Portal web UI session.

When SAML 2.0 is enabled, the first time a user initiates access to Portal in a browser session, Portal redirects the user to the SAML IDP for authentication. Upon successful authentication, the IDP redirects the user back to Portal, and the UI opens. The IDP sends back the user role corresponding to the username being authenticated, and that user has permissions in Portal as defined by that role. As long as the user keeps that browser session active, any subsequent Portal session—even if the user logs out of the system, quits the browser tab, or accesses a new system—begins immediately without requiring the user to reauthenticate. The user needs to reauthenticate with the IDP if they quit the browser session in which they had authenticated earlier.

Audit logging is enabled for Portal by default. The audit log records configuration changes made to Portal using the CLI and web UI. By default, the audit log records all configuration changes. The associated details of the modified data/settings are the same for the two user interfaces, and they include appropriate source/user/session information. If you do not want to record all configuration changes, you can configure the audit log to omit specific changes.

We recommend enabling audit logging so you have a record of exactly who accessed every resource on a system during an attempted breach.

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

Choose Administration > System Settings: System Operations and select 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, we strongly discouraged that.

Portal 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.

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

To replace Portal's current certificate with an existing certificate or generate a new, self-signed certificate, choose Administration > System Settings: General and select the Web Server Settings tab. Refer to "Replacing the SSL certificate" in the Alluvio Portal User Guide for complete details.

Portal's Secure Vault feature cryptographically encrypts secret keys and certificates stored locally. This vault decrypts (unlocks) secured data 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 is 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 Portal consists of:

To modify these cipher strings, choose Administration > System Settings: General and select the Web Server Settings tab.

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

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

Known vulnerabilities that are addressed by bug fixes in Portal are cited as fixed issues in the release notes for each new Portal version.

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