mobieusKnow Firewall Management History #88

Revision #88

Approved
All revisions
Author
system
Submitted
May 30, 2026 7:32pm
Reviewed
May 30, 2026 7:32pm
Summary
2026-05-30 — add pipeline section, snapshot explanation, auto-bans, common scenarios, escalation paths
+ ## Firewall Management
− ## Firewall Viewer
+ `/admin/iptables` is your interface to the platform's firewall. View active rules, block bad actors, whitelist trusted IPs, and review attack patterns. Designed mobile-first so you can ban an IP from your phone.
− `/admin/iptables` shows the live firewall ruleset for your tenant. It is a read-only view: you can see exactly which addresses are currently blocked at the network level and why. To add or remove a block, use the IP Bans page (see below).
+ For automatic banning rules and broader security tooling, see [IP Bans & Security](/know/ip-bans-and-security).
− For managing bans and whitelists, see [IP Bans & Security](/know/ip-bans-and-security).
---
## Page anatomy
+ The v3 redesign organizes the page into 4 zones:
− The page has three zones:
+ | Zone | What it does |
− | Zone | What it shows |
|---|---|
+ | Stat strip | Live counts: active bans, whitelists, 24h ban rate, fail2ban jail size |
+ | Filter chips | One-click filters by type (ban, whitelist, jail) and source (manual, fail2ban, modsec) |
+ | Sticky-header table | Every active rule. Header stays visible as you scroll |
+ | Action drawer | Add a ban, add a whitelist, edit an entry |
− | Stat strip | Live counts: active blocks, whitelisted addresses, recent activity |
− | Filter chips | One-click filters by type and source |
− | Table | Every active firewall rule, with a sticky header as you scroll |
+ The CSS uses an `ipt-*` namespace and semantic theme tokens, so it looks correct on both light and dark themes.
− The page looks correct on both light and dark themes.
---
## Stat strip
+ Shows 4 live counters:
− A row of live counters:
+ - **Active bans.** IPs currently blocked.
+ - **Whitelisted.** IPs that fail2ban will never block.
+ - **24h ban rate.** How many new bans landed in the last 24 hours.
+ - **Jail size.** Current fail2ban jail population.
− - **Active blocks.** Addresses currently blocked.
− - **Whitelisted.** Addresses that are never auto-blocked.
− - **Recent activity.** New blocks added in the last 24 hours.
Each counter clicks through to a filtered view of the table.
---
## Filter chips
+ One row of chips below the stat strip. Click a chip to filter the table. Click again to unfilter. Multiple chips stack.
− A row of chips below the stat strip. Click a chip to filter the table; click again to clear. Multiple chips stack.
+ - **Type:** Ban, Whitelist, Jail
+ - **Source:** Manual, fail2ban, ModSec
− - **Type:** Block, Whitelist
− - **Source:** Manual or automatic
- **Age:** Last hour, Last 24h, Last 7d, All time
The filter is reflected in the URL, so you can share a filtered view.
---
## Table
A single sticky-header table. Columns:
| Column | Notes |
|---|---|
+ | IP | Click to copy via App.toast notification |
+ | CIDR | If the entry is a range, the CIDR mask |
+ | Type | Ban or Whitelist |
+ | Source | Manual, fail2ban, ModSec |
+ | Reason | Free text or rule ID |
− | IP | Click to copy |
− | CIDR | If the entry is a range, the network mask |
− | Type | Block or Whitelist |
− | Source | Manual or automatic |
− | Reason | Free text or rule reference |
| Added | Time ago, full timestamp on hover |
+ | Expires | When the ban auto-lifts (blank for permanent) |
+ | Actions | Unban, edit reason, copy |
− | Expires | When the block auto-lifts (blank for permanent) |
Click any column header to sort.
---
+
+ ## Adding a ban
+
+ Click **Add ban** in the toolbar. Fill 3 fields:
+ - **IP or CIDR.** Single IP or range. Example: `203.0.113.5` or `203.0.113.0/24`.
+ - **Reason.** Free text. Will show in audit log.
+ - **Duration.** Permanent, 1 hour, 24 hours, 7 days, 30 days.
− ## Adding and removing blocks
+ Save. The ban is live within seconds.
− Adding a block, adding a whitelist, and lifting a block all happen on the **IP Bans** page, not here. This viewer is read-only by design, so a glance at the firewall can never change it. Open [IP Bans & Security](/know/ip-bans-and-security) to make changes.
---
+
+ ## Adding a whitelist
+ Same flow. Click **Add whitelist**, fill the fields, save. Whitelisted IPs are never auto-banned by fail2ban or ModSec.
− ## How current the view is
+ Use whitelists for:
− The view can be up to about a minute behind the live ruleset. If you just added or lifted a block on the IP Bans page and don't see it reflected here yet, give it a minute or refresh.
+ - Your office IP (so a typo doesn't lock you out)
+ - A shared VPN that other admins use
+ - Trusted monitoring services (Pingdom, UptimeRobot)
− If the view shows a stale-data warning that persists for more than a few minutes, open a ticket with [[email protected]](mailto:[email protected]) and we'll look into it.
---
+
+ ## Destructive actions confirm safely
+ The redesign replaces native browser `confirm()` dialogs with themed modal dialogs. Click **Unban** and a Mobieus-styled modal asks you to confirm. Click outside to cancel.
− ## Blocks you did not add
+ This means:
− Some addresses are blocked automatically when they show clear signs of abuse, such as brute-force login attempts or known attack patterns. These appear in the table with their **Source** set to automatic and a short reason.
+ - Confirmation dialogs match your theme (light or dark)
+ - Mobile users see a properly sized modal instead of a tiny browser prompt
+ - Screen readers announce the action clearly
− If you think an automatic block caught a real member by mistake, lift it and add a whitelist for their address on the IP Bans page. Whitelisted addresses are never auto-blocked.
---
## Mobile
+
+ The page is fully responsive. On narrow screens:
+ - Stat strip stacks vertically
+ - Filter chips wrap to multiple rows
+ - Table switches to card layout with key fields stacked
+ - Action drawer slides up from the bottom
− The page is fully responsive. On narrow screens the stat strip stacks, the filter chips wrap, and the table switches to a card layout with key fields stacked.
---
## Access
+
+ Requires Tenant Admin role or higher. Tenant Super Mods can view but not edit.
+
+ ---
+
+ ## Audit trail
+
+ Every ban, whitelist, edit, and unban writes to the audit log. View the trail at `/admin/audit-log` filtered to firewall events.
+
+ ---
+
+ ## How bans actually take effect (the pipeline)
+
+ When you click **Add ban** or **Unban**, three things happen in this order:
+
+ 1. **Database write.** The ban entry lands in your tenant's `ip_bans` table with the type, source, reason, and expiry you specified. This part is instant — the audit log entry is the proof.
+
+ 2. **Marker file touched.** The page writes a sentinel file telling the host-level sync watcher there's work to do.
+
+ 3. **Watcher runs the kernel sync.** A platform-level watcher polls for the marker every 10 seconds. When it sees one, it rebuilds the kernel's `iptables` ruleset from the DB and removes the marker.
+
+ **End-to-end latency:** click to kernel rule visible is typically **10 to 15 seconds**. If you reload `/admin/iptables` immediately after a ban, the table will show the new entry instantly (it is reading the DB), but the kernel rule may take a few seconds to actually start blocking traffic.
+
+ A backstop minute-cron also runs the full sync once a minute regardless of marker, so even if the watcher misses a tick, your bans never go more than 60 seconds without being applied.
+
+ ---
+
+ ## Where the live data comes from
+
+ Mobieus runs hardened PHP. The `exec` and `shell_exec` family is disabled for security, which means PHP cannot shell out to `iptables -L` directly. Instead, a minute-cron snapshot job dumps the current kernel ruleset to a JSON file that PHP reads on every page load.
+
+ Consequence: **the page can be up to 60 seconds stale.** If you just banned an IP and do not see it in the table yet, give it a minute or hit refresh.
+
+ If the snapshot is more than 5 minutes old, the page shows a warning banner. That usually means the cron is broken. Open a ticket with [[email protected]](mailto:[email protected]) and we will clear it from the platform side.
+
+ ---
+
+ ## Auto-bans you did not make
+
+ Two systems can ban IPs without you clicking anything:
+
+ - **fail2ban** watches your nginx logs and bans IPs that hit too many 4xx/5xx errors in a short window. Default jail times are short: 10 minutes for HTTP 401 floods, 1 hour for SSH brute-forces.
+ - **ModSec** (ModSecurity WAF) bans IPs that trigger high-severity OWASP CRS rules: SQL injection attempts, XSS payloads, RFI/LFI patterns. Bans from ModSec are typically longer, 24 hours to permanent.
+
+ Auto-bans appear in the table with their **Source** column set to `fail2ban` or `modsec`. The **Reason** column shows the rule ID or jail name.
+ If you think an auto-ban is a false positive (a legitimate member who hit a rate limit during a busy weekend, for example), just **Unban** them and **Add a whitelist** for their IP. Whitelists override every auto-banner.
− Requires the Tenant Super Admin role. This page is view-only.
---
## Common scenarios
+
+ **"I accidentally banned my own IP and now I cannot log in."**
+
+ Use your phone on cell data (different IP) or a VPN to get back into `/admin/iptables`. Find your IP in the table and click Unban. If you have no second device, email [email protected] with the timestamp of when you locked yourself out. Support can clear the ban from the platform side within minutes.
+ **"I see a ban I do not understand."**
− **"I accidentally blocked my own address and now I cannot log in."**
+ Check the **Source** and **Reason** columns. If Source is `fail2ban`, the IP triggered a brute-force pattern. If Source is `modsec`, the IP hit a WAF rule (the rule ID links through to its description). Either way, you can unban without needing to understand the original trigger. Worth flagging recurring patterns to support so the rule tuning can improve.
− Get back in from a different network (cell data or a VPN), open the IP Bans page, find your address, and lift the block. If you have no second device, email [email protected] with the timestamp of when you locked yourself out, and we can clear it.
+ **"I need to ban a whole CIDR range."**
− **"I see a block I do not understand."**
+ Use CIDR notation in the IP field: `198.51.100.0/24` bans all 256 addresses in that /24. The platform clamps very large CIDRs (anything broader than `/16`) to prevent accidentally banning a hyperscaler's whole address space and locking out half your members.
− Check the **Source** and **Reason** columns. If the source is automatic, the address matched an abuse pattern. You can lift it from the IP Bans page without needing to know the original trigger. Worth flagging recurring patterns to support so we can tune them.
+ **"I want to un-ban everyone and start fresh."**
− **"I need to block a whole range."**
+ There is no bulk-unban button by design. Sweeping clears are too easy to do wrong. Filter the table by Source (just `fail2ban` bans, for example), then unban entries one at a time. For a real "rebuild the rules from scratch" emergency, escalate to support.
− Use CIDR notation on the IP Bans page. For example, `198.51.100.0/24` covers all 256 addresses in that range. Very broad ranges are clamped to avoid accidentally blocking a large provider's whole address space.
---
## When to escalate
Open a ticket with [[email protected]](mailto:[email protected]) if:
+ - The snapshot banner is stuck stale for more than 10 minutes
+ - An IP you unbanned is still being blocked after 2 minutes
+ - You are seeing more than 50 new auto-bans per hour and traffic looks legitimate
+ - You suspect ModSec is blocking real members on a high-traffic event day
− - The stale-data warning stays up for more than 10 minutes
− - An address you lifted is still being blocked after a couple of minutes
− - You're seeing a surge of automatic blocks during a busy event and the traffic looks legitimate
+ Support can adjust fail2ban thresholds, tune ModSec rules, and clear stuck snapshots directly on the platform host.
− Support can tune the automatic block thresholds and clear stuck states for you.

Firewall Management

/admin/iptables is your interface to the platform's firewall. View active rules, block bad actors, whitelist trusted IPs, and review attack patterns. Designed mobile-first so you can ban an IP from your phone.

For automatic banning rules and broader security tooling, see IP Bans & Security.

Page anatomy

The v3 redesign organizes the page into 4 zones:

Zone What it does
Stat strip Live counts: active bans, whitelists, 24h ban rate, fail2ban jail size
Filter chips One-click filters by type (ban, whitelist, jail) and source (manual, fail2ban, modsec)
Sticky-header table Every active rule. Header stays visible as you scroll
Action drawer Add a ban, add a whitelist, edit an entry

The CSS uses an ipt-* namespace and semantic theme tokens, so it looks correct on both light and dark themes.

Stat strip

Shows 4 live counters:

  • Active bans. IPs currently blocked.
  • Whitelisted. IPs that fail2ban will never block.
  • 24h ban rate. How many new bans landed in the last 24 hours.
  • Jail size. Current fail2ban jail population.

Each counter clicks through to a filtered view of the table.

Filter chips

One row of chips below the stat strip. Click a chip to filter the table. Click again to unfilter. Multiple chips stack.

  • Type: Ban, Whitelist, Jail
  • Source: Manual, fail2ban, ModSec
  • Age: Last hour, Last 24h, Last 7d, All time

The filter is reflected in the URL, so you can share a filtered view.

Table

A single sticky-header table. Columns:

Column Notes
IP Click to copy via App.toast notification
CIDR If the entry is a range, the CIDR mask
Type Ban or Whitelist
Source Manual, fail2ban, ModSec
Reason Free text or rule ID
Added Time ago, full timestamp on hover
Expires When the ban auto-lifts (blank for permanent)
Actions Unban, edit reason, copy

Click any column header to sort.

Adding a ban

Click Add ban in the toolbar. Fill 3 fields:

  • IP or CIDR. Single IP or range. Example: 203.0.113.5 or 203.0.113.0/24.
  • Reason. Free text. Will show in audit log.
  • Duration. Permanent, 1 hour, 24 hours, 7 days, 30 days.

Save. The ban is live within seconds.

Adding a whitelist

Same flow. Click Add whitelist, fill the fields, save. Whitelisted IPs are never auto-banned by fail2ban or ModSec.

Use whitelists for:

  • Your office IP (so a typo doesn't lock you out)
  • A shared VPN that other admins use
  • Trusted monitoring services (Pingdom, UptimeRobot)

Destructive actions confirm safely

The redesign replaces native browser confirm() dialogs with themed modal dialogs. Click Unban and a Mobieus-styled modal asks you to confirm. Click outside to cancel.

This means:

  • Confirmation dialogs match your theme (light or dark)
  • Mobile users see a properly sized modal instead of a tiny browser prompt
  • Screen readers announce the action clearly

Mobile

The page is fully responsive. On narrow screens:

  • Stat strip stacks vertically
  • Filter chips wrap to multiple rows
  • Table switches to card layout with key fields stacked
  • Action drawer slides up from the bottom

Access

Requires Tenant Admin role or higher. Tenant Super Mods can view but not edit.

Audit trail

Every ban, whitelist, edit, and unban writes to the audit log. View the trail at /admin/audit-log filtered to firewall events.

How bans actually take effect (the pipeline)

When you click Add ban or Unban, three things happen in this order:

  1. Database write. The ban entry lands in your tenant's ip_bans table with the type, source, reason, and expiry you specified. This part is instant — the audit log entry is the proof.

  2. Marker file touched. The page writes a sentinel file telling the host-level sync watcher there's work to do.

  3. Watcher runs the kernel sync. A platform-level watcher polls for the marker every 10 seconds. When it sees one, it rebuilds the kernel's iptables ruleset from the DB and removes the marker.

End-to-end latency: click to kernel rule visible is typically 10 to 15 seconds. If you reload /admin/iptables immediately after a ban, the table will show the new entry instantly (it is reading the DB), but the kernel rule may take a few seconds to actually start blocking traffic.

A backstop minute-cron also runs the full sync once a minute regardless of marker, so even if the watcher misses a tick, your bans never go more than 60 seconds without being applied.

Where the live data comes from

Mobieus runs hardened PHP. The exec and shell_exec family is disabled for security, which means PHP cannot shell out to iptables -L directly. Instead, a minute-cron snapshot job dumps the current kernel ruleset to a JSON file that PHP reads on every page load.

Consequence: the page can be up to 60 seconds stale. If you just banned an IP and do not see it in the table yet, give it a minute or hit refresh.

If the snapshot is more than 5 minutes old, the page shows a warning banner. That usually means the cron is broken. Open a ticket with [email protected] and we will clear it from the platform side.

Auto-bans you did not make

Two systems can ban IPs without you clicking anything:

  • fail2ban watches your nginx logs and bans IPs that hit too many 4xx/5xx errors in a short window. Default jail times are short: 10 minutes for HTTP 401 floods, 1 hour for SSH brute-forces.
  • ModSec (ModSecurity WAF) bans IPs that trigger high-severity OWASP CRS rules: SQL injection attempts, XSS payloads, RFI/LFI patterns. Bans from ModSec are typically longer, 24 hours to permanent.

Auto-bans appear in the table with their Source column set to fail2ban or modsec. The Reason column shows the rule ID or jail name.

If you think an auto-ban is a false positive (a legitimate member who hit a rate limit during a busy weekend, for example), just Unban them and Add a whitelist for their IP. Whitelists override every auto-banner.

Common scenarios

"I accidentally banned my own IP and now I cannot log in."

Use your phone on cell data (different IP) or a VPN to get back into /admin/iptables. Find your IP in the table and click Unban. If you have no second device, email [email protected] with the timestamp of when you locked yourself out. Support can clear the ban from the platform side within minutes.

"I see a ban I do not understand."

Check the Source and Reason columns. If Source is fail2ban, the IP triggered a brute-force pattern. If Source is modsec, the IP hit a WAF rule (the rule ID links through to its description). Either way, you can unban without needing to understand the original trigger. Worth flagging recurring patterns to support so the rule tuning can improve.

"I need to ban a whole CIDR range."

Use CIDR notation in the IP field: 198.51.100.0/24 bans all 256 addresses in that /24. The platform clamps very large CIDRs (anything broader than /16) to prevent accidentally banning a hyperscaler's whole address space and locking out half your members.

"I want to un-ban everyone and start fresh."

There is no bulk-unban button by design. Sweeping clears are too easy to do wrong. Filter the table by Source (just fail2ban bans, for example), then unban entries one at a time. For a real "rebuild the rules from scratch" emergency, escalate to support.

When to escalate

Open a ticket with [email protected] if:

  • The snapshot banner is stuck stale for more than 10 minutes
  • An IP you unbanned is still being blocked after 2 minutes
  • You are seeing more than 50 new auto-bans per hour and traffic looks legitimate
  • You suspect ModSec is blocking real members on a high-traffic event day

Support can adjust fail2ban thresholds, tune ModSec rules, and clear stuck snapshots directly on the platform host.

## Firewall Management

`/admin/iptables` is your interface to the platform's firewall. View active rules, block bad actors, whitelist trusted IPs, and review attack patterns. Designed mobile-first so you can ban an IP from your phone.

For automatic banning rules and broader security tooling, see [IP Bans & Security](/know/ip-bans-and-security).

---

## Page anatomy

The v3 redesign organizes the page into 4 zones:

| Zone | What it does |
|---|---|
| Stat strip | Live counts: active bans, whitelists, 24h ban rate, fail2ban jail size |
| Filter chips | One-click filters by type (ban, whitelist, jail) and source (manual, fail2ban, modsec) |
| Sticky-header table | Every active rule. Header stays visible as you scroll |
| Action drawer | Add a ban, add a whitelist, edit an entry |

The CSS uses an `ipt-*` namespace and semantic theme tokens, so it looks correct on both light and dark themes.

---

## Stat strip

Shows 4 live counters:

- **Active bans.** IPs currently blocked.
- **Whitelisted.** IPs that fail2ban will never block.
- **24h ban rate.** How many new bans landed in the last 24 hours.
- **Jail size.** Current fail2ban jail population.

Each counter clicks through to a filtered view of the table.

---

## Filter chips

One row of chips below the stat strip. Click a chip to filter the table. Click again to unfilter. Multiple chips stack.

- **Type:** Ban, Whitelist, Jail
- **Source:** Manual, fail2ban, ModSec
- **Age:** Last hour, Last 24h, Last 7d, All time

The filter is reflected in the URL, so you can share a filtered view.

---

## Table

A single sticky-header table. Columns:

| Column | Notes |
|---|---|
| IP | Click to copy via App.toast notification |
| CIDR | If the entry is a range, the CIDR mask |
| Type | Ban or Whitelist |
| Source | Manual, fail2ban, ModSec |
| Reason | Free text or rule ID |
| Added | Time ago, full timestamp on hover |
| Expires | When the ban auto-lifts (blank for permanent) |
| Actions | Unban, edit reason, copy |

Click any column header to sort.

---

## Adding a ban

Click **Add ban** in the toolbar. Fill 3 fields:

- **IP or CIDR.** Single IP or range. Example: `203.0.113.5` or `203.0.113.0/24`.
- **Reason.** Free text. Will show in audit log.
- **Duration.** Permanent, 1 hour, 24 hours, 7 days, 30 days.

Save. The ban is live within seconds.

---

## Adding a whitelist

Same flow. Click **Add whitelist**, fill the fields, save. Whitelisted IPs are never auto-banned by fail2ban or ModSec.

Use whitelists for:

- Your office IP (so a typo doesn't lock you out)
- A shared VPN that other admins use
- Trusted monitoring services (Pingdom, UptimeRobot)

---

## Destructive actions confirm safely

The redesign replaces native browser `confirm()` dialogs with themed modal dialogs. Click **Unban** and a Mobieus-styled modal asks you to confirm. Click outside to cancel.

This means:

- Confirmation dialogs match your theme (light or dark)
- Mobile users see a properly sized modal instead of a tiny browser prompt
- Screen readers announce the action clearly

---

## Mobile

The page is fully responsive. On narrow screens:

- Stat strip stacks vertically
- Filter chips wrap to multiple rows
- Table switches to card layout with key fields stacked
- Action drawer slides up from the bottom

---

## Access

Requires Tenant Admin role or higher. Tenant Super Mods can view but not edit.

---

## Audit trail

Every ban, whitelist, edit, and unban writes to the audit log. View the trail at `/admin/audit-log` filtered to firewall events.

---

## How bans actually take effect (the pipeline)

When you click **Add ban** or **Unban**, three things happen in this order:

1. **Database write.** The ban entry lands in your tenant's `ip_bans` table with the type, source, reason, and expiry you specified. This part is instant — the audit log entry is the proof.

2. **Marker file touched.** The page writes a sentinel file telling the host-level sync watcher there's work to do.

3. **Watcher runs the kernel sync.** A platform-level watcher polls for the marker every 10 seconds. When it sees one, it rebuilds the kernel's `iptables` ruleset from the DB and removes the marker.

**End-to-end latency:** click to kernel rule visible is typically **10 to 15 seconds**. If you reload `/admin/iptables` immediately after a ban, the table will show the new entry instantly (it is reading the DB), but the kernel rule may take a few seconds to actually start blocking traffic.

A backstop minute-cron also runs the full sync once a minute regardless of marker, so even if the watcher misses a tick, your bans never go more than 60 seconds without being applied.

---

## Where the live data comes from

Mobieus runs hardened PHP. The `exec` and `shell_exec` family is disabled for security, which means PHP cannot shell out to `iptables -L` directly. Instead, a minute-cron snapshot job dumps the current kernel ruleset to a JSON file that PHP reads on every page load.

Consequence: **the page can be up to 60 seconds stale.** If you just banned an IP and do not see it in the table yet, give it a minute or hit refresh.

If the snapshot is more than 5 minutes old, the page shows a warning banner. That usually means the cron is broken. Open a ticket with [[email protected]](mailto:[email protected]) and we will clear it from the platform side.

---

## Auto-bans you did not make

Two systems can ban IPs without you clicking anything:

- **fail2ban** watches your nginx logs and bans IPs that hit too many 4xx/5xx errors in a short window. Default jail times are short: 10 minutes for HTTP 401 floods, 1 hour for SSH brute-forces.
- **ModSec** (ModSecurity WAF) bans IPs that trigger high-severity OWASP CRS rules: SQL injection attempts, XSS payloads, RFI/LFI patterns. Bans from ModSec are typically longer, 24 hours to permanent.

Auto-bans appear in the table with their **Source** column set to `fail2ban` or `modsec`. The **Reason** column shows the rule ID or jail name.

If you think an auto-ban is a false positive (a legitimate member who hit a rate limit during a busy weekend, for example), just **Unban** them and **Add a whitelist** for their IP. Whitelists override every auto-banner.

---

## Common scenarios

**"I accidentally banned my own IP and now I cannot log in."**

Use your phone on cell data (different IP) or a VPN to get back into `/admin/iptables`. Find your IP in the table and click Unban. If you have no second device, email [email protected] with the timestamp of when you locked yourself out. Support can clear the ban from the platform side within minutes.

**"I see a ban I do not understand."**

Check the **Source** and **Reason** columns. If Source is `fail2ban`, the IP triggered a brute-force pattern. If Source is `modsec`, the IP hit a WAF rule (the rule ID links through to its description). Either way, you can unban without needing to understand the original trigger. Worth flagging recurring patterns to support so the rule tuning can improve.

**"I need to ban a whole CIDR range."**

Use CIDR notation in the IP field: `198.51.100.0/24` bans all 256 addresses in that /24. The platform clamps very large CIDRs (anything broader than `/16`) to prevent accidentally banning a hyperscaler's whole address space and locking out half your members.

**"I want to un-ban everyone and start fresh."**

There is no bulk-unban button by design. Sweeping clears are too easy to do wrong. Filter the table by Source (just `fail2ban` bans, for example), then unban entries one at a time. For a real "rebuild the rules from scratch" emergency, escalate to support.

---

## When to escalate

Open a ticket with [[email protected]](mailto:[email protected]) if:

- The snapshot banner is stuck stale for more than 10 minutes
- An IP you unbanned is still being blocked after 2 minutes
- You are seeing more than 50 new auto-bans per hour and traffic looks legitimate
- You suspect ModSec is blocking real members on a high-traffic event day

Support can adjust fail2ban thresholds, tune ModSec rules, and clear stuck snapshots directly on the platform host.