<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5HLVVHN" height="0" width="0" style="display:none;visibility:hidden">

Release Notes: Imunify360 v.5.7 beta

IM-beta-release

We’re pleased to announce that a new beta version of Imunify360, version 5.7, is now available. The following features are new in the v.5.7 beta release:

  • Apache + ModSecurity version 3 support on cPanel (experimental)
    Imunify360 v5.7 added support of ModSecurity version 3 on cPanel.

  • Improved WebShield iptables functionality
    Improvement in WebShield operation. In case of any malfunction the system will fall back on standard configuration automatically and no requests will be blocked or lost.

  • WordPress core files protection
    A new way to ensure protection of the legit WordPress core files and folders from any malicious modification and execution.

  • Active Response enhancement: custom SSH ports support
    Flexible sshd protection regardless of port number. Imunify360 v5.7 detects the used port and protects it accordingly.

  • Conceal passwords in logs
    A better way to pass sensitive data. Passwords are passed to commands in a secure way.

  • OSSEC logs rotation
    Changes allow to make sure that OSSEC logs will not increase in size exceeding the limit.

  • Better Ezoic CDN support
    In Imunify360 v5.7 we’ve added an option to trust Ezoic CDN headers and resolve CAPTCHA.

This is what we’ve updated in version 5.7: 

Apache + ModSecurity version 3 support on cPanel (experimental)

Beginning with version 92, cPanel added experimental support for ModSecurity 3.x. We follow suit and are broadening our scope by implementing the experimental support of ModSecurity version 3.x on cPanel. Starting with version 5.7, Imunify360 extends its support for ModSecurity 3.x. There are limitations. Not all features are yet implemented in the ModSecurity 3 module. The feature limitations are: working with mod_ruid2, working with mod_remoteip, app-specific ruleset feature, HackerTrap, uploaded files scanning, simple password redirect.

Please share your experience with us on feedback@imunify360.com.

Improved WebShield iptables functionality

In version 5.7, we improved WebShield’s reliability by adding a new self-check cron job. It changes iptables settings depending on WebShield status and automatically redirects suspicious traffic to WebShield if it’s operating normally. But should anything ever happen to the WebShield, for example any sort of malfunction or glitch, this situation will be quickly detected and the traffic redirection to the WebShield will be disabled, therefore maintaining smooth web-hosting work. Customers will not face any inconvenience and maintain access to the website.

Proactive Defense extension: WordPress core files protection

The recent Proactive Defense version got a new set of rules to protect WordPress core files from modifications and malicious drops into CMS system folders. Many infections in WordPress - malicious standalone files or malware injections are happening with WordPress core folders wp-admin and wp-includes. We came up with a way to: 

  • collect, store and update list of legit WP core files
  • protect wp-admin/wp-includes legit core files from malicious modification
  • prevent upload of malicious files to wp-admin/wp-includes folders and sub-folders
  • forbid wp-admin/wp-includes malicious files execution
  • forbid wp-admin/wp-includes malicious files include

Proactive Defense prevents WordPress infection and re-infection by automated malicious tools and hacker’s services via PHP vulnerabilities and compromised WordPress admin access.

The feature is controlled by the Proactive Defense rules 13500, 13501, 13502, 13503. The rules will be applied and will be enabled automatically upon the Imunify360 update.

Active Response enhancement: custom SSH ports support

Customer input indicated that SSH is not always configured for port 22 but instead may have an unusual configuration. We opted for dynamic detection of all ports to be protected in the Active Response scripts.If your system has an SSH configuration that is different from the standard and you prefer to use Active Response for its protection, switching is relatively easy. Just enable Active Response and Imunify360 will do the rest of the job for you.

To enable Active Response, do the following:

On the Imunify360 panel, go to Settings, pick “General,” and look for the Active response option. Note that for this option to be available, PAM has to be disabled.

or use CLI: 

imunify360-agent config update '{"PAM": {"enable": false, "exim_dovecot_protection": false}, {"OSSEC": {"active_response": true}}'

Conceal passwords in logs

