Release Notes

MetaDefender ICAP Server now supports users to control proxy setting for the product via UI setting, and also proxy authentication is supported.

The new feature also provide options to define separate proxy settings for each MetaDefender ICAP Server functionalities that requires network connection.

This addition ensures consistent experience when deploying both MetaDefender Core and MetaDefender ICAP Server, streamlining the overall user experience for IT administrators.

For those customers upgrading to MetaDefender ICAP Server 5.5.1 using system proxy via environmental variable, the product will keep the same for backward compatibility.

Besides other existing filtration options, now MetaDefender ICAP Server enrich the feature to provide a way to filter requests based on request URL.

For example: below setting will filter the request which have request URL in ICAP message contain string "google.com" or begin with "https://www.opswat.com"

• Strengthen the product security to use strongest cipher AES_256_GCM to encrypt sensitive data on PostgreSQL database.
• Increase minimum password length enforcement to 30 characters.

New configuration to collect system resource information on server where MetaDefender ICAP Server resides for Splunk integration, instead of using Splunk Universal Forwarder.

• global/system_info_logging to enable/disable logging the system info. (default is disable)
• global/system_info_logging_interval to set logging interval in seconds (15 seconds by default).

More detail, refer to Configuration file

• Improved system resources utilization better.
• Enhanced scan result polling mechanism against MetaDefender Core.

• “Scan Server Became Unreachable” setting mistakenly became unchecked after upgrading from MetaDefender ICAP Server version 5.2.0 to 5.5.0.
• Failed to create SAML user directory.
• Failed to connect and setup email server when using system proxy configuration (via environmental variable).
• Base64 decoding could be incorrect when data length is not a multiply of 4
• Correct decoding for malformed base64 data whose length is not multiple of 4.

UI (frontend) issue which can workround via using REST API.

Having no impact on existing SAML directory when upgrading to MetaDefender ICAP Server 5.5.0.

The issue will be addressed on MetaDefender ICAP Server 5.5.1 or newer.

MetaDefender ICAP Server 5.1.0 or newer might not be able to work properly with Red Hat /Cent OS with its kernel 372.

The vendor Red Hat has already fixed issues with latest kernel version 425

On MetaDefender ICAP Server 5.1.0 or newer, OpenSSL 1.x is replaced by OpenSSL 3.x within the product and other dependencies (NGINX) as a security improvement, and prevent known vulnerabilities found on OpenSSL 1.x

NGINX's OpenSSL 3.x on MetaDefender ICAP Server has the enforcement in place to reject all weak cipher suites. It only accepts "HIGH" encryption cipher suites https://www.openssl.org/docs/man1.1.1/man1/ciphers.html (MD5 and SHA1 hashing based will not be accepted as well).

As a result, if you already configured MetaDefender ICAP Server for HTTPS connection, but using a weak SSL cipher with your certificate, then MetaDefender ICAP Server will not be able to start due to NGINX's OpenSSL 3.x enforcement.

MetaDefender ICAP Server v5.1.0 on Debian OS must execute 2 bellows command to connect with MetaDefender Core via TLS enable.

sudo mkdir -p /etc/pki/tls/certs/

sudo ln -s /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt

This issue has already fixed since MetaDefender ICAP Server v5.1.1