Static Filter Rules – Block or Allow RADIUS Requests by Attribute

Overview

The Static Filter Rules page provides rule-based filtering for incoming RADIUS authentication requests. Each rule matches against a specific RADIUS attribute — either User-Name (type 1) or Calling-Station-ID (type 33) — using one of several operators, and either blocks or allows the request when matched.

Rules are evaluated in order from lowest to highest. The first matching rule determines the outcome, and subsequent rules are skipped. This page also includes a Block By Default option that blocks all requests that do not match any rule, enabling a whitelist-only configuration.

Static filter rules operate independently from Mideye Shield’s automated IP blocking. While auto-blocked IPs rely on real-time fraud scoring, static filter rules provide permanent, administrator-defined access controls.

Access & Permissions

Required Role: ROOT, SUPER_ADMIN, or ADMIN (to create, edit, delete, or reorder rules)

Navigation: Home → Mideye Shield → Static Filter Rules

Role	View Rules	Create / Edit / Delete	Change Order	Toggle Block By Default
ROOT	✅	✅	✅	✅
SUPER_ADMIN	✅	✅	✅	✅
ADMIN	✅	✅	✅	✅
OPERATOR	✅	❌	❌	❌

Features & Configuration

Data Grid Columns

The data grid displays all static filter rules sorted by evaluation order (ascending). Pagination options: 10, 15, 20, 50, or 100 rows per page.

Column	Description	Hidden by Default
Order	Evaluation priority (lower = first evaluated)	No
Rule Action	BLOCK or ALLOW	No
Rule Attribute	USERNAME or CALLING_STATION_ID	No
Operator	Match operator (EQUAL_TO, CONTAINS, REGEX_MATCH, or SUBNET)	No
Value	The value to match against the attribute	No
Last Hit At	Timestamp of the most recent match (formatted as yyyy-MM-dd HH:mm:ss)	Yes
Hit Count	Total number of times the rule has matched	No
Enabled	Whether the rule is active	No
Comment	Optional administrator note	No
Action	Edit, Delete, and Change Order buttons (admin only)	No

Tip

Enable the Last Hit At column from the column visibility menu to identify stale rules that are no longer matching traffic.

Block By Default

The Block By Default checkbox above the data grid controls the default behavior when no rule matches an incoming request.

Setting	Behavior
Unchecked (default)	Requests that match no filter rule are allowed
Checked	Requests that match no filter rule are blocked

Toggling this setting opens a confirmation dialog:

• Enable: “Caution: This will block all RADIUS requests if no filter rule is hit.”
• Disable: “Caution: This will allow all RADIUS requests if no filter rule is hit.”

Caution

Enabling Block By Default without sufficient ALLOW rules will block all authentication requests. Ensure at least one ALLOW rule exists for legitimate users or IP ranges before enabling this setting.

Creating a Filter Rule

Steps:

1. Click Add New in the toolbar.
2. Fill in the rule fields (see Field Reference).
3. Click Save.

An informational alert at the top of the form reads: “The Static Filter Rule will filter RADIUS request on target attribute that matches the given value via the operator.”

Default values for new rules:

• Rule Action: ALLOW (if Block By Default is enabled) or BLOCK (if disabled)
• Rule Attribute: USERNAME
• Operator: EQUAL_TO
• Value: (empty)
• Enabled: true
• Order: next available position
• Comment: “Created by [username] [date]”

Editing a Filter Rule

Steps:

1. Click the Edit icon in the Action column.
2. Modify the desired fields.
3. Click Save.

Note

You cannot change a rule to have the same combination of Attribute + Operator + Value as an existing rule. Each combination must be unique.

Deleting a Filter Rule

Steps:

1. Click the Delete icon in the Action column.
2. Confirm in the dialog: “Are you sure you want to delete the Static Filter Rule with value [value]?”
3. Click Delete.

Remaining rules are automatically reordered to fill the gap.

Changing Rule Order

Rules are evaluated in ascending order — the rule with the lowest order number is checked first. To change a rule’s position:

1. Click the Change Order (swap) icon in the Action column.
2. Enter the new order number (1 to the total number of rules).
3. Click Change.

All affected rules are automatically renumbered to accommodate the change.

Field Reference

Rule Action

Value	Description
BLOCK	Block the RADIUS request if the rule matches
ALLOW	Allow the RADIUS request if the rule matches

Rule Attribute

Value	RADIUS Attribute	Description
USERNAME	User-Name (type 1)	Filter based on the username in the RADIUS request
CALLING_STATION_ID	Calling-Station-ID (type 33)	Filter based on the client IP or MAC address

