[MokoCBRegGuard] [FEATURE] Subnet burst detection #21

New Issue

2026-06-02T19:31:35Z

jmiller commented

2026-06-02 19:31:35 +00:00

Migrated from MokoCBRegGuard#19

Feature Description

Add subnet-level registration velocity checks to detect coordinated signup bursts from IP ranges.

Problem or Use Case

The current IP frequency check uses a fixed window per exact IP. Sophisticated spam operations rotate through IPs within the same subnet (e.g., a /24 block). Three signups from 192.168.1.10, .11, and .12 each pass the per-IP check but are clearly coordinated.

Proposed Solution

Add subnet-level burst detection:

Check registrations from the same /24 subnet (IPv4) or /48 subnet (IPv6) within a short burst window
New params: enable_subnet_check, subnet_mask_ipv4 (default: 24), subnet_mask_ipv6 (default: 48), subnet_burst_window_minutes (default: 30), subnet_burst_max (default: 5)

Generate SUBNET_BURST flag (weight: 2) when threshold exceeded.

Alternative Solutions

Tighter per-IP limits (causes false positives for shared IPs like offices/schools)
Firewall-level rate limiting (too coarse, affects all traffic)

Benefits

Who: Sites targeted by coordinated spam campaigns using IP rotation
Problem solved: Detects distributed-but-related signup patterns invisible to per-IP checks
Value: Catches a common spam evasion technique with minimal false positives

Implementation Details (Optional)

New params in cbregguard.xml
New RegGuardHelper::checkSubnetBurst() static method
IP subnet math: mask IP to network prefix, query #__cbregguard_log for matching subnet
Use inet_pton() for IPv4/IPv6 binary conversion and bitwise masking

Relevant Standards

Security best practices
Code quality standards

Checklist

I have searched for similar feature requests before creating this one
I have clearly described the use case and benefits
I have considered alternative solutions
This feature aligns with the project's goals and scope

> Migrated from MokoCBRegGuard#19 ## Feature Description Add subnet-level registration velocity checks to detect coordinated signup bursts from IP ranges. ## Problem or Use Case The current IP frequency check uses a fixed window per exact IP. Sophisticated spam operations rotate through IPs within the same subnet (e.g., a /24 block). Three signups from 192.168.1.10, .11, and .12 each pass the per-IP check but are clearly coordinated. ## Proposed Solution Add subnet-level burst detection: - Check registrations from the same /24 subnet (IPv4) or /48 subnet (IPv6) within a short burst window - New params: `enable_subnet_check`, `subnet_mask_ipv4` (default: 24), `subnet_mask_ipv6` (default: 48), `subnet_burst_window_minutes` (default: 30), `subnet_burst_max` (default: 5) Generate `SUBNET_BURST` flag (weight: 2) when threshold exceeded. ## Alternative Solutions - Tighter per-IP limits (causes false positives for shared IPs like offices/schools) - Firewall-level rate limiting (too coarse, affects all traffic) ## Benefits - **Who:** Sites targeted by coordinated spam campaigns using IP rotation - **Problem solved:** Detects distributed-but-related signup patterns invisible to per-IP checks - **Value:** Catches a common spam evasion technique with minimal false positives ## Implementation Details (Optional) - New params in `cbregguard.xml` - New `RegGuardHelper::checkSubnetBurst()` static method - IP subnet math: mask IP to network prefix, query `#__cbregguard_log` for matching subnet - Use `inet_pton()` for IPv4/IPv6 binary conversion and bitwise masking ## Relevant Standards - [x] Security best practices - [x] Code quality standards ## Checklist - [x] I have searched for similar feature requests before creating this one - [x] I have clearly described the use case and benefits - [x] I have considered alternative solutions - [x] This feature aligns with the project's goals and scope

jmiller added the pending: testing regguard labels 2026-06-02 19:52:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoJoomCommunity#21