There are specific bits of sensitive information transferred in the system. We always strive to provide you with a safer way to work with them. For example, a root password in logs and `ps`, when the administrator uses the commands: 

  • `imunify360-agent login pam --username ... --password ...` or 
  • `backup-systems init

Now data transfer has a greater security level, which conceals the value from a potential malicious actor. Sensitive information transfer occurs via environment variables.

Examples:

  • REG_KEY=license_key imunify360-agent register
  • PASSWORD=’P@ssw0rd’ imunify360-agent backup-systems init acronis --username user@123.org
  • PASSWORD=’P@ssw0rd’ imunify360-agent login pam --username user1

For backward compatibility, the previous methods still work. However, we strongly recommend you change the way you use the above commands.

OSSEC logs rotation

Log files in /var/ossec/logs/alerts directory may sometimes grow bigger in size than necessary and become a nuisance, occupying extra space on the disk. There is a fix for this nuisance. The system automatically purges outdated logs (logs older than two days). The system also purges logs no longer needed for exploit investigation. There is no reason to keep this data because it gets automatically copied into Imunify360’s incident table. The result is the elimination of log-flooding.

Better Ezoic CDN support

Our customers sometimes face CAPTCHA issues. For example, legit customers on their sites working with Ezoic CDN encounter CAPTCHA issues. After investigating the problem, we discovered a dynamic list of servers used by CDN over a wide range of Google Cloud IPs that we can’t blindly trust. For such cases, we came up with an easy and elegant solution. We added the “trust_ezoic” option for WebShield, which authorizes IPs that Ezoic CDN specifies as their servers. By default the option is off. If needed, there is a straightforward way to switch it on. Be aware when вeciding to use this option - the list of Ezoic CDN servers is quite extensive and includes ranges that someone else in Amazon EC2 can control.

To enable it, open

/etc/imunify360-webshield/virtserver.conf,

find the directive set

$trust_ezoic 0;

replace '0' with '1', save the file and restart WebShield, using the following command

# service imunify360-webshield restart

Additional information

Imunify360 v5.7 includes 89 tasks and 27 bug fixes.

Internal records

DEF-14808
DEF-14811
DEF-14810
DEF-14809

Collect statistics to monitor if any changes affected server load/connection number
DEF-16064
DEF-16053
DEF-16026
DEF-15991
DEF-15983
DEF-15934
DEF-15903
DEF-15869
DEF-15852
DEF-15815
Deobfuscator enhancement
DEF-15537 Allowing customers to use relative path when submitting false-positive/false-negative
DEF-16069 Fix decode error with 'utf-8' codec
DEF-15914 Fix custom branding of captcha page
DEF-15936 WebShield watchdog script now creates a flag file to inform the agent that WebShield is not accessible
DEF-15634 Fix for enabling the FTP brute force protection
DEF-15810 Fix for cleanup option in GUI
DEF-16105 Fix for HTML files cleanup
DEF-16129 Fix for traceback in case of CLI parts missing
DEF-15572 Fix for ValueError: embedded null byte
DEF-14405 Fix for FileNotFoundError

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Stay in touch

Please give our product team feedback on this version 5.7 release, or share your ideas and feature requests via feedback@imunify360.com.

If you encounter any problems with this beta release, please send a comment or request to our Imunify support team via cloudlinux.zendesk.com.

How to install

To install the new Imunify360 v.5.7 beta, please follow the instructions in the documentation.

How to upgrade

To upgrade Imunify360 on CentOS/CloudLinux systems, run the command:

yum update imunify360-firewall --enablerepo=imunify360-testing

To upgrade Imunify360 on Ubuntu 16.04, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/ubuntu-testing/16.04/ xenial main' > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

To upgrade Imunify360 on Ubuntu 18.04, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/ubuntu-testing/18.04/ bionic main' > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

To upgrade Imunify360 on Ubuntu 20.04, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/ubuntu-testing/20.04/ focal main' > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

 

To upgrade Imunify360 on Debian 9, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/debian-testing/9/ stretch main'  > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

To upgrade Imunify360 on Debian 10, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/debian-testing/10/ buster main'  > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

Release Notes: Imunify360 v.5.7 beta

IM-beta-release

We’re pleased to announce that a new beta version of Imunify360, version 5.7, is now available. The following features are new in the v.5.7 beta release:

  • Apache + ModSecurity version 3 support on cPanel (experimental)
    Imunify360 v5.7 added support of ModSecurity version 3 on cPanel.

  • Improved WebShield iptables functionality
    Improvement in WebShield operation. In case of any malfunction the system will fall back on standard configuration automatically and no requests will be blocked or lost.

  • WordPress core files protection
    A new way to ensure protection of the legit WordPress core files and folders from any malicious modification and execution.

  • Active Response enhancement: custom SSH ports support
    Flexible sshd protection regardless of port number. Imunify360 v5.7 detects the used port and protects it accordingly.

  • Conceal passwords in logs
    A better way to pass sensitive data. Passwords are passed to commands in a secure way.

  • OSSEC logs rotation
    Changes allow to make sure that OSSEC logs will not increase in size exceeding the limit.

  • Better Ezoic CDN support
    In Imunify360 v5.7 we’ve added an option to trust Ezoic CDN headers and resolve CAPTCHA.

This is what we’ve updated in version 5.7: 

Apache + ModSecurity version 3 support on cPanel (experimental)

Beginning with version 92, cPanel added experimental support for ModSecurity 3.x. We follow suit and are broadening our scope by implementing the experimental support of ModSecurity version 3.x on cPanel. Starting with version 5.7, Imunify360 extends its support for ModSecurity 3.x. There are limitations. Not all features are yet implemented in the ModSecurity 3 module. The feature limitations are: working with mod_ruid2, working with mod_remoteip, app-specific ruleset feature, HackerTrap, uploaded files scanning, simple password redirect.

Please share your experience with us on feedback@imunify360.com.

Improved WebShield iptables functionality

In version 5.7, we improved WebShield’s reliability by adding a new self-check cron job. It changes iptables settings depending on WebShield status and automatically redirects suspicious traffic to WebShield if it’s operating normally. But should anything ever happen to the WebShield, for example any sort of malfunction or glitch, this situation will be quickly detected and the traffic redirection to the WebShield will be disabled, therefore maintaining smooth web-hosting work. Customers will not face any inconvenience and maintain access to the website.

Proactive Defense extension: WordPress core files protection

The recent Proactive Defense version got a new set of rules to protect WordPress core files from modifications and malicious drops into CMS system folders. Many infections in WordPress - malicious standalone files or malware injections are happening with WordPress core folders wp-admin and wp-includes. We came up with a way to: 

  • collect, store and update list of legit WP core files
  • protect wp-admin/wp-includes legit core files from malicious modification
  • prevent upload of malicious files to wp-admin/wp-includes folders and sub-folders
  • forbid wp-admin/wp-includes malicious files execution
  • forbid wp-admin/wp-includes malicious files include

Proactive Defense prevents WordPress infection and re-infection by automated malicious tools and hacker’s services via PHP vulnerabilities and compromised WordPress admin access.

The feature is controlled by the Proactive Defense rules 13500, 13501, 13502, 13503. The rules will be applied and will be enabled automatically upon the Imunify360 update.

Active Response enhancement: custom SSH ports support

Customer input indicated that SSH is not always configured for port 22 but instead may have an unusual configuration. We opted for dynamic detection of all ports to be protected in the Active Response scripts.If your system has an SSH configuration that is different from the standard and you prefer to use Active Response for its protection, switching is relatively easy. Just enable Active Response and Imunify360 will do the rest of the job for you.

To enable Active Response, do the following:

On the Imunify360 panel, go to Settings, pick “General,” and look for the Active response option. Note that for this option to be available, PAM has to be disabled.

or use CLI: 

imunify360-agent config update '{"PAM": {"enable": false, "exim_dovecot_protection": false}, {"OSSEC": {"active_response": true}}'

Conceal passwords in logs

There are specific bits of sensitive information transferred in the system. We always strive to provide you with a safer way to work with them. For example, a root password in logs and `ps`, when the administrator uses the commands: 

  • `imunify360-agent login pam --username ... --password ...` or 
  • `backup-systems init

