Skip to main content
Sign in

CloudLinux Knowledge Base

  1. CloudLinux
  2. Imunify Security Products
  3. Articles

Standalone installation and configuration of Imunify360 (with integration.conf examples)

Michael Cernyavsky
  • Updated

Issue

How to install Imunify360 in standalone mode (without a control panel) and configure it using integration.conf examples?

  • The Stand-alone version of Imunify360 requires preparations for installation.
  • The integration.conf file must be filled according to your environment; otherwise, the deploy script may fail.

This article presents the minimum required settings and examples to simplify the installation steps.

Environment

  • Imunify360 (standalone deployment)
  • No control panel / No integration with standard hosting panels (e.g., cPanel, Plesk)
  • Supported OS

Solution

To install Imunify360 Stand-alone, ensure general software like a web server (Apache, Nginx, LiteSpeed), PHP, and modules such as mod_security2 and remote_ip are installed, and the OS meets the prerequisites.

  • Make sure to consider the following:
  • Once the web server and modules are configured, and a domain serves the Imunify360 web UI path, installation can continue.
  • Prepare the integration file for the environment (see attachments to this article) and proceed with the Imunify360 installation script. Note that changes in the integration file after the first installation require re-installation.
    • The following files and paths need to be created:
mkdir -p /etc/sysconfig/imunify360/generic/
touch /etc/sysconfig/imunify360/integration.conf
touch /etc/sysconfig/imunify360/generic/modsec.conf

Examples will be provided below and require adjustments for the environment.

1 . Creating an integration configuration file

Create a file named /etc/sysconfig/imunify360/integration.conf following the stand-alone manual. It should include:

Without these sections, Imunify360 Stand-alone cannot function properly.

1.1 UI Paths

The paths section points to the Imunify UI directory, setting its owner, and may look like this:

[paths] 
ui_path = /home/imunifyui/public_html 
ui_path_owner = imunifyui:apache 
[paths] 
ui_path = /var/www/vhosts/imunify360/imuify360.hosting.test.tld/html/im360 
ui_path_owner = www-data:www-data

⚠️ Note that the content inside the defined [paths.ui_path] will be overwritten.

  • The ui_path_owner can be a web-engine user or a specific user like imunifyui, but a specific user is not required for Imunify UI.
  • If using a user profile path, feel free to create the user:
useradd imunifyui
mkdir /home/imunifyui/public_html
passwd imunifyui

1.2 PAM Authentication

Set the authentication section to the system-auth method:

[pam] 
service_name = system-auth

To log in to UI, use a root privileged user, the only allowed user by default (`imunifyui` or web service users cannot log in). Admins can be specified by the admins.txt list, and other users can be defined per the manual.

1.3 Malware section

Patterns should point to the web server's public pages, e.g.:

[malware] 
basedir = /home 
pattern_to_watch = ^/home/.+?/(public_html|public_ftp|private_html)(/.*)?$ 
[malware] 
basedir = /var/www/ 
pattern_to_watch = ^/var/www/(vhosts|html)(/.*)?$

They can be absolute or relative; refer to the Python regexp manual for adjustments.

1.4 Specifying the web server variables

[web_server] 
server_type = apache 
graceful_restart_script = /usr/sbin/apachectl 
restart modsec_audit_log = /var/log/httpd/modsec_audit.log 
#modsec_audit_logdir = /var/log/modsec_audit 
[web_server] 
server_type = nginx 
graceful_restart_script = /usr/sbin/nginx -s reload 
modsec_audit_log = /var/log/nginx/modsec_audit_log 
#modsec_audit_logdir = /opt/modsecurity/var/audit
  • For issues with LiteSpeed, consider a full restart:
graceful_restart_script = /usr/bin/systemctl restart lsws
  • modsec_audit_log/ logdir parameters should refer to the ModSecurity logs.
  • Starting with Imunify360 version 7.5, a new optional parameter for checking server configuration was introduced. The config_test_script can be defined explicitly.
    • For Apache:
config_test_script = /usr/sbin/apachectl -t
    • For Nginx:
