Auto Discover Internal Web Apps with Riverbed AppResponse

Riverbed_® AppResponse™ speeds the identification, diagnosis, and resolution of your most difficult network and application problems. A key component of AppResponse is its application analysis. It provides specialized analysis modules that deliver focused visibility into 60+ TCP and UDP applications, web transactions, SQL database transactions, Citrix, and VoIP and video apps.

Although AppResponse users are generally responsible for the upkeep of the network infrastructure and its core connectivity and transport functions, they are not part of IT teams that make the decisions that determine which applications use network resources. It’s therefore quite common for AppResponse users to want to “discover” which applications and protocols are present in the network. Often, they are surprised by what they see!

Web applications constitute an increasing share of mission-critical apps. Some AppResponse customers choose not to use the Web Transaction Analysis (WTA) module for very detailed performance analysis of HTTP/S, but they still want the Application Stream Analysis (ASA) module to tell them which apps are present in the network. The ASA module primarily looks at fields in the IP and TCP/UDP headers. These fields do not have enough information to recognize internal web apps because that information is only present deep in the bowels of HTTP/S that ASA does not analyze. This creates the following problem: How do AppResponse customers using (only) ASA know which traffic on the network belongs to important internal web applications?

Discovering internal Web apps

Good news! A new feature, called Discovered Service Names, enables the ASA module to identify internal web apps by extracting the service name from the HTTP CONNECT, TLS SNI, or X509 Certificates. Public web apps, like SAP, Google, etc. that are already tracked by DPI aren’t discovered by this feature. The URL app is not automatically created; the user must choose to explicitly monitor an application. This feature is disabled by default.

The AppResponse ASA Discover Service Names feature identifies critical internal web apps for monitoring and analysis.

How does it work?

By inspecting the SNI (Server Name Indication) field in SSL/TLS handshakes, AppResponse ASA can classify web traffic. SNI is an addition to the TLS encryption protocol that enables a client device to specify the domain name it is trying to reach in the first step of the TLS handshake, preventing common name mismatch errors. Using SNI, AppResponse ASA is now able to classify internal web applications traffic more accurately by inspecting the contents in SSL/TLS handshakes, in addition to fields in the IP and TCP/UDP headers.

AppResponse can also classify internal web traffic by matching the content of the HTTP Connect message that browsers send to web proxies, including CASBs that act as web proxies. HTTP Connect messages will typically contain the name of the web application or web service, e.g., hr.company.com, booking.company.com, etc. This lets ASA accurately classify traffic into internal web applications.

TLS 1.3 traffic decryption (PFS API)

Web applications dominate the mission-critical traffic that AppResponse sees in most of its in-production deployments. As a result, WTA is the second most used analysis module. It delivers vital insight into network and application behavior for web applications, e.g., seeing web traffic organized by user sessions, auto-stitched web pages and their network, client, and server delays, and analyzing web server behavior by looking for unexpected HTTP Status Codes and so on.

All mission-critical web apps use either TLS 1.2 or 1.3 encryption. AppResponse must decrypt these application packets to calculate and derive the statistics whose analysis (via Insights, Navigator, or Transaction Search) delivers the deep visibility AppResponse users expect. Because TLS 1.3 mandates the use of encryption algorithms that guarantee Perfect Forward Secrecy (PFS), any man-in-the-middle network appliance that intercepts TLS 1.3 packets cannot decrypt them even if it has access to the private keys. As a result, we’ve added support for TLS 1.3 to our PFS API that enables the decryption of traffic encrypted by TLS 1.3, in addition to the previously supported SSL and TLS 1.2. We still need an external source (like a F5 load balancer) to send the keys. For more information on how AppResponse PFS API works, check out this blog Riverbed AppResponse Adds SSL/TLS Analysis and PFS API.

Backup and restore

An AppResponse deployed in production is a source of network and application performance data

– both packets and metadata/metrics derived from DPI. The metadata/metrics contain data that spans a few weeks, to several months, to a few years. A deployed AppResponse also contains a lot of user customizations in the form of configurations, e.g., Host Groups definitions, app definitions, traffic policy definitions, WTA page analysis rules, etc.

The new Backup and Restore capabilities are found under System Settings.

Performance data includes aggregate data (ASA, WTA, DBA, VOIP, CXA), alert events, scheduled reports, and system metrics. AppResponse customers want data loss protection in place for this information set. Together, an AppResponse’s configuration and forensic data represent very valuable information.

AppResponse can backup and restore both configuration and performance data to local and remote backup servers. You can initiate a backup manually or create a schedule and automate when backups are performed, e.g., after working hours or on weekends. However, you must restore to the same software and hardware.

Faster transaction analysis

What makes AppResponse transaction data invaluable is that it’s never topped. AppResponse power users use HD Insights and Transaction Search when they need to analyze all types of network and application behavior, including occasional low-volume communication. For example, a security use case like finding the IP address that generated just a few bytes of traffic six hours ago and went quiet after that.

We continue to make writing and querying faster when accessing critical transaction data (e.g., 1-min. summaries of each TCP connection, detailed summary metrics of each HTTP/S request-response pair, 1-min. summaries of each voice/video media stream, 1-min. summaries of every SQL query-response pair).

We addressed this problem in a two-part project: The first part was delivered in 11.12 and included updating to a newer version of the database we use for write-once many-reads data store for transaction data. This feature delivers the second part of this performance improvement by optimizing the structure of the underlying database tables to better leverage data sparseness and facilitate highly selective record processing times.

Support for VMWare ESXi 7.0

For customers who operate private clouds based on VMware ESXi, deploying a virtual AppResponse appliance as a guest VM is the NPM packet analysis option we have long delivered to address this need. Just like any other OS platform, the ESXi hypervisor evolves over time and shows up as newer release versions. In the release, we added support for VMware ESXi version 7.0. We continue to support versions 6.5 and 6.7 but dropped support for ESXi 6.0.

To summarize, Riverbed AppResponse provides the ability to extract valuable network and application performance information using real-time packet analysis and do it at the peak scale. We continue to enhance this capability by

• Improving AppResponse’s built-in intelligence to auto-recognize enterprise-internal web apps,
• Enabling decryption of TLS 1.3 using our PFS API,
• And delivering performance improvements for packet write to disk and HD Insight transaction queries.