Operator

Available operators depend on the selected attribute:

Operator	USERNAME	CALLING_STATION_ID	Match Logic
EQUAL_TO	✅	✅	Exact string match
CONTAINS	✅	✅	Substring match
REGEX_MATCH	✅	✅	Java regular expression match
SUBNET	❌	✅	CIDR subnet match (IPv4 only)

Note

When SUBNET is selected, the Value field must contain valid CIDR notation (e.g., 192.168.1.0/24). The SUBNET operator only works with IPv4 addresses.

Form Fields

Field	Type	Required	Validation	Description
Rule Action	Select	Yes	Must be BLOCK or ALLOW	Determines whether matching requests are blocked or allowed
Rule Attribute	Select	Yes	Must be USERNAME or CALLING_STATION_ID	The RADIUS attribute to match against
Operator	Select	Yes	Must be valid for the selected attribute	The comparison method
Value	Text	Yes	Max 255 characters. CIDR regex validation when operator is SUBNET	The value to match against
Order	Number	Yes	Min: 1, Max: total rule count (+1 on create)	Evaluation priority
Comment	Text	No	Max 255 characters	Administrative note
Enabled	Checkbox	No	—	Whether the rule is active (defaults to true on create)

CIDR Validation Pattern

When the SUBNET operator is selected, the Value field enforces this pattern:

^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|[1-2][0-9]|3[0-2]))$

Valid examples: 192.168.1.0/24, 10.0.0.0/8, 172.16.0.0/12

Rule Evaluation Logic

Understanding how rules are evaluated is critical for correct configuration:

1. Incoming RADIUS request arrives.
2. Rules are iterated in order (lowest order first).
3. Disabled rules are skipped entirely.
4. For each enabled rule, the target attribute (User-Name or Calling-Station-ID) is extracted from the request.
5. The value is compared using the rule’s operator.
6. First match wins — the rule’s action (BLOCK or ALLOW) is applied immediately.
7. If no rule matches:
   • Block By Default enabled → request is BLOCKED
   • Block By Default disabled → request is ALLOWED

Common Use Cases

Blocking a Specific User

1. Click Add New.
2. Set Rule Action to BLOCK, Attribute to USERNAME, Operator to EQUAL_TO.
3. Enter the username in the Value field.
4. Click Save.

Allowing a Specific IP Subnet (Whitelist Mode)

1. Enable Block By Default (confirm the warning dialog).
2. Click Add New.
3. Set Rule Action to ALLOW, Attribute to CALLING_STATION_ID, Operator to SUBNET.
4. Enter the subnet in CIDR notation (e.g., 10.0.0.0/8).
5. Click Save.
6. Repeat for each trusted subnet.

Blocking Usernames Matching a Pattern

1. Click Add New.
2. Set Rule Action to BLOCK, Attribute to USERNAME, Operator to REGEX_MATCH.
3. Enter a Java regular expression (e.g., .*@malicious\.domain$).
4. Click Save.

Permanently Allowing an Auto-blocked IP

When an IP is frequently auto-blocked by Mideye Shield but is legitimate:

1. Click Add New.
2. Set Rule Action to ALLOW, Attribute to CALLING_STATION_ID, Operator to EQUAL_TO.
3. Enter the IP address.
4. Click Save.

The static ALLOW rule takes precedence over automated blocking.

Troubleshooting

Issue	Possible Cause	Resolution
Rule not blocking requests	Rule is disabled or has higher order than a matching ALLOW rule	Check the Enabled checkbox and rule order
All requests blocked unexpectedly	Block By Default enabled without ALLOW rules	Disable Block By Default or add appropriate ALLOW rules
Cannot save rule — “already exists”	Duplicate attribute + operator + value combination	Each combination must be unique; modify the value or operator
CIDR validation error	Invalid subnet format	Use valid IPv4 CIDR notation (e.g., 192.168.1.0/24)
SUBNET operator not available	USERNAME attribute selected	SUBNET is only available for CALLING_STATION_ID
Hit Count not increasing	Rule is disabled or never matched	Verify the rule is enabled and the expected traffic is reaching the server
Cannot edit or delete rules	Insufficient permissions	Requires ADMIN role or higher

Related Pages

• Mideye Shield Configuration — Configure automated blocking thresholds and actions
• Auto-blocked IPs — View and manage automatically blocked IP addresses
• Blocked Attempts — View blocked authentication attempts
• Authentication Logs — Review authentication events and block individual IPs