Now data transfer has a greater security level, which conceals the value from a potential malicious actor. Sensitive information transfer occurs via environment variables.

Examples:

  • REG_KEY=license_key imunify360-agent register
  • PASSWORD=’P@ssw0rd’ imunify360-agent backup-systems init acronis --username user@123.org
  • PASSWORD=’P@ssw0rd’ imunify360-agent login pam --username user1

For backward compatibility, the previous methods still work. However, we strongly recommend you change the way you use the above commands.

OSSEC logs rotation

Log files in /var/ossec/logs/alerts directory may sometimes grow bigger in size than necessary and become a nuisance, occupying extra space on the disk. There is a fix for this nuisance. The system automatically purges outdated logs (logs older than two days). The system also purges logs no longer needed for exploit investigation. There is no reason to keep this data because it gets automatically copied into Imunify360’s incident table. The result is the elimination of log-flooding.

Better Ezoic CDN support

Our customers sometimes face CAPTCHA issues. For example, legit customers on their sites working with Ezoic CDN encounter CAPTCHA issues. After investigating the problem, we discovered a dynamic list of servers used by CDN over a wide range of Google Cloud IPs that we can’t blindly trust. For such cases, we came up with an easy and elegant solution. We added the “trust_ezoic” option for WebShield, which authorizes IPs that Ezoic CDN specifies as their servers. By default the option is off. If needed, there is a straightforward way to switch it on. Be aware when вeciding to use this option - the list of Ezoic CDN servers is quite extensive and includes ranges that someone else in Amazon EC2 can control.

