Security and SSL

Imunify360: check detections and understand its limits

Reviewed on 3 min read Imunify360 web security

Imunify360 brings together several layers of detection and mitigation. Depending on the configuration applied on each server, it can include:

  • Access analysis and smart blocking, generating black, white and grey lists.
  • Web request analysis using security rules.
  • Analysis of access logs for cPanel, email, FTP, etc. to detect brute-force attempts.
  • Global database of suspicious IPs.
  • Scheduled or on-demand malware scanner.
  • Reputation management for hosted domains.
  • Real-time analysis of PHP process execution and possible malicious code.
  • Additional protection against certain suspicious PHP behaviour.

These layers reduce the risk, but they do not guarantee that an application cannot be compromised, nor do they replace its maintenance.

Options and scans from cPanel

cPanel also includes an Imunify360 interface where you can:

  • See the files the scanner has flagged and their status.
  • Request the clean-up actions enabled for the account.
  • Review the action history.
  • Manage the exclusions allowed by the configuration.

Proactive Defense, analysing processes in real time

Proactive Defense analyses the behaviour of PHP scripts while they run. Its effect depends on the mode configured on the server.

It can be disabled, in log mode (records without blocking) or in kill mode (blocks executions it classifies as malicious). Before blaming a website failure on this layer, check the specific event and script.

An automatic clean-up or a scan with no detections does not by itself prove that a compromised account is safe. In the event of an intrusion, preserve evidence, define the scope, fix the entry point and check files, databases, users, scheduled tasks and credentials. Avoid excluding entire directories: a broad exclusion can hide future malware.

If a website feature fails

Write down the time, URL and action you were performing. Link the failure to a specific event before changing the protection. A 403 or a PHP error can have other causes. If you need us to review it, provide the path and the detection ID, without passwords or public copies of the file.

An exclusion prevents future checks on the excluded scope; it is not the same as declaring a file clean. If a false positive is confirmed, use the narrowest exception that solves the case and review when to remove it. For a confirmed infection, continue with the account clean-up.

You may also find useful

Something wrong or out of date? Tell us and we will review it.