1. Kemp Support
2. Hidden Playground
3. ECS Connection Manager
4. Release Notes

ECS Connection Manager 7.2.59.0 Release Notes

Updated: February 05, 2024 22:04

ECS Connection Manager (ECS CM) is a hardware and virtual Application Delivery Controller for the DELL EMC Elastic Cloud Storage (ECS) object storage solution.

ECS CM 7.2.59.0 is a feature and bug fix update for the General Availability (GA) release branch, made available on 27 March 2023. Please read the sections below before installing or upgrading to this release. 

Contents

Before You Upgrade (READ ME FIRST)
New Features
Response Code Modification
GEO HTTP HEAD Site Health Checks
API Updates for WhatsUp Gold Integration
GEO System Information / Debug Page
WAF Logging: Splunk HEC Integration
HTTP Request Load Balancing
Change Notices
ACME Support for Multiple Service Providers
Security Updates
WAF: ModSecurity Engine Security Update
Issues Resolved
New Known Issues
Existing Known Issues

Before You Upgrade (READ ME FIRST)

Please pay special attention to the issues below before you begin an upgrade to this ECS CM release.

Generation of 4096-bit DHE Key

During an upgrade to this version of ECS CM from a version prior to 7.2.53.0, a new 4096-bit DHE key is generated. On some virtual or hardware appliances, this can lead to significant CPU and memory consumption that could impact regular virtual service traffic. Kemp strongly recommends that updates to this release from a version prior to 7.2.53.0 be performed in a maintenance interval. 

Best Practices Cipher Set

In ECS CM 7.2.52.0, the BestPractices cipher set was updated. If you are upgrading from a version prior to 7.2.52.0, this change is effective immediately after upgrade to this release. This change was made to improve security and conform to the latest industry best practices.

It is recommended, however, that you migrate your services as soon as possible to use the new BestPractices cipher set. For more information on the cipher suites removed from the set, please see the ECS CM 7.2.52.0 Release Notes.

Supported Models for Upgrade

This release of ECS CM is supported on the Hardware and Virtual models shown in the first three columns of the table below. It is not supported and should not be installed on any model listed in the two columns at right. This update patch can be applied to any supported model regardless of licensing (e.g., SPLA, MELA) or platform (e.g., hardware, local cloud, public cloud).

If your model number is not listed above, please see the list of End of Life models.

Upgrade Path

You can upgrade to this release of ECS CM from any previous 7.2.x release. For full upgrade path information, please see the article Firmware Upgrade Path.

Upgrade Patch XML File Verification Notes

By default, verification of the digital signature on upgrade images is required in ECS CM 7.2.50.0 and above. See the Update Verification Options setting under System Administration > Miscellaneous Options > WUI Settings. If the unit you are upgrading is set to require validation, you'll need to supply the XML Verification File supplied with this release.

Note that:

• In previous releases, two verification files were provided: one for pre-7.2.51 systems and one for later systems. This restriction has been removed with the 7.2.53.0 release; if upgrading from firmware 7.2.51.0 / 7.2.48.3 and above you can use the XML file provided with this release. If upgrading from any other firmware version you must following the upgrade path detailed in Firmware Upgrade Path article.
• Appliances running an ECS CM version prior to 7.2.49 do not provide the option of XML file verification in the UI or API. If you are upgrading from one of these releases to this release, you can verify the digital signatures offline using a manual process documented on the support website.

Code Signing Certificate Update

On 27 May 2022, the certificate used to sign ECS CM release artifacts for ECS CM version 7.2.56.x and prior releases expired. For most customers, this will not impact normal operations, as explained in this Announcement on the Support website.

All releases that occur after the above date (e.g., ECS CM 7.2.57.0) will be digitally signed using a newly obtained code signing certificate. 

New Features

Response Code Modification / Filtering

Response code modification (or filtering) supports the interception of specific HTML response codes received from servers behind ECS CM and the substitution of another response code and/or text to send back to the client.

This is typically used in an API Gateway deployment to hide back-end responses that might expose sensitive information to a threat actor, and could also be of use to virtually any application.

• Response code modification is a Virtual Service option and is disabled by default.
• In the UI, it's located under a Virtual Service's Advanced Settings.
• Click Show Text & Mappings to display the response code modification configuration. Note that:
  • The configuration can be edited before enabling the Response Code Modification check box.
  • If any mappings have been configured, the button text will show the number of HTML response codes that have been mapped.
• On the HTTP Response Code Management page, there are two accordions:
  • Response Text shows the text returned to clients along with the response code. The default is the standard HTML response code text and can be edited. Blank text is not allowed.
  • Response Mappings shows the currently mapped response codes; by default, this table is empty. Use the controls provided to map one or more server HTML response codes to a single code to be returned to clients.

Limitation: Any HTML response code that specifies a redirect (300-399) is only intended to be intercepted on the way from the server and a substitute response code returned to the client. There is no provision for specifying a redirect URL to send to the client.

GEO HTTP HEAD Site Health Checks

GEO site health checking has been expanded to include the HTTP HEAD method. This can be useful for many different application types. The following configuration options are supported:

• Specify the name and content of a specific header to provide to the application.
• Up to 4 custom headers can be defined per GEO Site.
• The status of the last health check performed is reflected in the UI and log.
• Return codes of 200-299, 301, 302, and 401 are interpreted to mean the server is healthy.

The following example shows how to configure an HTTP HEAD check to authenticate to the site using basic authentication via the Authorization header. The header value is “Basic”, followed by a space, followed by a base64-encoded string.

API Updates for WhatsUp Gold Integration