To enable it, open

/etc/imunify360-webshield/virtserver.conf,

find the directive set

$trust_ezoic 0;

replace '0' with '1', save the file and restart WebShield, using the following command

# service imunify360-webshield restart

Additional information

Imunify360 v5.7 includes 89 tasks and 27 bug fixes.

Internal records

DEF-14808
DEF-14811
DEF-14810
DEF-14809

Collect statistics to monitor if any changes affected server load/connection number
DEF-16064
DEF-16053
DEF-16026
DEF-15991
DEF-15983
DEF-15934
DEF-15903
DEF-15869
DEF-15852
DEF-15815
Deobfuscator enhancement
DEF-15537 Allowing customers to use relative path when submitting false-positive/false-negative
DEF-16069 Fix decode error with 'utf-8' codec
DEF-15914 Fix custom branding of captcha page
DEF-15936 WebShield watchdog script now creates a flag file to inform the agent that WebShield is not accessible
DEF-15634 Fix for enabling the FTP brute force protection
DEF-15810 Fix for cleanup option in GUI
DEF-16105 Fix for HTML files cleanup
DEF-16129 Fix for traceback in case of CLI parts missing
DEF-15572 Fix for ValueError: embedded null byte
DEF-14405 Fix for FileNotFoundError

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Stay in touch

Please give our product team feedback on this version 5.7 release, or share your ideas and feature requests via feedback@imunify360.com.

If you encounter any problems with this beta release, please send a comment or request to our Imunify support team via cloudlinux.zendesk.com.

How to install

To install the new Imunify360 v.5.7 beta, please follow the instructions in the documentation.

How to upgrade

To upgrade Imunify360 on CentOS/CloudLinux systems, run the command:

yum update imunify360-firewall --enablerepo=imunify360-testing

To upgrade Imunify360 on Ubuntu 16.04, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/ubuntu-testing/16.04/ xenial main' > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

To upgrade Imunify360 on Ubuntu 18.04, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/ubuntu-testing/18.04/ bionic main' > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

To upgrade Imunify360 on Ubuntu 20.04, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/ubuntu-testing/20.04/ focal main' > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

 

To upgrade Imunify360 on Debian 9, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/debian-testing/9/ stretch main'  > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall

To upgrade Imunify360 on Debian 10, run the following command:

echo 'deb https://repo.imunify360.cloudlinux.com/imunify360/debian-testing/10/ buster main'  > /etc/apt/sources.list.d/imunify360-testing.list
apt-get update
apt-get install --only-upgrade imunify360-firewall
Subscribe to Imunify security Newsletter