Imunify360 Stand-alone

Previously, Imunify360 had to be installed through a particular control panel, such as cPanel, DirectAdmin, or Plesk. Now, with version 4.5, it can be installed directly on the server, independent of any panel, regardless of the administrative interface.

Beta Limitations

This version is released as beta and our product team is looking for feedback and possible issues. You can drop any feedback to feedback@imunify360.com.

Beta version limitations

  • No WebShield support yet (Captcha, GreyList and etc.)
  • Support for apache server only, Nginx/LiteSpeed/OpenLiteSpeed are coming
  • No support for managing disabled rules yet. See also: Disabled rules

Requirements

Operating system

  • CentOS 6/7
  • RHEL 6/7
  • CloudLinux OS
  • Ubuntu 16.04/18.04

Web servers

  • Apache

There are four main steps in general required for having Imunify360 Stand-alone running on your server:

  1. Install and configure the prerequisites like web servers modules or so
  2. Configure Imunify360 integrations like authentication or mod_security configuration
  3. Install Imunify360
  4. Change default Imunify360 settings to reflect your needs

1. Prerequisites

Imunify360 Stand-alone version requires the following components installed or enabled at the server:

  • ModSecurity 2.9.x
  • Apache module mod_remoteip
  • PHP with proc_open function enabled (remove it from the disable_functions list in php.ini)

2. Configure Imunify360 integrations

Imunify360 Stand-alone version require the following integrations before installation:

  • Integration with web server for serving UI
  • Integration with ModSecurity
  • Integration with Malware scanner
  • Integration with authentication service
  • Define administrators for Imunify360

All integrations set in the integration config file like /etc/sysconfig/imunify360/integration.conf. You can find more details on config file here.

Integration with web server

Imunify360 UI is implemented as a single-page application (SPA) and requires a web server to serve it. It’s required to specify a path to the web server directory, where the Imunify360 UI SPA application will be installed and served.

Example

[paths]
ui_path = /var/www/vhosts/imunify360/imunify360.hosting.example.com/html/im360

Ensure that the domain you are going to use for the Imunify360 web-based UI refers to this path and that there are no other scripts or files under ui_path, as they might be overridden by Imunify360 installation.

Interaction with ModSecurity

Configure ModSecurity configuration directives (so that it can block):

SecAuditEngine = "RelevantOnly"
SecConnEngine = "Off"
SecRuleEngine = "On"

Create the empty file /etc/sysconfig/imunify360/generic/modsec.conf and include it into the web server config as IncludeOptional. The file would be replaced with the actual config during the first Imunify360 installation or you can fill it via calling the Imunify360 ModSec ruleset installation imunify360-agent install-vendor.

Set the path and graceful restart script in the integration.conf

  • [web_server].graceful_restart_script – a script that restarts the web server to be called after any changes in web server config or ModSecurity rules
  • [web_server].modsec_audit_log​ – a path to ModSecurity audit log file
  • [web_server].modsec_audit_logdir​ – a path to ModSecurity audit log dir

Example

[web_server]
server_type = apache
graceful_restart_script = /path/to/a/script/that/restarts/web-server/properly
modsec_audit_log = /var/log/httpd/modsec_audit.log
modsec_audit_logdir = /var/log/modsec_audit

To enable domain-specific ModSecurity configuration, specify the modsec_domain_config_script in the integration.conf.

[web_server]
modsec_domain_config_script = /path/to/inject/domain/specific/config/script.sh

It should point to an executable file that accepts as an input a list of domain-specific web server settings and injects them into the server config. The standard input (stdin) is given in the JSON Lines format similar to the following:

{"user": "username", "domain": "example.com", "config": "modsec config text"}
{"user": "another", "domain": "another.example.com", "config": "..."}

Each line contains config for a single domain e.g., it may contain rule tags excluded for the domain. The script should also restart the web server to apply the configuration. This should be done so that the script could implement the check that web server comes up after config change, and reset configuration if it doesn't.

If configuration change failed, the script should return 1, and in the standard error stream (stderr) it should return the reason for failure. On success, the script should return 0. In a single run of the script, we might update a single domain/user, as well as multiple users (all users) on the system.

Integration with malware scanner

To scan files uploaded via FTP, configure PureFTPd. Write in the pure-ftp.conf:

CallUploadScript             yes

To scan files for changes (to detect malware) using inotify, configure which directories to watch and which to ignore in the integration.conf file:

  • configure [malware].basedir – a root directory to watch (recursively)
  • configure [malware].pattern_to_watch – only directories that match this (Python) regex in the basedir are actually going to be watched

Example

basedir = /home
pattern_to_watch = ^/home/.+?/(public_html|public_ftp|private_html)(/.*)?$

Integration with authentication service

Imunify360 Stand-alone version can use PAM service to authenticate users for the Imunify360 UI application.

You can specify which PAM service Imunify360 should use with the service_name option:

[pam]
service_name = system-auth

Define administrators for Imunify360

The administrators have full access to Imunify360 UI and its settings.

By default, root is considered to be the only admin user.

To add more administrators, list them in the /etc/sysconfig/imunify360/auth.admin file or specify the admins option in the /etc/sysconfig/imunify360/integration.conf

Note

If some integration script is not found in integration_scripts section of /etc/sysconfig/imunify360/integration.conf, we will look for it in /opt/cpvendor/etc/integration.ini too.
If integration_scripts.admins is defined in any of them, it is used instead of /etc/sysconfig/imunify360/auth.admin

[integration_scripts]
admins = /path/to/get-admins-script.sh

It should point to an executable file that generates a JSON file similar to the following:

