Fail2ban, Firewall, and Security Events

Fail2ban automatic ban

The panel will automatically ban based on login attacks, XML-RPC, excessive access speed, sensitive file scans, and a large number of 404 requests, and synchronize to the system firewall and website access rules. Repeated violations will gradually extend the ban duration.

WordPress login and XML-RPC brute force attacks will be displayed as an independent „Login Protection“ source, unaffected by which access log mode the website chooses, and will not be counted together with the site-wide access frequency.

Common ban durations will gradually increase from 10 minutes to 1 hour, 6 hours, 24 hours, up to a maximum of 7 days. Administrators can manually unban or set a permanent ban.

Whitelist and search engines

Website and SSH whitelists are only applied to clearly trusted sources. Search engines such as Googlebot and Bingbot need to be verified through official IP information; a User-Agent name alone cannot prove identity.

Modifying the CDN origin group will affect both Nginx and Fail2ban. If configuration checks fail, the panel will attempt to restore the settings before the modification.

Security events

Security reports will summarize sensitive file scans, SQL injection probes, suspicious PHP requests, fake search engines, file changes, and abnormal visitor IP information.

HTTP 444 indicates that the request has been rejected by the rules. Security events are clues for troubleshooting, not every one needs to be permanently banned again.

Handling false bans

1. View IP, ban source, time, and cumulative count on the firewall page.
2. Verify the visitor address in the website access log against the actual connection source.
3. Confirm that the CDN uses the correct strict mode or compatibility mode.
4. After confirming a false ban, unban it, and only add long-term trusted sources to the whitelist.

Sensitive File Protection

The panel intercepts a small number of high-risk sensitive file accesses at the website service layer, such as .env configuration files and .git directories, to prevent direct reading of website credentials. It is enabled by default for both WordPress and regular PHP websites, and does not affect normal business pages.

WordPress websites also have an additional 「Probe Rate Limiting」 enabled: when a source frequently scans for non-existent configuration or program files within a short period, it will first be rate-limited with a prompt, and if the anomaly persists, it will be handed over to automatic banning. This protection does not block the admin panel, APIs, or normal login operations.

Regular PHP websites do not have probe rate limiting enabled by default, to avoid affecting legitimate APIs, download, or installation pages.

WordPress SQL injection request protection

Under „Security Settings“, you can separately enable high-confidence SQL request blocking and automatic banning of repeated sources, and configure independent thresholds and statistical windows. Requests matching high-confidence URL structures will return 403 before entering PHP; weaker signals are recorded only as security evidence. By default, trusted sources are temporarily banned by an independent rule after accumulating 5 hits within 600 seconds.

WordPress homepage onlysPure searches with parameters, and article or page REST API pure searches with onlysearchparameters are allowed; when other parameters are also present, the request is not exempted as a whole merely because it contains search parameters. This feature only inspects URLs, not POST or JSON request bodies, and is not a complete WAF. A single block only indicates that the request matched a signature; it does not mean a vulnerability or successful intrusion has been confirmed.

Direct connection and strict trusted proxy/CDN modes can participate in automatic banning; compatibility proxy mode still returns 403 and records evidence, but does not automatically ban based on the address in the request header. Cloudflare's official IP ranges and real IP headers are handled globally and strictly by the system, so there is no need to select a Cloudflare group in site details; site-level CDN configuration is used for other CDNs, custom trusted ranges, or compatibility mode.

Disabling blocking or automatic banning does not immediately release existing bans. Existing records are lifted naturally at their original expiry time, and can also be manually unbanned under „Security Defense“. SQL evidence and actions are centralized under „Security Defense“, and no panel, email, or Webhook notifications will be sent.

When saving security settings fails

When a single save involves SQL injection protection, Fail2ban, rate limiting, or log whitelists, the panel submits database changes as a whole and applies server configurations in sequence. If any configuration fails to apply, the panel restores the settings from before the save and re-applies the old configuration; even if restoring one subsystem fails, it will continue attempting the remaining subsystems and aggregate the errors.

Save requests are executed serially to prevent a failed request from overwriting another successfully saved new value. After seeing a failure message, do not assume that some new settings have reliably taken effect; check the actual running state as prompted.

IPv4 and IPv6 persistent banning

Scan defense, panel login protection, and manual administrator bans write to separate IPv4 and IPv6 Nftables sets based on address type. The current bans page merges the actual enforcement status of Fail2ban, persistent Nftables, and Nginx blacklists; the database only supplements the reason, level, and time.

If either the IPv4 or IPv6 set fails to read, the page will still retain results already confirmed by other layers and indicate that the list may be incomplete. A read failure must not be interpreted as meaning there are no bans.

When manual verification via SSH is required, check both address families separately:

nft list set ip wppanel_persist banned_ips
nft list set ip6 wppanel_persist banned_ips

File locks and code integrity

Only for WordPress sites that have file locks enabled and in a healthy locked state will the panel establish a SHA-256 comparison baseline outside the site directory, and check approximately hourly the WordPress core, plugins, themes, MU plugins, drop-ins, key root directory files, and PHP files in the runtime directory. When additions, deletions, or modifications are detected, evidence is recorded and an alert is raised, but files are not automatically deleted, quarantined, or restored.

• The first baseline establishment is only a starting point for future comparisons; it does not mean the site was secure at that time.
• After file locks are disabled, code and component monitoring no longer takes place; changes that occurred while locked become historical and are no longer counted toward current risk.
• Pausing a site retains the old baseline but stops scanning; when re-enabled, changes during the pause are compared, and pausing does not equal authorized maintenance.
• The first version identifies installations, deletions, and code modifications based on file changes, and does not compare plugin activation, deactivation, or theme switching.

For a maintenance window correctly opened via the maintenance password, or a panel-controlled component task, when the first re-lock succeeds and permission verification and state saving all succeed, only a change summary of plugins, themes, MU plugins, or drop-ins is recorded and the new baseline is accepted, without sending security notifications. If the first re-lock fails, the re-lock is restored after a restart, the state is unknown, or changes occur outside the authorized interval, the changes are not silently accepted; instead, the old baseline is retained and an alert is issued as an abnormal change.

Failed updates awaiting manual handling temporarily block integrity scanning, which resumes only after they are handled. This period is a detection gap, and failed tasks should be prioritized.

Integrity monitoring is used for alerts and forensics; it cannot replace malicious code scanning, nor will it automatically remediate on behalf of administrators.