Shared hosting monitoring, without root: what you get

What you get

What you install

The agent, with the same command as on a VPS, run from the account terminal, without root. It adds itself to the account crontab and finds the webroot by itself.

What it sees inside

The sha256 fingerprints of the webroot files (up to 40,000), malware patterns in new or changed files, the account access logs, the crontab, the file count and the quota.

What it sees from outside

Ten checks on the site’s domain: availability every minute, DNS, TLS certificate, blocklists, scripts and defacement, exposed files, domain expiry, headers, SPF/DMARC and TLS quality.

What alerts you

Malware in the site, attack campaigns in the access logs, a site down, a DNS change, a certificate close to expiry, a listed IP, defacement, exposed files, a domain close to expiry, a silent agent.

What it can fix

One, only with your approval: move infected files to quarantine, outside the webroot, and put them back with one click. Configuration files (wp-config.php, .htaccess) are refused.

What it cannot see

Processes, ports, SSH logins, CPU and memory. They belong to the server, not to the account, and reporting them as yours would be disinformation, not data. No port scan either: every account leaves through the same server.

What you see in the dashboard

The host page has the Overview, Availability, Resources, Security, Files, Inventory, Checks, Activity and Agent tabs: the quota, web traffic, the files with their quarantine, the outside checks and the agent’s state.

How it counts against your plan

One host from your plan, with the outside checks on its domain. Another domain in the same account is added separately, as an external site.

The full list, row by row

Each row says how often it looks, what it compares and what it does: alerts you, shows only on the host page, or is a remediation you approve.

from inside the account

• sha256 fingerprints of the webroot files (every 5 min) [on the host page]: We compare fingerprint against fingerprint, not the modified date, which can be forged. Only files whose size, inode or change time (ctime) differ are re-read: the owner of a file cannot set that one back. On a site nobody touched, a run reads no files at all. Up to 40,000 files per account, inventoried in instalments of at most 2,000 per run; past that cap the dashboard says plainly that the inventory is truncated. Besides PHP, HTML and JS, it watches .htaccess, .user.ini, php.ini, the rarer extensions (.php3 to .php8, .phps, .pht, .phar, .shtml) and double extensions (x.php.jpg). A new, changed or deleted file shows on the host page, without an alert.
• Injection patterns inside the files (every 5 min) [alerts you]: Webshells, obfuscated eval, uploaders, PHP under uploads and risky lines in .htaccess or .user.ini, searched in the first and last 64 KB of the files that are being re-read anyway, so the cost is near zero. A certain pattern opens a critical incident. The file never leaves the server: you get the matched fragment (at most 40 characters) and the line number.
• The account access logs (every 5 min) [alerts you]: The account access logs (domlogs), summarized per source: how many different paths it tries, how many errors it gets, scanning tools and POST requests to the root. A sustained campaign opens an incident.
• The account crontab (every 5 min) [on the host page]: Any job added or removed, with the whole command. It is one of the forms of persistence within reach of an account without root; the others (.htaccess, prepend files, scripts left in the site) are covered by the file inventory.
• Your sites’ PHP, against PHP2Shell (every 5 min) [alerts you]: The PHP version the account’s sites run (MultiPHP, PHP Selector) and its package: whether it is affected by PHP2Shell (CVE-2026-109618, CVE-2026-109619) or the provider already shipped the fix. The inventory is refreshed every 6 hours; an affected version in use opens an incident.
• One-click cleanup, with your approval (on request) [with your approval]: You tick the infected files and quarantine them in one click, which proposes the batch rather than running it: every move is approved in the dashboard, with all paths visible. Files move outside the webroot, so they are no longer reachable from the web, but they stay as evidence and go back with one click too. We never rewrite a file’s contents. wp-config.php, .htaccess, configuration.php and settings.php are refused: if one of them is infected, the fix is to edit it, not remove it, otherwise an infection becomes a total outage.

from outside

