sidebar hamburger menu

User Interface

There are following tabs in the Imunify360 end user interface:

Files

Go to Imunify360 → Malicious tab. Here, there is a table with a list of infected files.

The table has the following columns:

  • Detected — displays the exact time when a file was detected as malicious
  • File — the path where the file is located starting with root
  • Reason — describes the signature which was detected during the scanning process. Names in this column depend on the signature vendor. You can derive some information from the signature ID itself. SMW-SA-05155-wshll – in this Signature ID:
    • The first section can be either SMW or CMW. SMW stands for Server Malware and CMW stands for Client Malware
    • The second section of ID can be either INJ or SA. INJ stands for Injection (means Malware is Injected to some legitimate file) and SA stands for StandAlone (means File is Completely Malicious)
    • The third section is 05155. This is simply an identification number for the signature.
    • The fourth section wshll/mlw.wp/etc explains the category and class of malware identified. Here, wshll stands for web shell (mlw stands for malware).
    • The fifth section is 0, which provides the version number of the signature.
  • Status — displays the file status:
    • Infected — threat was detected after scanning. If a file was not cleaned after cleanup, the info icon is displayed. Hover mouse over info icon to display the reason
    • Cleaned — infected file is cleaned up
    • Content removed — a file content was removed after cleanup
    • Cleanup queued — infected file is queued for cleanup. Actions:
  • Add to Ignore List — add file to Ignore List and remove it from the Malicious files list. Note that if a file is added to Ignore List, Imunify360 will no longer scan this file
  • View file — click eye icon in the file line and the file content will be displayed in the popup. Only the first 100Kb of the file content will be shown in case if a file has bigger size
  • Cleanup — click to cleanup the file.
  • Delete — remove the file from the server and from the list of Malicious files.
  • Restore original — click Restore original to restore original file after cleaning up if backup is available.

To perform a bulk action, tick required users and click the corresponding button above the table.

The following filters are available:

  • Timeframe — displays the results filtered by chosen period or date.
  • Status — displays the results filtered by chosen status.
  • Items per page displayed — click the number at the table bottom.

The table can be sorted by detection date (Detected), file path (File), Reason, and Status.

If a user is allowed by an administrator to scan his files, he can see the Start scanning button.

History

History tab contains data of all actions for all files. Go to Imunify360 → History tab. Here, there is a table with a list of files.

The table has the following columns:

  • Date — action timestamp.
  • Path to File — path to the file starting from the root.
  • Cause — displays the way malicious file was found:
    • Manual — scanning or cleaning was manually processed by a user.
    • On-demand — scanning or cleaning was initiated/made by a user;
    • Real time — scanning or cleaning was automatically processed by the system.
  • Owner — displays a user name of file owner.
  • Initiator — displays the name of a user who was initiated the action. For system actions the name is System.
  • Event — displays the action with the file:
    • Detected as malicious — after scanning the file was detected as infected;
    • Cleaned — the file is cleaned up.
    • Failed to clean up — there was a problem during cleanup. Hover mouse over the info icon to read more.
    • Added to Ignore List — the file was added to Ignore List. Imunify360 will not scan it.
    • Restored original — file content was restored as not malicious.
    • Cleanup removed content — file contend was removed after cleanup.
    • Deleted from Ignore List — the file was removed from Ignore List. Imunify360 will scan it.
    • Deleted — the file was deleted.
    • Submitted for analysis — the file was submitted to Imunify team for analysis.
    • Failed to delete — there was a problem during removal. Hover mouse over the info icon to read more.
    • Failed to ignore — there was a problem during adding to Ignore List. Hover mouse over the info icon to read more.
    • Failed to delete from ignore — there was a problem during removal from Ignore List. Hover mouse over the info icon to read more.

The table can be sorted by Date, Path to File, Cause, and Owner.

Ignore List

Ignore List tab contains the list of files and directories that are excluded from Malware Scanner scanning. Go to Imunify360 → Ignore List tab. Here, there is a table with a list of files.

The table has the following columns:

  • Added — the date when the file was added to Ignore List.
  • Path — path to the file starting from the root.
  • Actions:
    • Remove from Ignore List — click Bin icon to remove the file from the Ignore List and start scanning.
    • Add new file or directory — click Plus icon to add a new file or directory to Ignore List. To perform a bulk action, tick required files and click the corresponding button above the table.

The following filters are available:

  • Timeframe — displays the results filtered by chosen period or date.
  • Items per page displayed — click the number at the table bottom.

The table can be sorted by Added and Path. By default, it is sorted from newest to oldest.

Note

The end-user malware ignore list is disabled by default. Only Imunify360 administrators can enable it:

imunify360-agent config update '{"PERMISSIONS": {"user_ignore_list": true}}'

For disabling:

imunify360-agent config update '{"PERMISSIONS": {"user_ignore_list": false}}'

WebShield

The WebShield tab holds the WebShield protection features you can manage for your own domains. Currently it contains one such feature, Under Attack Mode.

Under Attack Mode

Under Attack Mode (UAM) lets you put your own domains "under attack": while a domain is under attack, every visitor first gets a JavaScript splash page and only reaches the site after their browser solves it. Regular browsers solve it transparently and are then trusted for the lifetime of the clearance cookie; simple bots never get through.

Turn it on for a domain when it is the target of an automated flood — a scripted login or checkout abuse, for example — and turn it off once the flood is over.

Note

This tab appears only if Under Attack Mode is supported by the server, the server administrator has enabled it, and they have allowed end users to manage their own rules. If you do not see the tab, or you see a notice saying that the service is disabled, ask your hosting provider.

You only see and manage the rules you created, for the domains of your own account. Rules created by the server administrator are not shown here, but they still apply to your domains.

Adding a rule

Click ADD and fill in the form.

FieldDescription
DomainThe domain to put under attack. Pick one of your domains from the list, or enter its wildcard — *.example.com covers the subdomains only, .example.com covers the domain and its subdomains.
Clearance cookie lifetimeHow long a visitor is trusted after solving the splash page, before being asked again. The default is 1h; a shorter lifetime is stricter, a longer one is more comfortable for real visitors.
LabelAn optional note to remind you why the rule exists.
PathsEntire domain challenges every request. Only the listed paths challenges just the URLs you list — useful when only the login or the checkout page is being hit. All paths except the listed ones challenges everything else, which is a way to keep an API or a webhook endpoint reachable.

The path conditions and the way they treat query strings are described in Scoping a rule to paths.

Checking and managing rules

  • Test URL against the rules tells you whether a given URL would be challenged, without waiting for real traffic.
  • Hits for shows how many challenges the rule has served over the selected period, so you can see whether it is doing any work.
  • The Active switch pauses a rule and resumes it later — better than deleting a rule you will need again during the next flood.
  • Edit changes the cookie lifetime, the label and the paths of an existing rule. The domain cannot be changed; create a new rule instead.
  • Remove deletes the rule.

Legitimate automation needs to be whitelisted

Anything that cannot run JavaScript is stopped while the rule is active — including your own integrations, monitoring and cron jobs that call the site over HTTP. Ask your hosting provider to whitelist the IP addresses they come from; whitelisted IP addresses are not challenged.

For the technical details of how the challenge is enforced, see Under Attack Mode (UAM).

×
Need help?
I'm a multilingual AI chatbot, trained to answer all your questions!