n Overview of security

n Vulnerability management

n Overview of authentication

n Authentication features

n Configuring a RADIUS server

n Configuring a TACACS+ server

n Securing Interceptors

n Configuring SNMPv3 authentication and privacy

n Management access:

n Management ACL (Interceptor 4.0 and later)

n Image and configuration lifecycle:

n Physical control:

n compromise the OS of the appliance (buffer overflow, known security vulnerabilities, password exploitation).

n eavesdrop on data through sniffing and traffic replay.

n attack the optimized, connection-setup process.

n Local

n RADIUS

n TACACS+

n 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+.

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

n TACACS+ Server First Hit - When the tacacs-server first-hit is enabled, the Interceptor 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.

n Fallback - The fallback feature 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 using the aaa authentication cond-fallback command, 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.

n 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 doesn’t. 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.

n Configuring a RADIUS server with FreeRADIUS

n Configuring RADIUS authentication in the Interceptor

n Configuring RADIUS CHAP authentication

n Use the RADIUS server first for authentication, but

n Fall back to the Interceptor username and password database if the RADIUS server is unavailable.

n Configuring TACACS+ with Cisco secure access control servers

n Configuring TACACS+ authentication in the Interceptor

n For details about configuring TACACS+ with Cisco ACS 4.x, go to Knowledge Base article S14831.

n For details about configuring TACACS+ with Cisco ACS 5.x, go to Knowledge Base article S16158.

n Overview of securing Interceptors

n Best practices for securing access to Interceptors

n Best practices for enabling Interceptor security features

n Best practices for security monitoring

n Configuring SSL certificates for web user interface

n Restrict physical access - You must restrict physical access to any network device. An unauthorized user can easily gain access to an Interceptor if that person has physical access. Every device has the ability to recover lost passwords. By acquiring physical access to a device, an unauthorized user can gain control by using the lost password recovery procedures. Even without breaking into the Interceptor software, it is possible to gain access to the contents of disks by gaining access to the Interceptor itself. You should treat the Interceptor as comparable in value to the servers or clients that hold sensitive data. For example, if servers are in locked rooms, we recommend the Interceptors also be in locked rooms. The main function of the Interceptor is to load balance traffic, but it doesn’t store traffic packets unless you perform a TCP dump operation. The risk of accessing stored content is lower than that of a SteelHead.

n 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’s access and security policies. Have your organization’s legal council approve an appropriate login message.

n Allow management only from the primary interface - Limiting SSH and HTTPS access to the Primary interface allows you to restrict who can access the Interceptors by the use of filters or Administration: Security > Management ACLs. 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 Interceptors helps prevent unauthorized user access.

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

n 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 isn’t necessarily the case.

n Use TLS only for the Management Console - Only permit TLS between the browser and the Management Console.

n Remove the default username from the Web preference settings - The default username in the login field is admin. Don’t 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.

n Change all default passwords and community strings - Be sure to change the default password for the administrator and monitor accounts. The monitor account is disabled by default.

n Use strong passwords - Strong passwords typically include combinations of uppercase and lowercase letters, numbers, special characters, and are at least eight characters in length. Strong passwords reduce the likelihood of a successful brute-force attack because they aren’t found in dictionaries and exponentially increase the complexity of the passwords.

n Use AAA authentication - One of the challenges with using local usernames and passwords is that when an employee leaves an organization, an administrator must modify every device that has a username and password configured for that former employee.

n Configure the CLI session time-out - By default, the Interceptor closes the SSH session to the command line after 15 minutes. You can change this interval using the following command:

n Set an inactivity timer for console, SSH, and HTTPS sessions - Be sure to set a proper inactivity time-out value for management sessions. Don’t 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 didn’t manually log off.

n Ensure SNMP is listening on the management interface only - To prevent unauthorized SNMP access, we recommend enabling SNMP access on the Primary interface only. This action allows you to control who can access Interceptors through SNMP by way of using filters applied to routers, Layer-3 switches, or firewalls.

n Enable link state alarms - Enable the link state alarms, which are disabled by default. This action can alert you to any attempt to modify the cabling on the Interceptors by inserting a tap for illegal sniffing functions.

n Disable the auto-discover SCC feature - By default, all SteelHeads try to register with the SCC using the default hostname riverbedcmc. If you don’t have an SCC, disable this feature.

n Use a BIOS password - Enable a password for BIOS, which prevents admin password recovery without the supervisor password. To configure a BIOS password:

n Use a boot loader password - When you reboot the Interceptor, you can select from one of the two Interceptor images on the menu. You can perform password recovery at this point by pressing the E 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.

n Authenticate WCCP service groups - By default, WCCP peers in a WCCP group don’t use authentication when registering. This 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.

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

n Delete the preconfigured NTP servers - If your organization has NTP configured internally, we recommend removing the preconfigured NTP servers.

n Configure Network Time Protocol (NTP) settings - We recommend that you synchronize the Interceptor to an NTP server of your choice. By default, the appliance uses the Riverbed-provided NTP server. Time is a critical function for the appliances 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.

n Disable any interfaces not in use - Be sure to disable any interfaces that aren’t being used. Examples include the auxiliary interface and any unused in-path interfaces.

n Limit which hosts can communicate with the Interceptor - Interceptors communicate with other Interceptor and SteelHeads. Assuming the user subnets are different than the subnets you used to configure the Interceptors and SteelHeads (in-path interfaces), you can restrict the source networks to the optimization node subnets. At a minimum, you can restrict ports 7850 and 7860 using the management ACLs to avoid an attacker from a user subnet trying to connect to an Interceptor using these ports, which minimizes the risk of a Denial of Service attack. Figure: Example of limited host communication shows an example configuration.

n 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-facility>system <local-facility>perprocess <local-facility> command to configure the syslog facility.

n Email alerts - Be sure to enable email alerts internally.

n Register with the Riverbed forums - Riverbed has several forums that enable you to receive advanced notifications for:

n Riverbed Knowledge Base - Follow relevant Knowledge Base articles and use the Security Finder.

n Connect to the Interceptor CLI and enter the following command:

n Connect to the Interceptor CLI and enter the following command:

n Configure USM user

n Configure ACLs