Release Notes: Imunify360 v.5.7 beta
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 |
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