Fail2ban and Imunify360

Imunify360 is the web application firewall and malware scanner on our shared and cPanel stacks. Fail2ban is a log-watching tool you can run yourself on a VPS to ban noisy IPs. They cover similar ground in different ways, so you should know which one applies to your plan before you add more layers.

What Imunify360 and Fail2ban each do

Imunify360 watches PHP activity, known malware signatures, and common brute-force patterns. It can quarantine a bad file and block repeated login noise on the paths it is set to protect. It will not catch a stolen admin password used once from a quiet IP, and it does not replace plugin or core updates.

Fail2ban reads service logs such as sshd, mail, or web server logs and temporarily drops matching IPs at the firewall. It is only as useful as the jails and regex you enable. On shared hosting you do not install Fail2ban yourself; the node already runs Imunify360 and related protection. On a VPS without Imunify360, Fail2ban for SSH is a sensible baseline. Running both aggressively on the same login path can lock you out after a few mistyped passwords, including from the panel you need to fix it.

Keep one clear ban path

Do not stack three separate login limiters on top of each other. Default practice is Imunify360 on where it is included, WordPress and plugins kept current, and xmlrpc disabled if you do not use it. Add Fail2ban on a VPS mainly for SSH when Imunify360 is not present. Skip a third login-limiter plugin on the same forms. File permissions still matter; a WAF will not fix world-writable upload directories.

Jails, whitelists, and false positives

Whitelist your office network and any uptime monitors so health checks do not look like attacks. Review active jails on a schedule. A jail that never fires is unused config. A jail that fires constantly often points at a noisy plugin, xmlrpc traffic, or a probe whose pattern matches your own monitor.

Imunify360’s WAF can block a legitimate checkout or payment callback until you whitelist that path. That is a tuning step, not proof that stricter defaults are always better. For Fail2ban, set findtime and bantime to match how you work: a short ban for SSH noise is usually enough. Read the ban list once a month so dead jails and surprise blocks do not sit unnoticed.

Abandoned plugins still execute PHP even when Imunify360 is present. Keep software updated, keep permissions sane, and use only the ban layers your plan actually needs.