To use external files with the list of Black/White IPs, place this list into the following directory:
/etc/imunify360/whitelist/*.txt
/etc/imunify360/blacklist/*.txt
The files may have IP addresses or subnet in CIDR notation.
In order to apply the IP lists, run the following command:
imunify360-agent reload-lists
Or restart the agent.
Warning
Specifying IPs in those files will not prevent Imunify from adding the same IPs to dynamic lists (like Gray list), but all White lists always have the priority over Black lists when it comes to actual filtering of requests/packages.
The RapidScan feature increases scanning speed by lowering system resource usage. Increased scanning speeds and a higher scanning rate further hardens system security posture.
After enabling the RapidScan feature, the next scan runs with the usual speed. However, the subsequent scans speeds will improve, and they will run anywhere between 5 to 20 times faster. This is the case for both on-demand and scheduled scans, and it means, among other things, you can can increase scan frequency without affecting system performance.
To take advantage of this feature, go to your Imunify360 control panel and enable RapidScan in Settings→Malware Scanner. Please see the details here.
This is a special operation mode where Imunify360 consumes less CPU and RAM. It is intended for servers with limited resources.
This mode disables WebShield switching off GrayList and Captcha.
Low Resource Usage mode also enables the Minimized Modsec Ruleset option that disables Imunify WAF rules with a high memory footprint, leaving critical rulesets enabled.
When the Low Resource Usage mode is activated it is reflected on the UI: an Imunify main menu changes color to light green, and an appropriate label appears on the top right.
You can switch the mode via CLI and in the UI.
In CLI, run the following commands:
imunify360-agent config update '{"WEBSHIELD": {"enable": true}}'
imunify360-agent config update '{"MOD_SEC": {"ruleset": "FULL"}}'
In the UI, do the following steps:
Note
cPanel only, other panels will be added later
Exim+Dovecot brute-force attack protection is an advanced protection against Dovecot brute-force attacks. PAM module protects against IMAP/POP3 brute-force attack and prevents mail account from being compromised via brute-forcing.
How to enable Dovecot
We recommend using Imunify360 agent config to enable Dovecot because this allows to correctly switch OSSEC rules/configs:
imunify360-agent config update '{"PAM": {"enable": true, "exim_dovecot_protection": true}}'
How to disable Dovecot
To disable all PAM module via config file:
imunify360-agent config update '{"PAM": {"enable": false, "exim_dovecot_protection": false}}'
To disable only Exim+Dovecot via config file:
imunify360-agent config update '{"PAM": {"exim_dovecot_protection": false}}'
The options of the pam_imunufy
are placed in the file: /etc/pam_imunify/i360.ini
Values
USER_LOCK_TIMEOUT=5 | a period of time during which a user should be blocked (minutes) |
USER_LOCK_ATTEMPTS=10 | a number of attempts after which a user should be blocked |
USER_LOCK_MINUTES=5 | a period of time (minutes) during which violation attempts from a user are counted; all attempts earlier than USER_LOCK_MINUTES are not counted |
USER_IP_LOCK_TIMEOUT=5 | a period of time during which a user + IP should be blocked (minutes) |
USER_IP_LOCK_ATTEMPTS=10 | a number of attempts after which a user + IP should be blocked |
USER_IP_LOCK_MINUTES=5 | a period of time (minutes) during which violation attempts from a user + IP are counted; all attempts earlier than USER_IP_LOCK_MINUTES are not counted |
IP_LOCK_TIMEOUT=5 | a period of time during which an IP should be blocked (minutes) |
IP_LOCK_ATTEMPTS=10 | a number of attempts after which an IP should be blocked |
IP_LOCK_MINUTES=5 | a period of time during which violation attempts from an IP are counted; all attempts earlier than IP_LOCK_MINUTES are not counted |
rbl=net-brute.rbl.imunify.com. | RBL DNS Zone |
RBL_timeout=5 | this is the wait time for a response from RBL |
RBL_nameserver=ns1-rbl.imunify.com:53 | NS Server |
Notes
Default RBL block time for IP = 4 hours.
How to apply settings
In order to apply new settings in the /etc/pam_imunify/i360.ini
, run the following command:
systemctl restart imunify360-pam
During the last XXX_LOCK_MINUTES
we count the number of login failures (unsuccessful login attempts). If the number of attempts exceeds the specified threshold XXX_LOCK_ATTEMPTS
, the PAM plugin blocks access for XXX_LOCK_TIMEOUT
minutes. After that, the counter is reset and the process repeats.
Note that the plugin has three separate counters and a set of settings for USER/IP/USER+IP management regarding brute-force attacks (see the table above).
Notes
USER_LOCK_ATTEMPTS
, then this user will not have access to the server from any IPUSER_IP_LOCK_ATTEMPTS
, then this user will not have access to the server from that specific IPIP_LOCK_ATTEMPTS
, then all users will not have access to the server from that specific blocked IPDovecot native brute force protection module improves stability and resolves issues that standard PAM caused in some cases
There were situations when login with enabled PAM would produce log messages like these:
Jun 9 14:45:04 Hostl6 dovecot: auth-worker(31382): Error: pam(user@example.org,<IP>,<SESSION>): Multiple password values not supported
Jun 9 14:45:10 Hostl6 dovecot: pop3-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<user@example.org>, method=PLAIN, rip=<IP>, lip=<IP>, TLS, session=<SESSION>
This happened due to the specificity of PAM’s architecture and the way it processes such cases. We decided to develop a completely new native module for Dovecot with brute force protection functionality. With the new module, Dovecot will not produce any more error messages similar to shown above.
Since the module is fresh, it is in experimental mode – disabled by default for now. This will be changed to “enabled by default” state in later releases.
Now two options can be used to control how brute force protection works for Dovecot:
Condition | Behavior | |
---|---|---|
PAM.exim_dovecot_protection | PAM.exim_dovecot_native | |
Dovecot protection disabled | ||
Dovecot protection enabled (default)
| ||
Dovecot protection enabled
|
The following commands can be used to control the Dovecot native module:
Enable:
# imunify360-agent config update '{"PAM": {"exim_dovecot_native": true}}'
Disable (default):
# imunify360-agent config update '{"PAM": {"exim_dovecot_native": false}}'
Starting from version 4.10, an administrator is able to configure email addresses to submit reports and execute custom scripts. Go to Settings and choose Notifications tab.
The following events are available.
Occurs when malware is detected during the real-time scanning.
Occurs immediately after the user scanning has started.
Occurs immediately after on-demand (manual) scanning has started.
Occurs immediately after the user scanning has finished, regardless the malware has found or not.
Occurs immediately after on-demand (manual) scanning has finished, regardless the malware has found or not.
Occurs when the on-demand scanning process has finished and malware found.
Occurs when the malware scanning process of a user account has finished and malware found.
Occurs when the Proactive Defense has blocked malicious script.
Click Save changes at the bottom to apply all changes.
Malware Database Scanner (MDS) is designed to solve all malware related problems in the database.
Note
Version Imunify360 6.0 or later supports the use of MDS in UI.
Warning
For now, Malware Database Scanner (MDS) supports WordPress databases only.
To provide safe work with database MDS supports several methods:
--scan
- only scan the database, no changes will be applied--clean
- scan database and clean-up malicious--restore
- restore data affected by clean-up from the backup CSV fileNote
“Clean” operation includes “scan”, so you don’t need to run a scan before the cleanup. Whereas the “scan” can be used for non-disruptive checks of the database. Cleanup mode creates a backup file that can be used to rollback all changes back. It makes MDS safe to use and prevents websites from breaking and data loss.
The easiest way to use MDS is to run it with --search-configs
argument: MDS will try to find the config files and print out database credentials that should be later specified for scanning.
--creds-from-xargs
argument can be used to run MDS without a need to manually enter credentials. It allows automating the process of credentials discovery and the scan process.
/opt/ai-bolit/wrapper /opt/ai-bolit/imunify_dbscan.php [OPTIONS] [PATH]
Options
--host=<host> | Database host |
--port=<port> | Database port |
--login=<username> | Database username |
--password=<password> | Database password |
--password-from-stdin | Get database password from stdin |
--database=<db_name> | Database name |
--prefix=<prefix> | Prefix for table |
--scan | Do scan |
--clean | Do clean |
--search-configs | Find the config files and print out database credentials |
--creds-from-xargs | Discover credentials and do scan |
--report-file=<filepath> | Filepath where to put the report |
--signature-db=<filepath> | Filepath with signatures |
--progress=<filepath> | Filepath with progress |
--shared-mem-progress=<shmem_id> | ID of shared memory segment |
--create-shared-mem | MDS create own shared memory segment |
--status=<filepath> | Filepath with status for control task |
--avdb=<filepath> | Filepath with ai-bolit signatures database |
--procudb=<filepath> | Filepath with procu signatures database |
--state-file=<filepath> | Filepath with info about state (content: new /working /done /canceled ). You can change it on canceled . |
--restore=<filepath> | Filepath to restore CSV file |
-h, --help | Display this help and exit |
-v, --version | Show version |
# /opt/ai-bolit/wrapper /opt/ai-bolit/imunify_dbscan.php --port=3306 --login=user --password-from-stdin --database=$DATABASE --avdb=/var/imunify360/files/sigs/v1/aibolit/mds-ai-bolit-hoster.db --report-file=`pwd`/report.json --scan
Scan results will be stored in the report.json
.
# /opt/ai-bolit/wrapper /opt/ai-bolit/imunify_dbscan.php --port=3306 --login=user --password-from-stdin --database=$DATABASE --avdb=/var/imunify360/files/sigs/v1/aibolit/mds-ai-bolit-hoster.db --procudb=/var/imunify360/files/sigs/v1/aibolit/mds-procu2.db --report-file=`pwd`/report.json --clean
Cleanup results will be stored in the results.json
. Also, backup of the affected data will be created with a filename similar to the mds_backup_1597223818.csv
.
# /opt/ai-bolit/wrapper /opt/ai-bolit/imunify_dbscan.php --port=3306 --login=user --password-from-stdin --database=$DATABASE --report-file=$REPORT --restore=`pwd`/mds_backup_1597223818.csv
Warning
When the interface IP address is added to or deleted from the system, the restart of the webshield is required for the latter to recognize the new IP.
service imunify360-webshield restart
The CAPTCHA is a feature intended to distinguish human from machine input and protect websites from the spam and different types of automated abuse. Imunify360 uses reCAPTCHA service.
Warning
Please note that the WebShield Captcha is not compatible with aggressive CDN caching modes, like Cloudflare 'cache everything' with 'Edge Cache TTL'. If the Сaptcha page is cached by CDN, a visitor will see the Captcha from CDN cache disregarding it has been passed or not. In order to fix that, either disable the aggressive CDN caching or the Captcha functionality in the Imunify360.
There are two layers in CAPTCHA behavior:
Note
The IP address on the screenshot above is given as an example.
If successful, a user is redirected to the website, which means that the access is unblocked and the IP address of this user is removed from the Grey List.
It is also possible to enable the invisible reCAPTCHA via the Imunify360 Settings page. With the invisible reCAPTCHA enabled, a human user is not required to go through human confirmation - the process will pass under the hood and a user will be redirected to the website. In case if invisible reCAPTCHA failed to detect if a user is a human or not, then visible reCAPTCHA appears.
The reCaptcha supports localization. Depending on user’s browser settings, reCaptcha will use the browser default language and allow to change it:
To modify footer, header or body of the CAPTCHA use the templates in /usr/share/imunify360-webshield/captcha/templates/
.
There are three files:
head.tpl
– this file goes inside <head></head>
tags. So you can add JavaScript, CSS styles, etc.
body.tpl
– the main template file, modify it as you wish. CAPTCHA goes above all the layers.
static
– here you can place images, CSS, JavaScript, etc. and access these files as /static/<filename>
.
To find information on supported browsers follow this link https://support.google.com/recaptcha/answer/6223828.
A user can change the text of captcha messages for the supported languages. Note that adding custom language is not supported.
To change the text of the Imunify360 Captcha and update the localizations text, please do the following:
Locate appropriate Captcha localization files by running:
ls /usr/share/imunify360-webshield/captcha/translations/locale/{lang}/LC_MESSAGES/messages.po
For example for Polish language the catalog looks like this:
/usr/share/imunify360-webshield/captcha/translations/locale/pl/LC_MESSAGES/messages.po
Update Captcha localization files by editing msgstr "my customization or translation"
for appropriate msgid “original plain english text"
.
Where msgstr
contains text that is shown to user and msgid
contains Captcha original English text.
For example:
#: templates/index.html:154
msgid ""
"We have noticed an unusual activity from your <b>IP {client_ip}</b> and "
"blocked access to this website."
msgstr ""
"Zauważyliśmy nietypową aktywność związaną z twoim adresem <b>IP "
"{client_ip}</b> i zablokowaliśmy dostęp do tej strony internetowej"
To add Polish translation edit text in the msgstr
field. To change the text for a default English translation, edit text in the msgid
field.
Save files.
When translation in messages.po
files is finished, restart imunify360-webshield service:
service imunify360-webshield restart
If a server owner has his own Google reCAPTCHA keys (both private and public), he may use them instead of the default CloudLinux keys.
To set Google reCAPTCHA keys, place your keys into the /etc/imunify360-webshield/webshield-http.conf.d/captchakeys.conf
file as shown in the example below:
captcha_site_key <YOUR_SITE_KEY>;
captcha_secret_key <YOUR_SECRET_KEY>;
Then reload WebShield.
See how to setup invisible CAPTCHA.
Imunify360 admin should specify reCAPTCHA keys for the server since we’re planning to completely remove embedded reCAPTCHA keys in the future versions.
In this article, you can find a step by step guide on how to set up a custom site and secret keys for your Imunify360 server.
Public and secret reCAPTCHA keys are required for integration between Imunify360 and Google reCAPTCHA service.
The site key will be publicly available and shown on pages along with reCAPTCHA widget or Invisible CAPTCHA, whereas the secret key will be stored for intercommunication between the backend of Imunify360 and Google service.
Note: Due to the captcha rate limit we recommend using different reCAPTCHA keys for each server.
Google’s quotation: If you wish to make more than 1k calls per second or 1m calls per month, you must use reCAPTCHA Enterprise or fill out this form and wait for an exception approval.
Fill in required values
Note
You don’t need to put all your domains here
Accept terms and proceed
Notice keys
You need to put these keys on the Imunify360 settings page
or use the following CLI commands:
# imunify360-agent config update '{"WEBSHIELD": {"captcha_site_key": "6Ldu4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXCN6fJ"}}'
# imunify360-agent config update '{"WEBSHIELD": {"captcha_secret_key": "6Ldu4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXQqUuk"}}'
The final step is to allow Google to process requests from any of your domains
Open the Settings page
And disable the Verify the origin of reCAPTCHA solutions
That’s it.
In order to make sure that you’ve done everything correctly you need to do the following:
Make sure that your IP is not whitelisted (using the CLI):
# imunify360-agent whitelist ip list
IP TTL COUNTRY IMPORTED_FROM COMMENT
1.2.3.4 10256 None None Whitelisted for 3 hours due to successful panel login
# imunify360-agent whitelist ip delete 1.2.3.4
OK
# imunify360-agent whitelist ip list
IP TTL COUNTRY IMPORTED_FROM COMMENT
Make sure your target domain is not whitelisted:
# imunify360-agent whitelist domain list
example.com
# imunify360-agent whitelist domain delete example.com
OK
Send at least two WAF test requests to any domain on the server
# curl -v http://example.org/?i360test=88ff0adf94a190b9d1311c8b50fe2891c85af732
Open your test domain in the browser and let it pass the captcha challenge
Check the list of whitelisted IPs again
# imunify360-agent whitelist ip list
IP TTL COUNTRY IMPORTED_FROM COMMENT
1.2.3.4 86377 None None IP auto-whitelisted with expiration date: 2020-05-28 15:29:34
If you see that your IP is whitelisted then integration between Imunify360 and reCAPTCHA service was done properly.
You can watch how invisible reCAPTCHA works at https://www.youtube.com/watch?v=GQXmAj5hyDo.
Note
It is also possible to test Captcha by the server IP. Find more information here
Imunify360 correctly graylists and blocks IPs behind Cloudflare and other CDNs (see here for the full list).
Imunify360 passes all requests from CDN through WebShield, and uses CF-Connecting-IP and X-Forwarded-For headers to identify real IPs.
To enable it now, run the command:
imunify360-agent config update '{"WEBSHIELD": {"known_proxies_support": true}}'
Note
If you are using cPanel/EasyApache3, Imunify360 will not automatically deploy mod_remoteip, and log files will show local server IP for visitors coming from CDN. EasyApache 3 is EOL since December 2018, and we don't plan to add automated mod_remoteip setup and configuration for it.
Note
For cPanel/EasyApache 4, Plesk, DirectAdmin and LiteSpeed mod_remoteip will be automatically installed and configured.
The “trust_ezoic” option for WebShield allows you to trust all IPs that are specified by Ezoic CDN as their own servers. By default the option is switched off, but it can be switched on in a straightforward way. Be aware when using this option, at this moment the list of Ezoic CDN servers is quite big and includes ranges that can be controlled by someone else in Amazon EC2.
To enable it, open the /etc/imunify360-webshield/virtserver.conf
file, 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
Imunify360 Captcha isn't available in some countries due to certain restrictions, for example, in China. To alleviate this, Chinese customers can use Imunify360 SplashScreen as Captcha.
To enable SplashScreen, open the file /etc/imunify360-webshield/wscheck.conf
, find the following line:
wscheck_splashscreen_as_captcha off;
Change off
to on
:
wscheck_splashscreen_as_captcha on;
Save the file and run the following command:
For Ubuntu:
service imunify360-websheld reload
For CentOS:
systemctl reload imunify360-webshield
The graylisted visitors will see such screen for 5 seconds before redirecting to their initial destination.
Note
You can find WebShield and Captcha related logs in the /var/log/imunify360-webshield/
file.
Country blocking is available in both Admin UI and CLI
Starting from version 5.6, Imunify360 distinguishes bots from real visitors using the JavaScript challenge "Splash Screen." Most bots don’t solve the challenge, and their requests will not reach web applications such as WordPress, Drupal, and others. This can save the server’s resources and protects websites from scanners, automated attacks, and web-spammers.
Only bad actors will be redirected to the Imunify360 Splash Screen challenge page. Legitimate visitors get original content without any verification page nor any delay. The users forced to the Splash Screen will not see the challenge or CAPTCHA and be redirected to the page with the original content. Cookies and JavaScript support are required in a browser to successfully pass the challenge of Anti-bot protection.
The “Anti-bot protection” feature will not block legitimate bots (e.g., Google crawler).
You can enable Anti-bot protection, in the UI. Go to the General tab -> Settings and check the Anti-bot protection checkbox. You can find the details here.
Or via CLI. To do so, run the following command:
# imunify360-agent config update '{"WEBSHIELD": {"splash_screen": true}}'
Starting from Imunify360 v.5.8, we introduce the overridable config which provides the ability to provision default config for the whole fleet of Imunify servers and keep the ability for fine-tuning each particular server depending on its requirements.
Configs organization:
/etc/sysconfig/imunify360/imunify360.config.d/
/etc/sysconfig/imunify360/imunify360.config
is now linked to the imunify360.config.d/90-local.config
. It contains changes made through UI as well as through CLI.imunify360.config.defaults.example
. Modifying this config won't affect config merging behavior in any way, so please refrain from changing it.imunify360.config.defaults.example
and each other in lexical order. First-level "sections" (such as FIREWALL
) are merged, while second-level "options" (such as FIREWALL.TCP_IN_IPv4
) are replaced completely.imunify360.config.d/10_on_first_install.config
is a config that is supplied by Imunify360. Its purpose is to let us - Imunify360 developers - enable new features only on new installations without forcing existing installation to see new feature enabled on the update. This config should not be modified manually.This way you can keep your local customizations, and still be able to rollout your main config.
The following CLI command can be used to check current server configuration:
imunify360-agent config show
Current server configuration is also present at /etc/sysconfig/imunify360/imunify360-merged.config
path.
The following CLI command:
imunify360-agent config show defaults
can be used to check server configuration in the following states:
mutable_config
represents config state before applying imunify360.config.d/90-local.config
,local_config
represents parsed imunify360.config.d/90-local.config
config,immutable_config
represents merged configs which come after imunify360.config.d/90-local.config
in lexical order.Here is an example of custom server configuration:
imunify360.config.defaults.example Provided by Imunify installation. Contains default recommended configuration | FIREWALL: TCP_IN_IPv4: - '20' - '8880' port_blocking_mode: ALLOW |
imunify360.config.d/50-common.config Provisioned by server owner to the fleet of servers. | FIREWALL: TCP_IN_IPv4: - '20' - '21' port_blocking_mode: DENY |
imunify360.config.d/90-local.config Contains local customization per server individually. | FIREWALL: TCP_IN_IPv4: - '20' - '22' - '12345' |
The resulting (merged) configuration will look like this:
FIREWALL:
TCP_IN_IPv4:
- '20'
- '22'
- '12345'
port_blocking_mode: DENY
The mechanics is as follows: first-level "sections" - for example FIREWALL
are merged, while second-level "options" - for example FIREWALL.TCP_IN_IPv4
are replaced completely.
Those who don’t need this type of overridable configs can continue using custom configurations in the /etc/sysconfig/imunify360/imunify360.config
.
This feature is backward compatible.
On the web server, the user’s Crontab files are notoriously tricky to maintain secure because of specific format and various placement of the files outside of users’ home directories depending on specific OS and platform, which makes them a compelling target for malicious actors.
This feature detects any Crontab infection among the files that are owned by users of the server for every role that has access to run the scans on that server.
The feature is available as experimental starting from Imunify360 version 6.10 and switched off by default.
The setting MALWARE_SCANNING.crontabs
allows you to enable or disable scan of the system and user crontab files for malicious jobs.
Manage it through CLI:
To switch it on:
# imunify360-agent config update '{"MALWARE_SCANNING": {"crontabs": true}}'
And to switch it off:
# imunify360-agent config update '{"MALWARE_SCANNING": {"crontabs": false}}'
You can use a new notification system via CLI and UI.
Hooks are introduced as a script-based interface for various application events. This is a simple and effective way to automate Imunify360 alerts and event processing. For example, an administrator can have Imunify360 calling his own script when malicious files are detected or misconfigurations are detected and perform a custom processing or specific actions, for example, create a ticket. Hooks are available only via CLI.
Start using hooks with three simple steps:
Create a script to handle an event (a hook handler):
Register your hook handler in Imunify360 agent - use registration command:
imunify360-agent hook add --event <event name> --path </path/to/hook_script>
started - the event is generated each time the Imunify agent is started/restarted
{"version": "4.6.2-2"}
misconfig - the event is generated when the agent detects agent misconfiguration / broken settings / etc.
{
"error": "ValidationError({'SMTP_BLOCKING': [{'allow_groups': ['must be of list type']}]},)"
}
subtype ( started | finished )
started - the event is generated when the malware scanning process is started (for on-demand and background scans only, yet not the ftp / waf / inotify)
{
"scan_id": "dc3c6061c572410a83be19d153809df1",
"home": "/home/a/abdhf/",
"user": "abdhf",
"type": "background",
"scan_params": {
"file_patterns": "*",
"exclude_patterns": null,
"follow_symlinks": true,
"intensity_cpu": 2
"intensity_io": 2
"intensity_ram": 2048
}
}
finished - the event is generated when the malware scanning process is finished (for on-demand and background scans only, yet not the ftp / waf / inotify)
{
"scan_id": "dc3c6061c572410a83be19d153809df1",
"path": "/home/a/abdhf/",
"started": 1587365282,
"scan_type": "background",
"total_files": 873535,
"total_malicious": 345,
"error": null,
"status": "ok",
"users": ["abdhf"],
"scan_params": {
"file_patterns": "*",
"exclude_patterns": null,
"follow_symlinks": true,
"intensity_cpu": 2
"intensity_io": 2
"intensity_ram": 2048
}
}
critical
imunify360-agent malware malicious list --by-scan-id=... --json
{
"scan_id": "dc3c6061c572410a83be19d153809df1",
"scan_type": "on-demand",
"path": "/home/a/abdhf/",
"users": [
"imunify",
"u1"
],
"started": 1587365282,
"total_files": 873535,
"total_malicious": 345,
"error": null,
"tmp_filename": "/var/imunify360/tmp/malware_detected_critical_sldkf2j.json"
}
[
{
"scan_id": "dc3c6061c572410a83be19d153809df1",
"username": "imunify",
"hash": "17c1dd3659578126a32701bb5eaccecc2a6d8307d8e392f5381b7273bfb8a89d",
"size": "182",
"cleaned_at": 1553762878.6882641,
"extra_data": {
},
"malicious": true,
"id": 32,
"status": "cleanup_removed",
"file": "/home/imunify/public_html/01102018_2.php",
"type": "SMW-INJ-04174-bkdr",
"scan_type": "on-demand",
"created": 1553002672
},
{
"scan_id": "dc3c6061c572410a83be19d153809df1",
"username": "imunify",
"hash": "04425f71ae6c3cd04f8a7f156aee57096dd658ce6321c92619a07e122d33bd32",
"size": "12523",
"cleaned_at": 1553762878.6882641,
"extra_data": {
},
"malicious": true,
"id": 33,
"status": "cleanup_done",
"file": "/home/imunify/public_html/22.js",
"type": "SMW-INJ-04346-js.inj",
"scan_type": "on-demand",
"created": 1553002672
},
...
]
Note
All results can be saved in a temporary file before handler invocation and then remove the file after the event is being processed
subtype ( started | finished )
started - the event is generated when the malware cleanup process is started (for on-demand and background cleanup only, background auto-cleanup will be implemented later)
imunify360-agent malware malicious list --by-scan-id=... --json
. See malware-detected hook section for details.{
"cleanup_id": "dc3c6061c572410a83be19d153809df1",
"started": 1587365282,
"total_files": 873535,
"tmp_filename": "/var/imunify/tmp/hooks/tmp_02q648234692834698456728439587245.json",
}
finished - the event is generated when the malware scanning process is finished (for on-demand and background cleanup only, background auto-cleanup will be implemented later)
{
"cleanup_id": "dc3c6061c572410a83be19d153809df1",
"started": 1587365282,
"total_files": 873535,
"total_cleaned": 872835,
"tmp_filename": "/var/imunify/tmp/malware_cleanup_finished_slkj2f.json",
"error": null,
"status": "ok"
}
subtype ( expiring | expired | renewed )
params[]
{"exp_time": 1587365282}
params[]
{"exp_time": 1587365282}
params[]
{
"exp_time": 1587365282,
"license": "imunify360"
}
The following CLI command is used to manage hooks:
imunify360-agent hook [command] --event [event_name|all] [--path </path/to/hook_script>]
The following commands are supported:
The third parameter event_name defines a particular event that invokes a registered handler as opposed to all keyword.
The fourth parameter /path/to/hook_script
shall contain a valid path to a handler of the event, it shall be any executable or Python Native event handlers that agent will run upon a registered event.
Native hook is a script written on Python 3.5 and allows to quickly process events. The Python file should contain only one method that customer would implement:
def im_hook(dict_param):
…
pass
where dict_param
would hold the same data as JSON that non-Native hook would get.
You can see all hook data in the log file. It is located at /var/log/imunify360/hook.log . When the event comes, the data is recorded to the log file in the following format:
timestamp event : id : started [native:] name : subtype : script_path
Once the listener is done, the data is recorded to the log file in the following format:
timestamp event : id : done [native:] script_path [OK|ERROR:code]
In case of an error, you can see the error code you have specified.
Regular (non-native) hook:
#!/bin/bash
data=$(cat)
event=$(jq -r '.event' <<< ${data})
subtype=$(jq -r '.subtype' <<< ${data})
case ${event} in
malware-scanning)
case ${subtype} in
started)
# do stuff here
;;
*)
echo "Unhandled subtype: ${subtype}" 1>&2
exit 1
esac
;;
*)
echo "Unhandled event: ${event}/${subtype}" 1>&2
exit 2
esac
Native hook:
def im_hook(dict_param):
event = dict_param['event']
subtype = dict_param['subtype']
if event == 'malware-scanning':
if subtype == 'started':
# do stuff here
pass
elif subtype == 'finished':
# do other stuff here
pass
else:
raise Exception('Unhandled subtype {}'.format(subtype))
else:
raise Exception('Unhandled event {}'.format(event))