{
  "data": [
    {
      "name": "admin1",
      "unix_user": "admin",
      "locale_code": "EN_us",
      "email": "admin1@domain.zone",
      "is_main": true
    },
	{
      "name": "admin2",
      "unix_user": "admin",
      "locale_code": "Ru_ru",
      "email": "admin2@domain.zone",
      "is_main": false
    },
  ],
  "metadata": {
    "result": "ok"
  }
}

3. Install Imunify360

The installation instructions are the same as for cPanel/Plesk/DirectAdmin version and can be found in the Imunify360 documentation.

The web-based UI is available via the domain configured in the ui_path.

For example, if /var/www/vhosts/imunify360/imunify360.hosting.example.com/html/im360 is the document root folder for the imunify360.hosting.example.com domain, then you could open Imunify360 with the following URL:

  • https://imunify360.hosting.example.com/ (when you have TLS certificate configured for the domain) or
  • http://imunify360.hosting.example.com/

4.1 Use a specific list of users in Imunify360

By default, Imunify360 will use Linux system users, limited by uid_min and uid_max from the /etc/login.defs.

If you want to see a specific list of users (note, that all of them must be real Linux users accessible via PAM), you can specify the users option in the /etc/sysconfig/imunify360/integration.conf:

[integration_scripts]
users = /path/to/get-users-script.sh

It should point to an executable file that generates a JSON file similar to the following (see details here):

{
  "data": [
    {
      "id": 1000,
      "username": "ins5yo3",
      "owner": "root",
      "domain": "ins5yo3.com",
      "package": {
        "name": "package",
        "owner": "root"
      },
      "email": "ins5yo3@ins5yo3.com",
      "locale_code": "EN_us"
    },
    {
      "id": 1001,
      "username": "ins5yo4",
      "owner": "root",
      "domain": "ins5yo4.com",
      "package": {
        "name": "package",
        "owner": "root"
      },
      "email": "ins5yo4@ins5yo4.com",
      "locale_code": "EN_us"
    }
  ],
  "metadata": {
    "result": "ok"
  }
}

4.2 Use server domains

To provide a list of domains for Imunify360, specify the script that generates a JSON file in the /etc/sysconfig/imunify360/integration.conf:

[integration_scripts]
domains = /path/to/get-domains-script.sh

A JSON file should be similar to the following:

{
  "data": {
    "example.com": {
      "document_root": "/home/username/public_html/",
      "is_main": true,
      "owner": "username",
    },
    "subdomain.example.com": {
      "document_root": "/home/username/public_html/subdomain/",
      "is_main": false,
      "owner": "username",
    }
  },
  "metadata": {
    "result": "ok"
  }
}

web_server_config_path should point to a path that is added as IncludeOptional in this domain's virtual host e.g., /path/to/example.com/specific/config/to/include path should be added for the example.com domain.

Integration config file

The documentation for the Imunify360 Stand-alone version integration configuration file format.

Location /etc/sysconfig/imunify360/integration.conf

Parameters

[paths]
ui_path = /var/www/vhosts/imunify360/imunify360.hosting.example.com/html/im360

The path to the web server directory, where Imunify360 will be installed and served by web server. Need to be defined before Imunify360 installation.

[pam]
service_name = system-auth

The PAM service is used for user authentication in the Imunify360 UI application. By default the system-auth service is used.

[integration_scripts]
admins = /path/to/get-admins-script.sh

The path to the executable script that generates a JSON file with the list of admin accounts.

{
  "data": [
    {
      "name": "admin1",
      "unix_user": "admin",
      "locale_code": "EN_us",
      "email": "admin1@domain.zone",
      "is_main": true
    },
	{
      "name": "admin2",
      "unix_user": "admin",
      "locale_code": "Ru_ru",
      "email": "admin2@domain.zone",
      "is_main": false
    },
  ],
  "metadata": {
    "result": "ok"
  }
}
[integration_scripts]
users = /path/to/get-users-script.sh

The script to provide the specific list of users used by Imunify360.

It should point to an executable file that generates a JSON file similar to the following (domains are optional):

{
  "data": [
    {
      "id": 1000,
      "username": "ins5yo3",
      "owner": "root",
      "domain": "ins5yo3.com",
      "package": {
        "name": "package",
        "owner": "root"
      },
      "email": "ins5yo3@ins5yo3.com",
      "locale_code": "EN_us"
    },
    {
      "id": 1001,
      "username": "ins5yo4",
      "owner": "root",
      "domain": "ins5yo4.com",
      "package": {
        "name": "package",
        "owner": "root"
      },
      "email": "ins5yo4@ins5yo4.com",
      "locale_code": "EN_us"
    }
  ],
  "metadata": {
    "result": "ok"
  }
}

Data description

Key Nullable Description
id False ID of the UNIX account in the system.
username False The name of the UNIX account in the system.
owner True The name of the account owner. The owner can be an administrator (in this case he should be included in the admins() output) or a reseller (in this case he should be included in the resellers() output).
locale_code True The locale selected by a user.
email True Email of the account user. If there is no email, it should return null.
domain True The main domain of a user.
package True Information about the package to which a user belongs to. If the user doesn’t belong to any package, it should return null.
package.name False The name of the package to which a user belongs to.
package.owner True The owner of the package to which a user belongs to (reseller or administrator).
[integration_sctipts]
domains = /path/to/get-domains-script.sh

It should point to an executable file that generates a JSON file similar to the following

{
  "data": {
    "example.com": {
      "document_root": "/home/username/public_html/",
      "is_main": true,
      "owner": "username",
    },
    "subdomain.example.com": {
      "document_root": "/home/username/public_html/subdomain/",
      "is_main": false,
      "owner": "username",
    }
  },
  "metadata": {
    "result": "ok"
  }
}

web_server_config_path should point to a path that is added as IncludeOptional in this domain's virtual host e.g., /path/to/example.com/specific/config/to/include path should be added for the example.com domain.