The LM accessv2/ API endpoint has been enhanced to improve ECS CM integration with WUG and similar API-based monitors.

• Input data can be provided in either of two ways:
  • Using a POST of JSON-format data (as in previous releases)
  • Inline in the URL using a GET command
• Basic authentication can be provided using the "Authorization" header.

This makes it possible to configure a WhatsUp Gold monitor to leverage the accessv2/ API and plot graphs on the WhatsUp Gold console using data returned by the API. An example would be using the LM API stats command to graph VS stats like totalbytes and bytespersec. See Appendix A for an example.

GEO System Information & Debug Page

A new Global Balancing > GEO System Info / Debug page provides the following status information to aid in troubleshooting DNS issues:

• GEO Configuration
• DNS Services
• Partners & Clients
• File System Stats
• GEO IP DB version

In addition, new GEO Debug Options are provided at the bottom of the page:

• Manually restart all GEO services.
• Enable/disable partner syncing. Disabling it may be useful when debugging complex environments. While its disabled, the manual sync button still operates.
• Manually sync GEO partners using verbose debug logging.
• Retrieve status of all remote cluster Virtual Services using verbose debug logging.
• Open logs (without having to go to the logging UI).
• Enable debug logging for SSH connections.
• Enable debug logging for DNS queries.

Most of these options should be used with caution and only to debug specific issues for a limited period of time. Debug logging, for example, can consume a significant amount of system resources while enabled.

WAF Logging: Splunk HEC Integration

To respond to customer requests for increased availability of LM logs to 3rd party SIEM products, WAF logging has been enhanced to support integration with Splunk via the HTTP Event Collector (HEC):

• A new Splunk Logging Format is supported for JSON remote logging, which is only displayed when the Enable Remote Logging check box is enabled.
• LM logs have been enhanced to be displayed properly by Splunk.
• Note that a SPLUNK username is used to authenticate to HEC, along with an HEC authentication token.
• A new Logging Format is supported for JSON remote logging, which is only displayed when the Enable Remote Logging check box is enabled.
• A hard-coded SPLUNK username is used to authenticate to HEC, along with an HEC authentication token.
• The Password/Token must be obtained from the HEC configuration.

HTTP Request Load Balancing

LoadMaster by default performs 'connection-based load balancing' – meaning that although many http requests are pipelined into a single connection, load balancing is performed using the information associated with the first request in the connection only.

Some customers with specific application demands require instead 'request-based load balancing" where each request in a connection is load balanced separately from other requests.

HTTP request-based load balancing is disabled by default and can be enabled using the Reschedule on every HTTP Request check box in a Virtual Service's Advanced Properties. This can be used in combination with any of the Selection Methods supported under Standard Options, but should not be used with HTTP/2 workloads.

Change Notices

ACME Support for Multiple Service Providers

The current ACME-client-based support for automated certificate management has been enhanced to support using both LetsEncrypt and DigiCert as an ACME Certificate Authority (CA) in the same deployment. In previous releases, only certificates from one CA could be managed.

If you have certificates from an ACME CA before you upgrade, those certificates are preserved. After upgrade, the UI page for selecting a CA re-appears; select your current CA provider to see your current certificates.

Related API Changes

The following changes have been made to the API to improve its usability across multiple CAs

In ECS CM 7.2.58.0, all ACME parameters are managed via set and get commands using these parameters:

• directoryurl
• renewperiod
• kid
• hmac

In ECS CM 7.2.59.0 and subsequent releases:

1. Each parameter above has it's own get/set command.
2. For all commands above, a new required parameter (acmetype), specifies the CA to which the command applies:
   • • • 1 = LetsEncrypt
       • 2 = DigiCert

Here are syntax summaries for the new API commands:

setacmedirectoryurl?directoryurl=value&acmetype={1|2}
setacmerenewperiod?renewperiod=value&acmetype={1|2}
setacmekid?kid=value&acmetype=1
setacmehmac?hmac=value&acmetype=1

getacmedirectoryurl?acmetype={1|2}
getacmerenewperiod?acmetype={1|2}
getacmekid?acmetype=1
getacmehmac?&acmetype=1

Security Updates

WAF: ModSecurity Engine Security Update

The ModSecurity engine has been updated to the version 2.9.6:

• This version closes a serious security vulnerability in how SQL commands are constructed, as detailed in https://nvd.nist.gov/vuln/detail/CVE-2022-39956.
• Additional fixes in version 2.9.6 that are unrelated to CVE-2022-39956 are listed in the ModSecurity release notes. 

Issues Resolved

ssomgr: auth_saml_post: ERROR SAML Response decode failed!

validuser: bind failed for user [k8s] ...

New Known Issues

Existing Known Issues

kernel ssomgr[46119]: segfault at <num> ip <num> sp <num> error 4
kernel L7: verify_user: Auth request failed for id 0

Appendix A: WhatsUp Gold API Integration Example

To configure a WhatsUp Gold monitor for ECS Connection Manager, do the following:

1. Log in to WhatsUp Gold and open the My Network tab.
2. Select your device from the device list and click on Properties in the upper right corner.
3. Select the “+” button and then navigate to Performance monitor-> Create.
4. Select the Rest API monitor type.
5. Fill in the form:
6. Be sure to specify the accessv2/ endpoint in the REST API URL.
7. The Method must be GET.
8. In the JSONPATH field, provide the path to the data point(s) in the Connection Manager's API's stat command JSON output to monitor. The following is what your screen should look like before saving.

9. Click Verify to test your settings.
10. Click Save.

Comments