Imunify360 is a security suite for Linux web servers. Its web application firewall (WAF) inspects every HTTP request before it reaches your website and blocks known attack patterns, such as SQL injection, cross-site scripting and WordPress login attacks. How much of it you control depends on where your site runs: on shared hosting it is run for you, and on your own server you set it up yourself.
On Domain India cPanel shared hosting, Imunify360 runs server-wide with the FULL ModSecurity ruleset, application-specific rules and CMS account-compromise prevention switched on, one configuration for every account. You don't install or tune it, and plan level doesn't change it. If the WAF blocks something legitimate, open a ticket with the URL, time and your IP. On your own VPS or server, you install Imunify360 with your own licence and manage the rules yourself, as this guide describes.
1. What the Imunify360 WAF does
Imunify360 combines several layers. The WAF is the one that looks at web requests:
2. On Domain India shared hosting: what is already set
We measured the configuration on our cPanel shared servers on 20 September 2026:
| Setting | Value on our cPanel servers |
|---|---|
| ModSecurity ruleset | FULL (the complete Imunify360 ruleset, not the minimized one) |
| Application-specific rules | On |
| CMS account-compromise prevention | On |
| WordPress WAF protection | On by default |
| Scope | Server-wide, one configuration for every account on the server |
Imunify360 also runs on our DirectAdmin servers. The detailed settings above were measured on cPanel.
The WAF is configured for the whole server, not per plan. A Starter account and a Business account on the same server are protected by the same ruleset.
What this means for you on shared hosting:
- There is nothing to install or switch on. The WAF is already active in front of your site.
- You can't change the server's rules. Server-level settings, such as the ruleset, rule exclusions and ModSecurity configuration files, are managed by Domain India. The WHM steps in older guides are for server administrators and don't apply to a hosting account.
- Don't try to switch rules off in
.htaccess. Directives such asSecRuleEngineorSecRuleRemoveByIdbelong in the server configuration. In.htaccessthey typically cause a 500 error instead of disabling anything.
3. False positives on shared hosting
Sometimes a legitimate request looks like an attack: a page builder saving a large block of HTML, a form post containing code snippets, or an admin action with unusual parameters. The WAF then blocks it, usually with a 403 Forbidden error or a failed save in your CMS.
- Note the details.Write down the full URL, the exact time, what you were doing and the error you saw.
- Find your public IP.Search "what is my IP" from the same connection.
- Open a ticket.Send the URL, time and IP through a new support ticket. Support can look up the matching rule in the server logs and decide whether to add an exclusion for your domain.
- Retest.Repeat the action once support confirms the change.
If your whole connection stops reaching the server, rather than one page failing, you are probably looking at a firewall block after failed logins, not a WAF rule. See have I been blocked?. For other 403 causes, such as file permissions, see HTTP error 403 Forbidden.
4. On your own VPS or server: installing Imunify360
If you run your own server, Imunify360 is a licensed product you buy from its vendor and install yourself. It supports cPanel, Plesk and DirectAdmin servers, and also servers without a control panel. Check the vendor's current documentation for supported operating systems before you start; use a current release such as AlmaLinux 9 or Ubuntu 24.04 LTS, not an end-of-life system such as CentOS 7.
The standard installation, run as root:
wget https://repo.imunify360.cloudlinux.com/defence360/i360deploy.sh -O i360deploy.sh
bash i360deploy.sh --key YOUR_LICENCE_KEYThen confirm the service is running:
systemctl status imunify360
imunify360-agent versionOn a cPanel, Plesk or DirectAdmin server, Imunify360 adds its own page to the administrator interface. That page is where you manage the WAF from then on.
5. Configuring the WAF on your own server
The WAF settings are under Imunify360's Settings page, in the web application firewall section. The main choices:
| Setting | What it does | Suggested starting point |
|---|---|---|
| Ruleset: Full or Minimized | Full applies the complete ruleset; Minimized uses fewer rules to save memory on small servers | Full, unless the server is short on RAM |
| Application-specific rules | Adds rules for the CMS software detected on the server | On |
| CMS account-compromise prevention | Protects CMS logins from password guessing | On |
You can also change settings from the command line, which is useful for scripted builds:
imunify360-agent config update '{"MOD_SEC": {"ruleset": "FULL"}}'
imunify360-agent config show6. Handling false positives on your own server
When a legitimate request is blocked, fix the specific rule for the specific site rather than weakening protection for everything.
- Find the incident.Open the Imunify360 Incidents list and filter by IP address, domain or time. Each entry shows the rule ID and a description.
- Confirm it is legitimate.Check the URL and request. A rule that fires on a request you did not make yourself may be a real attack.
- Disable the rule for one domain.Use the option in the incident list, or the command line.
- Retest and review.Repeat the action, and review your exclusions every few months.
To disable one ModSecurity rule for a single domain from the command line:
imunify360-agent rules disable --id 214920 --plugin modsec --name "Page builder save" --domains example.comReplace the ID, the label and the domain with your own. Avoid allow-listing IP addresses to get around the WAF: an allow-listed address skips protection entirely, and home and mobile IPs change hands.
Write your own ModSecurity rules only when you understand the syntax and have a test site. A badly written rule can block every visitor or silently stop protecting a path. Each custom rule needs a unique ID that doesn't clash with vendor rules.
7. Good practice for WordPress and other CMSs
A WAF reduces risk but doesn't replace basic hygiene. These apply on shared hosting and on your own server alike:
- Keep everything updated. Most compromises come from outdated plugins and themes.
- Use strong, unique passwords and two-factor login for CMS administrators, and avoid the username
admin. - Remove unused plugins and themes rather than just deactivating them.
- Watch for new administrator accounts you did not create.
For more, see why WordPress sites get hacked and the security checklist for a hacked site.
8. Where Domain India fits
If you want the WAF managed for you, shared hosting includes it: on our cPanel servers Imunify360 runs with the FULL ruleset and also removes malicious code from infected files automatically, keeping the original for 14 days. Cleaning a hacked website by hand is not part of standard support. Prices on the card are live and exclude 18% GST.
- 25 GB NVMe SSD Storage
- 50 GB Monthly Bandwidth
- 1 Website
- 10 Email Accounts
If you need your own server, a Domain India VPS is self-managed: you choose, license and configure your own security software, including Imunify360 if you want it.
- 1 vCPU
- 2 GB DDR4 RAM
- 64 GB NVMe SSD Storage
- 2 TB Monthly Bandwidth
Is Imunify360 WAF active on Domain India shared hosting?
Yes. On Domain India cPanel shared servers, Imunify360 runs server-wide with the FULL ModSecurity ruleset, application-specific rules and CMS account-compromise prevention switched on. It protects every account on the server; there is nothing to install.
Does a higher hosting plan get stronger WAF protection?
No. The WAF is configured once for the whole server, so every account on that server gets the same ruleset whatever its plan.
Can I disable a WAF rule for my website on shared hosting?
Not yourself. Server-level WAF settings are managed by Domain India. Open a support ticket with the blocked URL, the time and your public IP, and support will check the rule and decide whether an exclusion is needed.
Why does my page builder show a 403 error when I save?
A WAF rule may have matched the content being saved. Note the URL and time, then open a support ticket so the matching rule can be found in the server logs.
How do I install Imunify360 on my own VPS?
Buy a licence from the vendor, then as root download i360deploy.sh from the Imunify360 repository and run it with your licence key. Check the vendor's documentation for supported operating systems first.
Does the WAF replace updating WordPress?
No. The WAF blocks many known attacks, but outdated plugins and themes, weak passwords and unused extensions remain the main causes of hacked sites.
Ready to go further? Read why WordPress sites get hacked, compare cPanel hosting plans, or open a ticket if the WAF is blocking something you need.
Send the URL, the time and your public IP address. Support can find the matching rule and check whether an exclusion is needed.
Open a support ticket