Blocked Attempts – View Authentication Requests Blocked by Security Rules
Overview
Section titled “Overview”The Blocked Attempts page displays all RADIUS authentication requests that were denied before reaching the authentication process. These blocks occur when incoming requests match a static filter rule or are flagged by the Mideye Shield automated protection system.
Reviewing blocked attempts is essential for validating that your security policies are working as intended, identifying false positives that may be blocking legitimate users, and understanding the volume and nature of threats targeting your authentication infrastructure. Each blocked event includes the timestamp, username, calling station ID, and the specific reason the request was blocked.
Access & Permissions
Section titled “Access & Permissions”Required Role: ROOT, SUPER_ADMIN, ADMIN, or OPERATOR
Navigation: Home → Logs → Blocked Attempts
All authenticated users with the required role can view blocked attempts. This is a read-only view — blocked attempts cannot be manually created or deleted from this page.
Features & Configuration
Section titled “Features & Configuration”Viewing Blocked Attempts
Section titled “Viewing Blocked Attempts”The data grid displays blocked authentication attempts with server-side pagination and sorting. By default, events are sorted by time in descending order (newest first).
| Column | Description |
|---|---|
| Time | Timestamp when the authentication attempt was blocked |
| Username | The user identity in the blocked request |
| Calling Station ID | The originating IP address or MAC address |
| Reason | Why the request was blocked |
Block Reasons
Section titled “Block Reasons”| Reason | Description |
|---|---|
| Blocked by Static Filter Rule | The request matched a manually configured static filter rule targeting the username or calling station ID |
| Blocked by Automated Shield | The request was blocked by Mideye Shield’s automated IP reputation and fraud score analysis |
Filtering Blocked Attempts
Section titled “Filtering Blocked Attempts”Click the Filter icon in the toolbar to open the filter panel.
| Filter | Type | Description |
|---|---|---|
| Start Date | Date picker | Beginning of the time range |
| End Date | Date picker | End of the time range |
| Username | Text input | Filter by username |
| Calling Station ID | Text input | Filter by originating address |
| Reason | Single select | Filter by block reason: All, Blocked by Static Filter Rule, or Blocked by Automated Shield |
Click Apply to execute the filter, or Reset to clear all filter fields.
Refreshing Data
Section titled “Refreshing Data”Click the Refresh (loop) icon in the toolbar to reload blocked attempts from the server with the current filter criteria.
Field Reference
Section titled “Field Reference”| Field Name | Type | Required | Description | Validation |
|---|---|---|---|---|
| jhiTime | LocalDateTime | Yes | Timestamp of the blocked attempt | — |
| username | String | No | Username from the blocked authentication request | — |
| callingStationId | String | No | Originating IP or MAC address | — |
| reason | BlockReason | Yes | Enum indicating why the request was blocked | BLOCKED_BY_STATIC_FILTER_RULE or BLOCKED_BY_AUTOMATED_SHIELD |
Actions
Section titled “Actions”Filter
Section titled “Filter”Purpose: Narrow down blocked attempts by date range, username, calling station, or reason. Steps:
- Click the Filter icon in the toolbar.
- Set desired filter values.
- Click Apply.
Result: The data grid updates to show only matching blocked attempts.
Refresh
Section titled “Refresh”Purpose: Reload the latest blocked attempt data. Steps: Click the Refresh (loop) icon in the toolbar. Result: The data grid refreshes with current data.
Common Use Cases
Section titled “Common Use Cases”Verifying Static Filter Rules Are Working
Section titled “Verifying Static Filter Rules Are Working”- Create a static filter rule targeting a specific username or IP address.
- Navigate to Blocked Attempts.
- Filter by Reason: “Blocked by Static Filter Rule”.
- Verify that authentication attempts matching the rule appear in the list.
Identifying False Positives from Mideye Shield
Section titled “Identifying False Positives from Mideye Shield”- Filter by Reason: “Blocked by Automated Shield”.
- Review the blocked usernames and calling station IDs.
- If a legitimate user or IP address appears, consider adjusting the Mideye Shield thresholds or adding an ALLOW rule in Static Filter Rules.
Monitoring Block Volume Over Time
Section titled “Monitoring Block Volume Over Time”- Set the Start Date and End Date to define a reporting period.
- Review the total number of blocked attempts.
- Compare volumes across different time periods to identify trends or spikes in malicious activity.
Troubleshooting
Section titled “Troubleshooting”| Issue | Possible Cause | Resolution |
|---|---|---|
| No blocked attempts appear | No blocks occurred in the selected time range | Expand the date range or check that Mideye Shield and static filter rules are active |
| Legitimate user is blocked | Overly broad filter rule or low shield threshold | Review static filter rules and Mideye Shield configuration; create an ALLOW rule if needed |
| Username shows as empty | Request did not contain a username attribute | This can occur with malformed or probing RADIUS packets |
Related Pages
Section titled “Related Pages”- Authentication Logs — View all authentication events including successful and failed attempts
- Static Filter Rules — Create and manage rules that block authentication attempts by username or calling station ID
- Mideye Shield Configuration — Configure automated blocking thresholds and IP reputation scoring
- Auto-blocked IPs — View and manage IP addresses blocked by Mideye Shield