> ## Documentation Index
> Fetch the complete documentation index at: https://docs.recon44.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Block Attacks Automatically with Recon44's WAF

> Enable active blocking to stop SQLi, XSS, brute force, RCE, and DDoS attacks at the edge before they ever reach your origin server.

Recon44's WAF inspects every incoming request against 200+ OWASP Core Rule Set patterns and, on paid plans, blocks matching requests at the edge in under 50ms. This guide explains how to upgrade from read-only mode to active blocking, how to manage individual IPs, and how brute force and DDoS protection work automatically once active blocking is enabled.

## Read-only WAF vs. active blocking

On the Free plan, the WAF runs in **read-only mode**: it detects and logs attacks but does not block them. This gives you visibility into what is hitting your site without any risk of false positives interrupting legitimate traffic.

When you upgrade to Pro or higher, you switch to **active blocking**: matching requests are dropped at the edge before they reach your origin server.

<CardGroup cols={2}>
  <Card title="Free — read-only" icon="eye">
    Attacks are detected and recorded in the threat feed, but all traffic passes through to your origin.
  </Card>

  <Card title="Pro+ — active blocking" icon="shield-halved">
    Malicious requests are blocked at the edge in under 50ms. No traffic matching attack patterns reaches your server.
  </Card>
</CardGroup>

## Enable active blocking

<Steps>
  <Step title="Upgrade your plan">
    Go to **Settings → Billing** in the dashboard and select the **Pro** plan or higher. Active blocking is available on Pro, Business, Scale, and Enterprise.
  </Step>

  <Step title="Open WAF settings">
    Navigate to **Security → WAF** from the left sidebar.
  </Step>

  <Step title="Switch from monitor to block">
    Find the **Mode** toggle at the top of the WAF page. Change it from **Monitor** to **Block**. The toggle turns red to confirm active blocking is on.
  </Step>

  <Step title="Confirm the change">
    A confirmation dialog lists the attack categories that will now be blocked (SQLi, XSS, RCE, path traversal, SSTI, and more). Click **Enable blocking** to apply.
  </Step>

  <Step title="Verify in the threat feed">
    Go to **Dashboard → Threat Feed**. New attack events will now show a **Blocked** badge instead of **Detected**.
  </Step>
</Steps>

<Note>
  Changes take effect within 30 seconds across all edge nodes. You do not need to update your DNS record or restart anything.
</Note>

## Manually block or whitelist an IP

You can override Recon44's automated decisions for any individual IP address at any time.

<Steps>
  <Step title="Find the IP in the threat feed">
    Go to **Dashboard → Threat Feed** and locate the event from the IP you want to manage. Click the IP address to open the IP detail panel.
  </Step>

  <Step title="Choose an action">
    In the IP detail panel, click **Block IP** to add it to your blocklist immediately, or click **Whitelist IP** to ensure Recon44 never blocks it regardless of its behavior.
  </Step>

  <Step title="Set a duration (optional)">
    By default, manual blocks are permanent. Use the **Duration** dropdown to set a temporary block of 1 hour, 24 hours, or 7 days if you prefer.
  </Step>

  <Step title="Confirm">
    Click **Apply**. The rule takes effect within seconds and appears under **Security → IP Rules**.
  </Step>
</Steps>

<Tip>
  Before blocking a large IP range, check the threat feed for any IPs you recognize as legitimate customers or partners and whitelist them first. Whitelisted IPs always bypass blocking rules, including geo and ASN blocks.
</Tip>

## How brute force protection works

Recon44 monitors login request patterns automatically. When it detects a suspicious number of authentication attempts from a single IP — for example, repeated failed logins in a short window — it takes the following actions in sequence:

1. **Rate limiting**: The source IP is throttled, slowing the attack without immediately blocking it.
2. **Blocklist**: If the pattern continues, the IP is added to your blocklist and all further requests from that IP are dropped.
3. **Alert** (Pro+ for email, Business+ for Telegram and SMS): You receive a notification that a brute force attempt was detected and blocked.

You can review brute force events under **Security → Brute Force Log** and adjust rate limit thresholds under **Security → WAF → Rate Limits**.

## How DDoS mitigation works

DDoS mitigation runs automatically for all plans, including Free, because your traffic flows through Cloudflare's global network the moment you add the Recon44 CNAME record. There is nothing to configure.

Volumetric attacks are absorbed at the edge before reaching your origin. The threat feed shows DDoS events in real time so you can monitor the attack as it is being mitigated.

<Info>
  DDoS mitigation is infrastructure-level and operates independently of your WAF mode setting. It is active even when the WAF is in read-only mode.
</Info>

## Tuning: whitelist legitimate IPs

If active blocking causes false positives — for example, a security scanner you own or a partner's monitoring service gets blocked — whitelist those IPs so they are never affected by WAF or rate limit rules.

<Steps>
  <Step title="Go to IP Rules">
    Navigate to **Security → IP Rules** in the dashboard.
  </Step>

  <Step title="Add a whitelist entry">
    Click **Add rule**, enter the IP address or CIDR range, and set the action to **Whitelist**.
  </Step>

  <Step title="Add a label">
    Enter a description (for example, "Uptime Robot monitoring") so you can identify the rule later.
  </Step>

  <Step title="Save">
    Click **Save rule**. The whitelist takes effect within 30 seconds.
  </Step>
</Steps>

<Warning>
  Be cautious when whitelisting CIDR ranges. A range that is too broad may inadvertently allow malicious traffic from the same subnet.
</Warning>

## Attack types caught by the WAF

<AccordionGroup>
  <Accordion title="SQL Injection (SQLi)">
    Requests containing SQL syntax designed to manipulate your database queries — matched against dozens of payload variations including comment-based, union-based, and blind injection patterns.
  </Accordion>

  <Accordion title="Cross-Site Scripting (XSS)">
    Attempts to inject client-side scripts into your pages, covering reflected, stored, and DOM-based XSS payloads.
  </Accordion>

  <Accordion title="Remote Code Execution (RCE)">
    Requests that attempt to execute system commands through vulnerable endpoints, including shell injection and deserialization exploits.
  </Accordion>

  <Accordion title="Path traversal">
    Attempts to access files outside the web root using sequences like `../`, catching both encoded and double-encoded variants.
  </Accordion>

  <Accordion title="Server-Side Template Injection (SSTI)">
    Payloads that target template engines such as Jinja2, Twig, and Freemarker to execute server-side code.
  </Accordion>

  <Accordion title="Scanners and bots">
    Automated scanning tools and vulnerability probers are fingerprinted and blocked based on behavior and known signatures.
  </Accordion>
</AccordionGroup>
