Skip to main content
Sign in

CloudLinux Knowledge Base

  1. CloudLinux
  2. Imunify Security Products
  3. Articles

Imunify360 Stand-alone installation guide with integration.conf examples

Michael Cernyavsky
  • Updated

Issue

The Stand-alone version of Imunify360 requires some preparations for installation and integration. The integration requires the integration.conf file to be filled according to your environment. Otherwise, the deploy script may fail or some functions will not work properly. This article presents the minimum required settings and provides examples to simplify the installation steps.

Environment

  • Imunify360 Stand-alone
  • No-Panel/unsupported panel
  • Supported OS

Solution

To install Imunify360 Stand-alone version it is expected that general software such as a web-server (Apache, Nginx or LiteSpeed), PHP, and modules like mod_security2 and remote_ip as described in the prerequisites is installed, and additionally, OS meet the requirements. 

 

A few more nuances are useful to consider, before proceeding:

  • For the scenarios using CloudLinux CageFS, updating Mounting Points is required.
  • Additionally, on servers with CloudLinux, user access to a socket should be prepared.
  • It is also the case that the SELinux policy should be added if SE is used.
  • If it is needed to set Imunify administrators other than root, filter out users from licensing, or to use domain-specific rules, the integration scripts are needed. 
  • Imunify firewall is using IPTables and firewalld need to be disabled.

As soon as a web server and modules are configured and a domain name serves the Imunify360 web UI path (vhost created), the installation can be continued.

 

The preparation will require to create the integration file according to the environment and proceed with the Imunify360 installation script after. Note, that if any changes are made in the integration file after the first installation, and changes are made, re-installation is required.

 

The below files and paths will be used and need to be created:

mkdir -p /etc/sysconfig/imunify360/generic/
touch /etc/sysconfig/imunify360/integration.conf
touch /etc/sysconfig/imunify360/generic/modsec.conf

The section examples will be given below and require adjustments to the particular environment.

 

1 . Creating integration configuration file

Following the stand-alone manual, it is needed first to create and prepare a file named /etc/sysconfig/imunify360/integration.conf, it should include the following sections:

Without the above sections, Imunify360 Stand-alone can not function properly.

 

1.1 UI Paths

The paths section points to Imunify UI directory and sets 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

CONTENT OF [paths.ui_path] WILL BE REMOVED.

While the ui_path_owner can be either a web-engine user or a user created specifically to own the UI path, e.g. imunifyui, it is not needed to create a specific user to use Imunify UI.

If user profile path is used, please feel free to create the user:

useradd imunifyui
mkdir /home/imunifyui/public_html
passwd imunifyui

 

1.2 The PAM section

The authentication section can be set to the system-auth method:

[pam]
service_name = system-auth

For the purpose of logging in to UI a root privileged user works and it is considered to be the only allowed user by default (note that imunifyui or web service user are not meant to be used to log in to UI). Admins can be specified by admins.txt list, and it is possible to define other users as per manual:

https://docs.imunify360.com/control_panel_integration/#define-administrators-for-imunify360

 

1.3 Malware section

Patterns should be set to 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)(/.*)?$

Those can be absolute and relative, please refer to the Python regexp manual to adjust those to your needs.

 

1.4 Specifying the webserver variables

Defaults for Apache and LiteSpeed or Nginx are below:

[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

In case of any issue with LiteSpeed, please consider using a full restart instead:

graceful_restart_script = /usr/bin/systemctl restart lsws

Meanwhile, modsec_audit_log/logdir parameters should be referring to the actual ModSec logs. After including these sections, the installation script should install Imunify360, UI should be available to set up protection mechanisms and various checks are available in the FAQ section.

Starting Imunify360 version 7.5, there new optional parameter to check server configuration was introduced for the web server section. Configuration test script config_test_script can be defined explicitly.

  1. For Apache:
config_test_script = /usr/sbin/apachectl -t

     2. For nginx:

config_test_script = /usr/local/nginx/sbin/nginx -t

For compatibility reasons, Imunify360 will fail back to binary search if script is not specified.

 

2. General preparation of a web server

ModSecurity needs to be enabled as a web server module and directives to be included in a web-server configuration. To avoid issues, ModSecurity directives for Apache or Nginx should be included as IncludeOptional. ModSecurity 2.9.x is used for Apache and ModSecurity 3.0.x is for Nginx (JSON support is required). Check that those match to make sure no issues with ModSecurity come later on.  

 

Also, the modules such as mod_remoteip for Apache and ngx_http_realip_module for Nginx are needed for WebShield to recognize real IPs behind trusted proxies. Below is an output example for an Apache webserver:

httpd -M | grep -E 'sec|rem'
remoteip_module (shared)
security2_module (shared)

 

For the above it is needed to create a file with a specific name /etc/sysconfig/imunify360/generic/modsec.conf and include to a 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 such and edit, it is assumed that the /etc/httpd/conf.d/mod_security.conf has opening tag <IfModule mod_security2.c> and entirely deferred to ModSec module related settings.

While the content of Imunify360 modsec.conf will be created with the install-vendors command, it is important that this file is included in the web server configuration.

It is also required to uninstall other vendors such as OWASP (i.e. /usr/share/modsecurity-crs/), to avoid false positives. For example, as per:

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

For our ruleset to work properly the recommended SecAuditLogParts are ABCFHZ, which will also save disk space, more on ModSec parameters can be found at https://github.com/SpiderLabs/ModSecurity:

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

 

In regard to SELinux, the template is now available to be installed:

#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

Please note that in older releases this template can be placed here, so please keep this in mind when executing the commands.

/opt/imunify360/venv/share/imunify360/imunify360.te

And if you host ImunifyUI within the users' directory, proceed with:

chcon -R -t httpd_sys_content_t /home/imunifyui/public_html

With some templates more adjustments are needed, for example, ossec-hids may not start without:

setsebool -P domain_can_mmap_files 1

In general, on a clean server it is possible to analyse the permissions needed 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 the predefined lists of users, domains, and administrators set in txt files that need to be filled with values in a fixed format. There are also ISPManager scripts, and the ISPManager ImunifyAV installation guide. Values can be filled by an 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 sctips to avoid erros
cat << EOF > /etc/sysconfig/imunify360/users.txt 
user1:1001:user1.domain.local:user1@user1.domain.local
EOF

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

3.1 Admins and users list

One reason to use integration scripts is when within the range after UID_MIN in /etc/login.defs, users may contain not only users who need to be checked with Imunify360 but also users created by some services. That is when, for correct licensing, we recommend using an integration script to filter out users, so that the right number of users with their domains that imunify360 should handle will be passed. To resolve possible registration issues both users and domains script should provide output.

There are general integration scripts that require listing users, domains, and admins in separate txt files and ISPManager oriented ones that collect data from known paths and API. The Data Format description is given on the page: https://docs.imunify360.com/installation/#data-description.

To make sure that Malware scanner can enumerate all files in www paths, please set UID for the owners of such files within the range of regular users according to login.defs.

 

3.2 ModSec DomainSpecific rules

To enable domain-specific ModSecurity configuration and be able to disable rules for particular domains only, you will need to specify the modsec_domain_config_script in the integration scripts section of integration.conf file. The parameter should point to an executable file that accepts a list of domain-specific web server settings as input from Imunify and injects those into the web server config. The standard input (stdin) should be anticipated in the JSON Lines format similar to the following:

{"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), and passes those settings to the web server configuration. It should check that the new web server config is correct and also restart the web server to apply the configuration and return error codes.  If the configuration change failed, the script should return 1.

There is yet no fully capable script adapted to every configuration, please 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 disabled 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 WebSheild settings.

WebShield is needed to recognise visitor's real IPs from trusted proxies such as CloudFalre and present suspicious actors with Captcha. It requires certificates cache to be added manually to present Captcha on domains with no issues. This process is described in our documentation: https://docs.imunify360.com/installation/#manage-webshield-ssl-cache-manually

We provide js_supply script, which simplifies this process: https://cloudlinux.zendesk.com/hc/en-us/articles/360016054460-WebShield-SSL-cache-configuration-on-Imunify360-stand-alone-installation 

Using a dummy certificate for jsupply scrips and activating WebShield may look like this:

./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

If your web server IP is behind a CDN, or the traffic is proxied otherwise, you may need to adjust the WebServer configuration to trust these subnets and read remote_ip from X-HTTP-headers:
https://docs.imunify360.com/installation/#required-web-server-configuration-to-correctly-detect-client-ip-addresses-from-headers

For example, if there are internal proxy addresses, these should be specified for the WebShield module with: 

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

 

5. Proactive Defense

Proactive Defense which logs and abort unsafe PHP execution provided as a i360.so PHP extension and it should be loaded to the web server configuration. For example for the given PHP version:

php -v | grep built
PHP 7.2.24 (cli)

The approach should be as per:

#locate i360.so
echo 'extension=/opt/alt/php72/usr/lib64/php/modules/i360.so' > /etc/php.d/50-i360.ini
apachectl restart

So that after the web server reload PHP should return information of the loaded module:

php -i | grep i360
/etc/php.d/50-i360.ini
i360
i360 param => Value
i360 state => activated
i360 mode => kill

And pass the PD tests described in our FAQ.

 

Worth mentioning that we provide alternative PHP patches built as a part of our Imunify360 license, and those can be used on the webserver to mitigate security loopholes in the obsolete PHP versions, while PHP Auto-immunity rules track what PHP execution patterns lead to infections and blocks those based on our cloud-delivered rules and there should be no additional actions required.

 

6. Installation

Proceed with the deploy script, if you have a key use it as per:

wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -O i360deploy.sh
bash i360deploy.sh --key ENTER_YOUR_KEY_HERE

Should the Installation be completed successfully, use the web to log in and proceed with further testing. You may register your deployment by a purchased key or a trial license key:

imunify360-agent register ENTER_YOUR_KEY_HERE

Otherwise, there will be warnings such as there is no IP license in the console.log file:

WARNING: {"message":"IP license not found for xx.xx.xx.xx","type":"no_ip","success":false,"data":null}

After the installation please proceed with the ModSecurity tests described in our FAQ.

 

Useful links

 

 

 

 

 

 

Comments

0 comments

Please sign in to leave a comment.

Related articles