Webshield is the Imunify360 component most operators misunderstand or disable outright after a single support ticket about "weird security pages". It is not the WAF and it is not the malware scanner — it is an IP-reputation filter sitting in front of Apache or LiteSpeed that decides, per request, whether the visitor goes straight through, gets challenged with a captcha, or is dropped at the firewall.
Run correctly, Webshield cuts the bot floor on a shared host by 60-80% — every login bruteforcer, XML-RPC pingback abuser, and SEO-spider-pretending-to-be-Googlebot eats a captcha or a 403 before PHP starts. Run badly, it shows real customers a splash screen they assume is a phishing page and you get a flood of WHMCS tickets. The difference is fifteen minutes of configuration and one decision about how to handle visitors behind a reverse proxy.
What Webshield actually does
Webshield reads from the same IP-reputation feed that Imunify Central uses across every installed instance — millions of brute force, scanner, and exploit-scan signals aggregated in near real time. For each incoming request it puts the source IP into one of three buckets:
- White — known good. Search engines (verified Googlebot, Bingbot), large CDNs, the operator's own monitoring IPs. Passes through with no inspection.
- Gray — suspicious. IPs with recent abusive activity but not yet bad enough to block. Imunify360 returns a splash screen with a captcha. If the visitor solves it, their IP is moved to white for a configurable window (default 30 minutes). If they fail or never load the page, nothing else happens — the next request hits the captcha again.
- Black — confirmed bad. Dropped with a 403 at the web server, or at the firewall level if
BLOCKEDmode is enabled.
The interesting part is the gray bucket. A naive blocklist drops anything that has ever scanned. Webshield assumes a percentage of those IPs are dynamic — a shared CGNAT pool, a corporate proxy, a residential IP recycled to a new user — and gives the human behind it a way to prove they are not a bot. That is the whole product.
Enable Webshield without breaking a Cloudflare deployment
Almost every Webshield disaster starts with Cloudflare in front of the origin. Without known_proxies support, Webshield sees every request coming from a small pool of Cloudflare edge IPs, marks the whole pool as suspicious as soon as one user trips a rule, and every visitor — including the operator — hits a splash screen on every request.
The fix is the same as for any other reverse-proxy-aware feature: tell Imunify360 to trust the CF-Connecting-IP header (or whichever real-IP header the proxy sets) before it scores the visitor. The full procedure is covered in Imunify360 behind Cloudflare with the real visitor IP. Do that first, then come back here.
Once real-IP is correct, turn Webshield on in graylist mode:
imunify360-agent config update '{"WEBSHIELD": {"enable": true}}'
imunify360-agent config update '{"WEBSHIELD": {"known_proxies_support": true}}'
imunify360-agent config show | grep -A6 WEBSHIELD
The two settings are independent. enable turns the filter on; known_proxies_support makes it score the real client and not the proxy. Skip the second one and you get the disaster described above.
Choose a captcha provider
Imunify360 ships with three captcha backends. The choice matters because it changes both the user experience and what gets through.
| Provider | Behaviour | When to use |
|---|---|---|
| Local captcha | Imunify's own checkbox-style challenge. No external calls. | Default. Works offline, works for HIPAA/PCI customers who object to Google. |
| reCAPTCHA v2 | Google "I am not a robot" checkbox. Free, well-tuned. | High-traffic shared hosts where local captcha bots are starting to solve. |
| hCaptcha | Privacy-focused, EU-friendly, similar UX to reCAPTCHA. | EU shared hosts, GDPR-conscious resellers. |
Configure the provider once and Webshield uses it for every splash screen across every customer site:
imunify360-agent config update '{"WEBSHIELD": {"captcha_provider": "hcaptcha"}}'
imunify360-agent config update '{"WEBSHIELD": {"hcaptcha_sitekey": "10000000-ffff-ffff-ffff-000000000001"}}'
imunify360-agent config update '{"WEBSHIELD": {"hcaptcha_secret": "0x0000000000000000000000000000000000000000"}}'
The local captcha is the right starting point. Move to hCaptcha or reCAPTCHA only when the Imunify360 dashboard shows a meaningful number of captcha solves originating from blocklisted IPs — that is the signal that bots have learned the local challenge.
Whitelist monitoring, uptime checkers, and your own IPs
The first thing every operator learns the hard way: UptimeRobot, Pingdom, StatusCake, and Better Stack all show up as graylisted within hours of enabling Webshield because they hit hundreds of customer sites per minute from a small pool of IPs. They never solve the captcha. The monitoring goes red.
Pin them to white permanently:
imunify360-agent ip-list local add --white --comment "uptimerobot" 216.144.250.0/24
imunify360-agent ip-list local add --white --comment "pingdom" 178.255.152.0/22
imunify360-agent ip-list local add --white --comment "operator-noc" 198.51.100.42
Then do the same for the office IP, the staff VPN, and any internal scanning host (Nessus, Acunetix, the operator's own wp-cli cron box). Webshield does not differentiate between "scanning to attack" and "scanning because we are the operator" — anything that looks like scanning is graylisted.
Splash screen branding
The default splash page is a generic Imunify-branded HTML template. Customers running a white-label shared hosting brand can override the template per-end-user without giving them root, by dropping a custom template into the user's home directory under the path Imunify360 reads:
/home/<user>/.imunify360/splash_screen/<language>.html
Imunify360 picks this up automatically. Keep the captcha placeholder token ({{captcha}}) intact — that is where the engine injects the challenge widget. Everything else is yours.
Tuning aggressiveness
Webshield has no single "sensitivity" dial, but two settings together control how aggressively it greylists:
imunify360-agent config update '{"WEBSHIELD": {"check_method": "FULL"}}'
imunify360-agent config update '{"PAM": {"enable": true}}'
check_method: FULLenables behavioural scoring on top of the IP reputation list. Catches more bots, marginally higher false positive rate.PAM(Password Authentication Module) blocks bruteforce attempts at the protocol level — SSH, FTP, IMAP. Not strictly part of Webshield but it shares the same IP scoring, so reputation gathered by SSH bruteforces feeds the HTTP greylist.
Run FULL on production shared hosts. Skip PAM if you front SSH with a bastion or run a non-standard SSH port — the rule set is tuned for port 22.
Verify it is working
Two checks. First, look at the dashboard counter:
Imunify360 → Incidents → filter "Captcha" + last 24h
A healthy shared host with a few hundred busy sites sees somewhere between 5k and 50k captcha challenges per day after a week of operation. If you see zero, Webshield is not in the request path — check that Apache/LiteSpeed loaded the Imunify360 connector module.
Second, hit a graylisted IP manually. Use a known-bad IP from the AbuseIPDB top 100 with curl --resolve to hit your server:
curl -v --resolve example.com:443:<your-ip> https://example.com/ \
-H "X-Forwarded-For: 185.220.101.50"
If known_proxies_support is on and your reverse-proxy headers are configured, the response should be the splash screen HTML with a captcha widget. If it is the real site, Webshield is reading the wrong client IP.
For deeper integration with the WAF and the firewall — particularly how Webshield, ModSecurity, and CSF coexist without double-blocking — see Imunify360 with CSF and ModSecurity coexistence. For new installs from scratch, start with install Imunify360 on cPanel.
Next steps
- Imunify360 behind Cloudflare with the real visitor IP
- Tune Imunify360 WAF false positives
- Activate an Imunify360 license