SeenSecure Help
EspañolEnglishDeutschFrançais

Firewall Incidents

Every time the firewall blocks a request, it generates a unique incident ID. From here you can search, analyze, and manage all recorded incidents.

What are Incidents?

Every time the SeenSecure firewall blocks an incoming request — whether due to SQL injection, XSS, LFI, geoblocking, blacklist, rate limiting, TOR, or any other rule — a unique incident ID is automatically generated. This ID is an alphanumeric identifier that allows you to locate the block precisely in the incident log.

🔑 Why are incident IDs important? When a user reports "I was blocked with ID X", the admin can search that ID and see exactly which request was blocked, from which IP, at what time, and by which rule. This greatly speeds up false positive analysis and incident response.

📋 Data contained in each incident

  • Incident ID: Unique identifier of the block.
  • IP Address: IP from which the blocked request originated.
  • Attack type: Block category (SQLi, XSS, LFI, Geo, Blacklist, etc.).
  • Reason: Detailed reason for the block (detected payload, triggered rule, etc.).
  • URI: The full URL that was blocked.
  • User Agent: The browser or HTTP client that made the request.
  • Date: Exact date and time of the block.

🗂️ Incident Categories & Filters

Not every block is the same, and not every admin wants the same level of detail. That's why SeenSecure groups every block into one of five categories, letting you decide which ones should generate a full incident (with IP, user, reason, and date stored in the table) and which should stay only in the general traffic log, without taking up space in your incidents list.

💡 Practical example: if your site receives heavy traffic from harmless bots that the firewall already blocks routinely, you can uncheck the "Firewall" category so it doesn't "flood" your incidents table with noise — while keeping "Login" enabled to keep seeing every brute-force attempt against your users in full detail, since those do deserve manual review.

🔑 Login (brute force)

Repeated failed password attempts against the same user. Includes the targeted account's name, useful for alerting the admin which accounts are being actively attacked.

🚦 Rate Limiting

Blocks due to too many requests in a short time, whether from an authenticated user or an anonymous IP. Flags clients or bots overwhelming your server with excessive requests.

🌊 Flood Events

Logged when your site enters or exits resilience mode against massive traffic — one event per transition, never one per individual request, so the table doesn't get overwhelmed during a real traffic spike.

🚨 Escalation / Flagged IP

Repeat-offender IPs attacking in multiple waves and ending up blocked for hours, or that were already flagged as blocked. This is the category that best signals a persistent attacker rather than an isolated attempt.

🛡️ Firewall (remaining protections)

The "catch-all": attacks blocked by the rest of the firewall rules, such as anti-injection (SQLi/XSS), security headers, geo-blocking, TOR exit nodes, blacklisted IPs, or detected bots. Usually the highest-volume category.

🔎 Quick filters in the table

Besides the exact-ID search, the incidents table includes quick filter buttons so you don't have to review all 50 records one by one: All (unfiltered), Users (shows only incidents with an associated username, ideal for spotting attacks against specific accounts), Login (only brute-force blocks), and Events (only flood mode transitions). You can also type a username into the table's search field to see only that account's incidents — very useful when a user reports repeated login problems and you want to review their full history without noise from other accounts.

📊 Incident Statistics

The statistics panel gives you a quick view of your site's security status. It updates in real time and reflects accumulated data since SeenSecure was installed.

Total Incidents

What it means: The total number of blocked requests since the firewall has been active. A high number does not necessarily indicate a problem — it may mean the firewall is doing its job. However, sudden growth may indicate an ongoing attack.

Today's Incidents

What it means: Blocks that occurred in the last 24 hours. Useful for detecting recent malicious activity spikes. If you see an unusually high number, review the incidents table to identify the pattern.

Unique Blocked IPs

What it means: Number of distinct IP addresses that have been blocked at least once. If this number is much lower than the total incidents, it means there are repeat offender IPs attacking repeatedly.

💡 Interpretation: Use statistics to evaluate trends. If today's incidents are consistently high for several days, consider reviewing your geoblocking or rate limiting configuration.

📋 Recent Incidents Table

The table displays the last 50 recorded incidents, sorted from newest to oldest. Each row represents a block with all available information so you can analyze attack patterns.

📌 Table columns

  • ID: Unique incident identifier. Click to view full details.
  • IP: IP address of the blocked attacker or requester.
  • Type: Attack category (SQLi, XSS, LFI, RFI, Geo, Rate Limit, etc.).
  • Reason: Detailed description of why the request was blocked.
  • URI: The exact URL that was blocked.
  • User Agent: HTTP client identification.
  • Date: Exact time of the block.

🔎 How to identify attack patterns

Same IP, same type

An IP generating multiple incidents of the same type (e.g., SQLi) indicates a targeted automated attack. Consider permanently blocking that IP.

Same URI, multiple IPs

Many different IPs attacking the same URL suggests a distributed attack (DDoS) or mass scanning. Enable rate limiting if it is not already active.

Multiple types, same IP

An attacker testing different vectors (SQLi, XSS, LFI) against your site. Sign of an experienced attacker. Block the IP and monitor.

⚡ Use in security audits: The incidents table is ideal for periodic audits. Review attack patterns weekly to adjust firewall settings and improve your security posture.

🗑️ Clear All Incidents

The 🗑️ Empty List button removes all incident records from the database. This operation is safe: it only deletes historical records and does not affect firewall operation or active rules.

⚠️ Confirmation required: When you click "Empty List", a confirmation modal will appear asking if you are sure. This prevents accidental deletion. Deleted data cannot be recovered.

When should you clear incidents?

  • Before an audit: To start with a clean slate and measure new incidents accurately.
  • After a massive attack: Once analyzed and mitigated, clearing helps detect new threats without historical noise.
  • Periodically: Some admins prefer to keep the history clean monthly. The firewall continues to work normally.
🔄 Incidents continue to be logged: Clearing incidents does not disable logging. The firewall will continue to generate new incident IDs for every future block.

🧹 Automatic pruning vs. manual clearing

Besides the "Empty List" button (which erases everything at once), SeenSecure periodically prunes the oldest incidents so the table doesn't grow without limit or slow down your admin panel. Next to "Empty List" you'll find the "Prune >30 days" button, which deletes only records older than that retention window and leaves recent ones intact — unlike "Empty List", which removes absolutely everything regardless of date.

⭐ Difference between plans: on the FREE plan the default retention window is 30 days. With SeenSecure PRO that window extends up to 365 days, letting you keep and analyze a full year of incident history — useful for annual audits, spotting seasonal attack patterns, or justifying security decisions to clients or auditors.