• HTTP availability (every 1 min) [alerts you]: Code, response time and redirects, from a server unrelated to yours. An apex pointing at another domain stays a warning, not green. A failure is confirmed by a second probe 15 seconds later, before alerting.
• DNS records and delegation (every hour) [alerts you]: A, NS and MX against the baseline. We query public resolvers, not the server’s own, so a local outage cannot read as a vanished domain. A change of A or NS is a critical incident.
• TLS certificate (every 6 h) [alerts you]: Issuer, chain and days left. Warning at 21 days, critical at 7, so the renewal does not land on a weekend. A change of certificate authority is reported separately.
• Blocklists (every 6 h) [alerts you]: Spamhaus ZEN, SpamCop and Barracuda: three lists that genuinely affect mail delivery. A listed IP is a critical incident; a list that does not answer means “unknown”, not “clean”.
• Third-party scripts, cookies and defacement (every 6 h) [alerts you]: What loads from outside, which cookies are written without protection and how the page structure changes. A new script shows on the host page; signs of defacement (a “hacked by” message, spam words in the title, obfuscated JavaScript) open a critical incident.
• Exposed sensitive files (every 12 h) [alerts you]: .git, .env, backups, dumps and phpinfo. A control probe with a random name first establishes what “not found” looks like, so a site that redirects everything does not read as full of exposed files.
• Domain registration expiry (every 12 h) [alerts you]: Through RDAP, with whois as a fallback. Warning at 30 days, critical at 7. For .ro the registry publishes no date, so we watch the domain status: on hold or expired is critical.
• Security headers (every 6 h) [on the host page]: HSTS, X-Content-Type-Options, X-Frame-Options, CSP and Referrer-Policy, measured on the final page, not on the redirect. What is missing shows on the host page and in the score, without an alert.
• SPF, DMARC, DKIM, CAA, DNSSEC (every 12 h) [on the host page]: Syntax, duplicates and over-permissive policies, including two SPF records where the standard allows exactly one. It shows on the host page, without an alert; the exceptions are DNSSEC switched off on a zone that was signed and a new issuer added to CAA, which open an incident.
• TLS quality: protocols and ciphers (every 12 h) [on the host page]: Outdated versions still accepted, weak ciphers and RSA keys under 2048 bits, tested with a real handshake rather than inferred from a banner. It shows on the host page, without an alert.

from our side

• Silent agent: a critical incident (always on) [alerts you]: If three reports in a row do not arrive, either the account was suspended or the agent was removed from cron. Both are worth knowing.
• A collector that can no longer read (every 5 min) [alerts you]: A moved webroot or an access log that can no longer be read: the affected collector is named, with the reason, not treated as quiet.

across nine real accounts, in a single comparison: 1508 files appeared, 509 removed, 107 changed against the earlier fingerprints

How to start

1. In the dashboard pick “Add a host”, type “Shared hosting”, with the site’s domain.
2. Run the install command from the account terminal (SSH or Terminal in cPanel), without root.
3. The installer adds a line to the account crontab and finds the webroot by itself (public_html, www, htdocs).
4. The first sweep inventories the files in instalments; until it finishes, nothing shows up as a “new file”.

Questions about this host type

Does it work on any hosting?

On any account where you can run a command and have a crontab. The agent looks for the webroot in public_html, www, htdocs, httpdocs and domains/*/public_html; otherwise you tell it at enrollment. It reads the access logs from the places cPanel uses; on other panels the traffic view may stay empty, and the host page says why.

What can it not see on shared hosting?

Processes, ports, SSH logins, CPU and memory: they belong to the server, not to the account. For those you need the server itself, as a VPS with agent.

What happens when an infected file appears?

A certain pattern opens a critical incident, with the file, the line and the matched fragment. In the dashboard you tick the files and move them to quarantine once you approve; the file stays as evidence and goes back with one click. Its contents are never rewritten.

I have several sites in one account. How are they counted?

The agent watches the files of every webroot found in the account (up to 30). The outside checks run on the host’s domain; another domain is added as an external site, which uses one more host from your plan.

The other host types

VPS with agent · External site · cPanel/WHM reseller