Link11 WAAP
v2.16
v2.16
  • Link11 WAAP v2.16 Portal
  • Introduction
  • Getting Started
  • Setup Checklists
  • Marketplace onboarding
  • Console UI Walkthrough
    • General UI flow
    • Traffic
      • Traffic Concepts
      • Dashboard
      • View Log
    • Security
      • Security Section Concepts
      • Dynamic Rules
      • Quarantined
      • Profiles
        • Profile Concepts
        • Profiles
        • ACL Policies
        • WAF/IPS Policies
        • Custom Signature
      • Args Analysis
      • Tag Rules
      • Rate Limiting
      • Cloud Functions
    • Settings
      • Web Proxy
      • Backend Services
      • Error Pages
      • SSL
      • DNS
      • Planet Overview
      • Account
  • Using the product
    • Best Practices
      • Saving and Publishing Your Changes
      • Enabling Passive Challenges
      • Using the Reblaze Query Box
      • Understanding and Diagnosing Traffic Issues
    • How Do I...
      • Ban, Unban, and Whitelist Traffic Sources
      • Bypass Rate Limits for Loadtesting
      • Control Caching Behavior
      • Filter by Content
      • Quickly Block an Attacker
      • Secure Traffic from a Third-Party Page
      • Set Rate Limits and Exemptions
      • Set up SIEM/SOC integration
      • Video Tutorials
        • DNS Training
    • API
      • Reblaze REST API
      • Mobile SDK
  • Reference Information
    • Access log-structure
    • Acronyms
    • Deployment Terminology
    • Hostile Bot Detection / RCSI
      • Environmental detection and browser verification
      • Client authentication
      • Biometric behavioral verification
    • HTTP Response Codes
    • Pattern Matching Syntax
    • Signatures
    • Tags
    • TTL Expression Syntax
  • Support
Powered by GitBook
On this page

Was this helpful?

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

Quickly Block an Attacker

PreviousFilter by ContentNextSecure Traffic from a Third-Party Page

Last updated 3 years ago

Was this helpful?

Sometimes can make it difficult to find and block a specific attacker.

For example, let's say an ACL Policy (named "Allow US Traffic") for an ecommerce store allows all traffic originating from the United States. But then an attacker, using an IP within the US, begins to scrape prices and other data from the store.

If an ACL Policy were added to Deny that IP address, it wouldn't work. The hierarchy of ACL Policy enforcement means that the "Allow US Traffic" Policy will take precedence, and the 'Deny' Policy for that IP will never be invoked.

One way to quickly solve this problem is to add an ACL Policy with a name ending in a suffix of "XDeny" (for example, "Block US Scraper XDeny"). As was discussed in the "" section, that suffix moves the ACL Policy to the top of the hierarchy.

Therefore, that ACL Policy will be invoked and enforced for that IP address, and the attacking IP will be blocked, before the "Allow US Traffic" Policy has a chance to grant it access.

Long-term use of this capability is not optimal; using it too frequently can tend to create a collection of ACL policies that is messy, confusing, and difficult to manage. The optimal approach is to use it as a tool for solving a specific problem temporarily, while a robust set of ACL Policies are constructed and tested that will solve the problem correctly.

ACL Policies
Special ACLs