All manual sections

DocumentationReal-time protection

Real-time protection

Real-time protection checks the files of the sites as they are written: a vulnerable plugin used to upload a web shell, a file changed over SFTP, a tampered .htaccess. There is no need to wait for the nightly scan: the file is examined a few seconds later, and if it is certain malware it is quarantined straight away.

The state is shown at the top of the Antimalware page ("Real-time protection: on") and on the antimalware page of every site.

What is checked

Every PHP, JavaScript, HTML, SVG, .htaccess and .user.ini file written inside a site folder, and images too (for hidden PHP code). The check starts once the file has been closed after writing, or moved into place (as PHP does with uploaded files), after a short wait for the writes to settle.

The file goes through the same engines as the scans:

  • the heuristic rules of the built-in scanner;
  • ClamAV, when it runs as a service ("daemon" mode, on servers with at least 4 GB of RAM): the content is handed to it over its local socket. On smaller servers the heuristic rules remain; ClamAV works in the scheduled scans.

The quarantine, the logs folder, the WordPress caches and the session files are not checked.

During a migration, the real-time check pauses for the sites the panel is writing: otherwise thousands of copied files would mean thousands of checks and alerts about what was already on the old server. At the end of the import, and of every final sync, the panel starts a scan of those sites. The migration's working folders, outside the sites, are never checked in real time.

What happens when something is found

Administrators choose the policy:

  • Quarantine certain detections automatically, alert for the others (default). "Certain" means a ClamAV signature, the EICAR test file, or several web shell traits together in the same file (for example eval(base64_decode($_POST[...]))). The file is moved to the site's quarantine, where you can restore or delete it as usual. The other findings stay open for you to judge.
  • Alert only: no file is moved.

Either way the site owner and the administrators get an email for critical and high threats (when alerts are on in the antimalware Settings), and the finding appears in the site's list with the "real time" label.

A file restored from the quarantine or marked as a false positive is not quarantined again until it changes.

Since 0.85.0 administrators can also turn on Block PHP files in the uploads at once: a PHP file written in wp-content/uploads goes into the quarantine at once, even with the "alert only" policy. WordPress never puts PHP files there, while it is the favourite place of whoever exploits a vulnerable plugin. The data files and guard pages of plugins (such as those of WPForms or Sucuri) are recognized and left alone. The option is off until you turn it on.

When an update of WordPress or of a plugin writes the official files, the heuristic rules do not flag them: the panel compares them with the originals of wordpress.org, as in the scans.

Recent events

Below the state there is the list of the latest detections: when, which site, which file, what was found and what was done. Every user sees only their own sites. When too many files arrive at once (during a migration, for example) some are skipped and the list says so: the nightly scan picks them up.

Turning it on and off, exclusions

  • The whole server: administrators turn it on or off from the Antimalware page. It is on by default and starts again by itself when the panel restarts.
  • One site: administrators can turn it off for a single site from its antimalware page.
  • Exclusions: whoever manages the site can exclude paths, one per line, relative to the site folder. A folder excludes everything in it; * and ? work too (public_html/cache, *.min.js). Use them for cache folders or libraries that are regenerated often, not to hide findings: that is what "False positive" is for.

Resources

The checks run one at a time at the lowest CPU and disk priority (like nice 19 and ionice idle), so they do not slow the sites down. The queue is capped: beyond the cap, events are skipped rather than piling up.

To watch the files the panel uses fanotify, a Linux kernel mechanism that sees every write on a file system with a single mark, whoever writes (PHP, SFTP, cron). When the kernel does not allow it, it uses inotify, folder by folder; in that case, on servers with a great many files, the system limit may leave some folders out, and the page says so.