Link11 WAAP
v5
v5
  • Link11 WAAP Documentation
  • Release Notes
  • Known Issues
  • User Guide
    • Introduction to Link11 WAAP
  • How Link11 WAAP Works
    • Traffic Filtering Process
    • Traffic Reporting and Analytics
    • Policy Mapping and Traffic Routing
    • Tagging
    • UI Overview and Common Elements
  • Console UI Walkthrough
    • Analytics
      • Dashboard
      • Events Log
    • Security
      • Global Filters
      • Flow Control Policies
      • Security Policies
      • Rate Limit Rules
      • ACL Profiles
      • Actions
      • Dynamic Rules
      • Quarantined
      • Content Filter
        • Content Filter Profiles
        • Content Filter Rules
    • Sites
      • Server Groups
      • Proxy Templates
      • Mobile Application Groups
      • Backend Services
      • Edge Functions
      • DNS Records
      • SSL
        • Load Balancers
        • Certificates
    • System
      • Interactive Challenge
      • SSO Configuration
      • Purge CDN Cache
      • Users Management
      • Security Alerts
      • Log Exporters
      • Version Control
      • System DB
      • Publish Changes
    • Account
  • Using the product
    • Best Practices
      • Saving and Publishing Your Changes
      • Enabling Passive Challenges
      • Understanding and Diagnosing Traffic Issues
    • How Do I...
      • Authenticate mobile app users
      • Ban, unban, and allowlist traffic sources
      • Bypass Link11 WAAP for loadtesting or other purposes
      • Configure a new path/section of a site
      • Control caching behavior
      • Enable GraphQL traffic
      • Enable mTLS (mutual TLS)
      • Protect sensitive information in logs and analytics
      • Quickly block an attacker
      • Redirect or block HTTP traffic
      • Run custom code
      • Set rate limits and exemptions
      • Stream event data to a SIEM solution or other destination
    • The Link11 WAAP API
      • Overview
      • Internal data structures
      • Using Swagger UI
      • Using curl
  • Reference Information
    • Acronyms
    • API
      • API access to traffic data
      • Types of namespaces
      • Namespace reference
        • ACL Profiles
        • Actions
        • Backend Services
        • Certificates
        • Configs
        • Content Filter Profiles
        • Content Filter Rules
        • Data queries
        • Dynamic Rules
        • Edge Functions
        • Flow Control Policies
        • Global Filters
        • Load Balancers
        • Log Exporters
        • Mobile Application Groups
        • Planets
        • Proxy Templates
        • Rate Limit Rules
        • Security Alerts
        • Security Policies
        • Server Groups
        • Tags
        • Tools
        • Users
    • Hostile Bot Detection / LWCSI
      • Environmental detection and browser verification
      • Client authentication
      • Biometric behavioral verification
    • HTTP Response Codes
    • Log Exporter Output
    • Pattern Matching Syntax
    • Query Filter Syntax and Best Practices
  • Support
Powered by GitBook
On this page
  • Using a Global Filter
  • Consider a dedicated Global Filter for long-term management

Was this helpful?

Export as PDF
  1. Using the product
  2. How Do I...

Quickly block an attacker

PreviousProtect sensitive information in logs and analyticsNextRedirect or block HTTP traffic

Last updated 4 months ago

Was this helpful?

Sometimes situations will arise where an attacker needs to be blocked temporarily, while the security posture is being reconfigured. Since the hostile traffic is not being filtered, admins recognize that their security posture needs to be strengthened, but they need some time to analyze the situation. Meanwhile, the attacker should be blocked.

It might seem that admins should merely add the for the attacker's IP (e.g., ip:82-64-131-193) to the Enforce Deny column in the applicable . This can work (as long as the attacker is consistently using the same IP), but it's not necessarily the best approach.

Using a Global Filter

The better approach is usually to create a , based upon criteria that will match the attacker (but will not match any other traffic source), with an to block the matching requests.

Here's why this is usually the optimal choice:

  • While both approaches can be done when the attacker is using a single IP (or a set of IPs), the second one also supports situations where the attacker is rotating IPs, and therefore needs to be identified with a combination of characteristics.

  • The ACL Profile will limit the blocking to specific paths/URLs (those defined in the associated with it, and used within one or more ). The Global Filter will block the attacker's activity globally, which is usually more desirable.

  • The Global Filter is more efficient during processing, because the hostile requests are blocked earlier in the .

  • The ACL Profile approach can result in the long-term accumulation of "special cases" within the Profiles, if admins are not diligent about cleaning them up when they're no longer needed. This situation is not ideal, because it can be messy and difficult to manage. The Global Filter approach makes it easier to also consists in creating special cases, but they are more visible and thus, easier to find and purge when no longer necessary.

Consider a dedicated Global Filter for long-term management

Instead of creating and discarding one-off Global Filters, it's often better to maintain a dedicated Global Filter for manually blocking attackers. As traffic sources need to be blocked (or unblocked), admins can just add (or remove) matching criteria.

This creates a single location for administering these special cases. Admins can easily monitor the current list of manual interventions, and purge them as they become obsolete.

ACL Profile
Global Filter
Action
Security Policies
Server Groups
traffic filtering process
system tag