config_test_script = /usr/local/nginx/sbin/nginx -t
    • For compatibility, Imunify360 will revert to binary search if no script is specified.

1.5 Specifying panel information

Use the panel_info option in the [integration_scripts] section of integration.conf to specify your hosting panel in Imunify360/ImunifyAV.

  • This field is mandatory before installation.
[integration_scripts] 
panel_info = /etc/sysconfig/imunify360/get-panel-info.sh
  • The option should include a full path to the executable that prints JSON data in this format:
{     
  "data": {         
    "name": "MyHostingPanel",         
    "version": "1.23.4"     
  },     
  "metadata": {         
    "result": "ok"     
  } 
}
  • The script can print information in JSON format or be configured to receive details about the hosting panel. If no hosting panel exists, use this stub file: get-panel-info.sh

2. General preparation of a web server

1. Enable ModSecurity as a web server module and include directives in the configuration.

    • Use ModSecurity directives for Apache or Nginx with IncludeOptional.
    • Use ModSecurity 2.9.x for Apache and 3.0.x for Nginx (JSON support required).
    • Ensure compatibility to avoid issues.
    • Modules like mod_remoteip for Apache and ngx_http_realip_module for Nginx are needed for WebShield to recognise real IPs behind proxies. Below is an example output for Apache:
httpd -M | grep -E 'sec|rem'
remoteip_module (shared)
security2_module (shared)

2. Create a file named /etc/sysconfig/imunify360/generic/modsec.conf and include it in the web server configuration. For example:

#adding Imunify360 modsec.conf to Apache ModSecurity settings
sed -i '/<\/IfModule>/iIncludeOptional /etc/sysconfig/imunify360/generic/modsec.conf' /etc/httpd/conf.d/mod_security.conf
    • For this edit, the /etc/httpd/conf.d/mod_security.conf must have the opening tag <IfModule mod_security2.c> and defer to ModSecurity settings.
    • The content of Imunify360 modsec.conf will be created with the install-vendors command, and this file must be included in the web server configuration.

3. Uninstall other vendors like OWASP (e.g., /usr/share/modsecurity-crs/) to avoid false positives.

 # Include OWASP ModSecurity CRS rules if installed
#IncludeOptional /usr/share/modsecurity-crs/*.load
# Imunify360 rules
IncludeOptional /etc/sysconfig/imunify360/generic/modsec.conf
/IfModule>

4. For proper functionality, use SecAuditLogParts ABCFHZ to save disk space.

#checking a section parameter and log paths  
grep SecAuditLog /etc/httpd/conf.d/mod_security.conf

5. The SELinux template is now available for installation:

#adding SE WEB template
checkmodule -M -m -o /var/imunify360/imunify360.mod /opt/imunify360/venv/share/imunify360/imunify360.te
semodule_package -o /var/imunify360/imunify360.pp -m /var/imunify360/imunify360.mod
semodule -i /var/imunify360/imunify360.pp
  • Note that in older releases, this template can be placed here when executing commands.
/opt/imunify360/venv/share/imunify360/imunify360.te
  • If you host ImunifyUI in the users' directory, proceed with:
chcon -R -t httpd_sys_content_t /home/imunifyui/public_html
  • Some templates require adjustments; for example, ossec-hids may not start without:
setsebool -P domain_can_mmap_files 1
  • On a clean server, analyse the needed permissions and compile a policy as per:
cat /var/log/audit/audit.log | audit2allow -m moretypes > /var/imunify360/moretypes.te

 

3. Integration scripts

The scripts are executable files that return JSON output from predefined lists of users, domains, and administrators in fixed-format txt files. There are also ISPManager scripts and the ISPManager ImunifyAV installation guide. Values can be filled with examples:

wget https://cloudlinux.zendesk.com/hc/article_attachments/4840874408988/integration-script.tar.gz
tar -xvzf integration-script.tar.gz -C /etc/sysconfig/imunify360
chmod +x /etc/sysconfig/imunify360/get-*-script.sh
#it is needed to use get-users-script.sh scripts to avoid errors
cat << EOF > /etc/sysconfig/imunify360/users.txt 
user1:1001:user1.domain.local:user1@user1.domain.local
EOF

