Feature Request: Add Fail2Ban to FlyWP Provisioning + Management UI (SSH + WordPress Protection)

FlyWP-managed servers are constantly targeted by automated brute-force bots. Two attack vectors are especially noisy and costly:

SSH brute force

Observing 4–5 unauthorized attempts per minute from rotating IPs.

Common usernames attempted: root, admin, ubuntu, postgres, docker, etc.

WordPress login brute force (wp-login.php / xmlrpc.php)

Continuous credential stuffing attempts that cause:

Increased DB load from authentication queries

PHP worker exhaustion / resource spikes

Potential lockouts for real users

Increased risk of compromise if weak credentials exist

Even with SSH locked down to key-based auth, WordPress sites remain exposed to login brute forcing. On smaller servers, these attacks can materially impact uptime and performance.

Current FlyWP Mitigation: Useful, but Not Enough

FlyWP UFW Firewall Panel is helpful for basic port allow/deny rules, but it doesn’t address behavioral abuse:

No rate limiting options in the UI

No automatic IP banning based on repeated failures

No application-aware rules (per-site / per-URL patterns like wp-login.php)

No visibility into active offenders / bans

Proposed Solution

Add Fail2Ban as an optional component in FlyWP server provisioning, plus a Fail2Ban management panel inside FlyWP.

Goals

Protect SSH from brute-force attempts

Protect WordPress logins (wp-login.php) and XML-RPC attacks

Support both Nginx and OpenLiteSpeed (with equivalent jails/filters)

Suggested Default Jails (Nginx + OpenLiteSpeed equivalents) Jail Protects Monitors sshd SSH access /var/log/auth.log wordpress-login wp-login.php brute force Web access logs (401/403 on wp-login.php) wordpress-xmlrpc XML-RPC attacks Web access logs (POST to xmlrpc.php) nginx-http-auth HTTP basic auth abuse Nginx error logs nginx-limit-req Rate limit violations Nginx error logs wordpress-wplogin-dos Login page DoS High request rate to /wp-login.php

(Repeat the above using OpenLiteSpeed log locations/format.)

WordPress Detection Options Option A: Log-based detection (no plugin required)

Create Fail2Ban filters that match failed logins in web server logs:

Example filter concept:

Match POST /wp-login.php returning 401/403

Match POST /xmlrpc.php

Option B: Plugin-assisted logging (more accurate)

Offer an optional lightweight MU-plugin (or add to the FlyWP WordPress plugin) to log failed logins to syslog, then Fail2Ban watches /var/log/auth.log:

Hook into wp_login_failed

Log source IP + username attempt

This improves accuracy across different WP configurations and login flows.

FlyWP UI / UX Suggestions

A simple panel in FlyWP could include:

Toggle Fail2Ban on/off per server

Enable/disable jails (SSHD, WordPress, XML-RPC, etc.)

Set thresholds: maxretry, findtime, bantime

View active bans + “unban” button

Whitelist IPs (safe list)

Show recent offenders and top blocked IPs

Per-site mapping (FlyWP already knows site roots/log paths)

Optional advanced feature:

Cloudflare API integration to push bans to the edge (reduces origin load further)

Why This Matters

Fail2Ban is lightweight, widely trusted, and a standard hardening step on Ubuntu. Adding it directly to FlyWP would:

Reduce server load from bot attacks

Improve stability on smaller memory servers

Provide stronger defaults for WordPress security

Reduce support incidents related to login abuse and resource exhaustion