Security and isolation
SHM security is a set of cooperating boundaries: role and ownership checks, account isolation, resource limits, authentication policy, network filtering, web request protection, malware scanning, audit history, and recoverable backups.
Where to find it: Documentation > Hosting Manager > Security and isolation.
Available to: Anyone reading the public documentation. The related SHM action still follows the role stated on its page.
What this page does
Use this guide to choose the right protection layer. A firewall controls network exposure, HTTP Guard and ModSecurity inspect web traffic, Antivirus examines files, account policy limits identity and access, and Audit records security-sensitive changes. None of them replaces all the others.
Before you start
Start from evidence and change the narrowest layer that owns the problem. Disabling a global control to fix one request is usually an expensive way to avoid writing one precise exception.
Protection layers
| Layer | Protects | Does not replace |
|---|---|---|
| Roles, ownership, and feature profiles | Which server, reseller, and account resources an identity may use. | Operating-system isolation or network filtering. |
| Shell and resource policy | Account command access and CPU, memory, process, inode, disk, and I/O consumption. | Application security. |
| Firewall and LFD | Network ports, addresses, login-failure response, and connection policy. | Per-request application analysis. |
| HTTP Guard | Bounded request filtering and smart protection for enabled domains. | A network firewall or a full application correctness review. |
| ModSecurity | Rule-based web application firewall behavior and OWASP CRS policy. | Malware scanning of stored files. |
| Antivirus | Account or server file scanning, findings, quarantine, and reviewed suppression. | A guarantee that a vulnerable application is safe. |
| Audit and logs | Who changed what and the evidence around an incident. | Prevention by themselves. |
| Backups | Recovery from deletion, corruption, or a failed change. | Prevention or incident investigation. |
Account boundary
Account pages and API routes resolve an authorized username and then constrain files, domains, databases, mail, applications, logs, backups, and runtime actions to that account. Root can cross account boundaries because the role owns the server; resellers remain limited to delegated accounts; account users remain limited to themselves.
Safe exceptions
When legitimate traffic or a file is blocked, preserve the rule, request, finding, path, hash, time, and account first. Prefer monitor mode, one domain, one rule, one exact address, or one reviewed file identity over a global disable. Verify that the exception fixes the customer request without opening unrelated traffic.
How to use it
- Identify whether the incident is identity, resource, network, HTTP, application-rule, file, or recovery related.
- Collect evidence from Audit, Logs, Diagnostics, delivery reports, scan results, or service status.
- Change the narrowest owning control.
- Test both the legitimate customer workflow and the blocked or malicious case.
- Record the reason and remove temporary exceptions when they are no longer needed.
Result and next check
The intended service continues to work, the unwanted behavior is blocked or contained, and Audit or the relevant module records enough context for later review. A security toggle that is green but untested is a setting, not proof.
Theme color