⚠️ Make sure to include all users that might own files in the www roots, so that these will not be skipped by the scanner. In such a case, there might be a user ID in the report instead of a username.

3.1 Admins and users list

  • Use integration scripts when users after UID_MIN in /etc/login.defs include those needing Imunify360 checks and service-created users. This ensures correct licensing by filtering users for Imunify360. The script should output both users and domains to resolve registration issues.
  • General integration scripts require listing users, domains, and admins in separate txt files, including ISPManager scripts that gather data from known paths and API.
    • The Data Format description is provided here.
  • Ensure the Malware scanner can enumerate all files in www paths by setting UID for file owners within the range of regular users per login.defs.

3.2 ModSec DomainSpecific rules

To enable domain-specific ModSecurity configuration (to disable rules for a domain), specify the modsec_domain_config_script in the integration.conf file. This should point to an executable that accepts domain-specific settings from Imunify and injects them into the web server config in JSON Lines format:

{"user": "username", "domain": "example.com", "content": "modsec config text"}
  • The modsec config text in this example is a web server-specific configuration lines that are generated by the agent as an input for the script, e.g.:
<IfModule security2_module>
SecRuleRemoveById 654 789
</IfModule>
<IfModule security3_module>
modsecurity_rules 'SecRuleRemoveById 654 789'
</IfModule>
  • The script takes JSON output from the agent, passes settings to the web server, checks the config, restarts the server, and returns error codes. If the change fails, it returns 1.
  • No fully capable script exists for every configuration; refer to ISP scripts as an example.
  • Without user and domain lists provided, disabling a rule will show an error:
imunify360-agent rules disable --id 33311 --plugin modsec --name 'Bot detection' 
WARNING: Integration config is missing modsec_domain_config_script field
  • But you can disable any rule through the global include /etc/apache2/conf.d/im360security.conf:
# cat /etc/apache2/conf.d/im360security.conf

IncludeOptional /etc/sysconfig/imunify360/generic/modsec.conf
SecAuditEngine RelevantOnly
SecConnEngine Off
SecRuleEngine On
SecRuleRemoveById 33311

4. WebShield Integration

4.1 WebShield settings

WebShield recognizes visitor IPs from trusted proxies like Cloudflare and presents Captcha to suspicious actors. It requires manual addition of the certificates cache for the Captcha functionality.

./jsupply.py -k imunify.domain.com.key -c imunify.domain.com.crt -d imunify.domain.com | im360-ssl-cache --add -
imunify360-agent config update '{"WEBSHIELD": {"enable": true, "known_proxies_support": true}}'
systemctl enable --now imunify360-webshield

4.2 Proxies

imunify360-agent remote-proxy add 192.168.0.0/24 --name "my_proxy"

5. Proactive Defense

Proactive Defense logs and aborts unsafe PHP execution as an i360.so PHP extension, which should be loaded in the web server configuration.

  • For example, for the given PHP version:
php -v | grep built 
PHP 7.2.24 (cli)
  • The approach should be:
#locate i360.so

echo 'extension=/opt/alt/php72/usr/lib64/php/modules/i360.so' > /etc/php.d/50-i360.ini
apachectl restart
  • After the web server reload, PHP should return information about the loaded module:
# php -i | grep i360

/etc/php.d/50-i360.ini
i360
i360 param => Value
i360 state => activated
i360 mode => kill
  • We provide PHP patches with our Imunify360 license to mitigate security issues in obsolete PHP versions, while PHP Auto-immunity rules block infection patterns without additional actions needed.

6. Installation

To complete the final steps of installing Imunify360, execute the deploy script by referring to our official product documentation: 📌 Standalone Installation – Imunify Product Documentation

 

Useful Links

Video instructions

Installation & prerequisites

Integration configuration

Web Server configuration

Integration scripts

Testing & troubleshooting

 

 

 

 

 

Comments

0 comments

Please sign in to leave a comment.

Related articles