Hoppa till innehåll

WAF & Firewall

Det här innehållet är inte tillgängligt på ditt språk än.

WAF & Firewall looks at each request before it reaches your app. Managed rules catch known attacks in the path, the query and the body: SQL injection, cross-site scripting, path traversal, command injection and exploits of published vulnerabilities. Your own rules match on path, method, country, network and the signals Qlyne already has, and decide to block, challenge or skip the other rules. IP lists block or trust an address or a range, and the trusted ones skip every other rule. A rate limit caps how many requests a visitor can make per minute on a route, and answers the extra ones with 429.

Available with the Qlyne proxy and the Cloudflare Worker; the rate limit also with Next.js. Install the connector from its guide first. Everything on this page is then set in the dashboard, with no change to your app.

In the site menu, WAF & Firewall has three items:

  • Overview: what was blocked, and what would have been while you observe.
  • IP rules: the lists of blocked and trusted addresses.
  • Configuration: managed rules, rate limits and your rules, under “Advanced”.

After you save, the connector picks up the change within a minute.

On Free, IP lists and rate limits work in full and the managed rules observe. Blocking with the managed rules, and your own rules, are Pro. The plans are compared in Plans.

Start in observe mode. With the connector on “Observe only” (under Connector), nothing is refused: each match shows up in Events as “Would block by managed rules”, “Would block by your rule”, “Would block by IP” or “Would rate limit”. Your app gets the same in the Qlyne-Rule header, like would_waf_block=sqli. When only attacks show up there, switch the connector to “Enforce”.

At the top of Configuration, the level sets the managed rules for you:

LevelManaged rules
BasicObserve only, all five attack groups
BalancedBlock, all five attack groups
AggressiveBlock, all five attack groups

The level never touches your IP lists, your rules or your rate limits. The same selector also sets what Tor exit nodes and shared reputation get, explained in Bot Management.

Under Configuration, “Managed rules”, “What they do” has three options: “Off”, “Observe only” (the default for every site) and “Block”. “Attacks to look for” picks the groups:

  • SQL injection: UNION SELECT, 1=1 conditions, stacked statements, time delays, schema reads.
  • Cross-site scripting: script tags, event handlers, javascript: links, iframes.
  • Path traversal: ../, system files, null bytes.
  • Command injection: $(…) with system commands, chained curl or bash, Log4Shell lookups.
  • Known CVE exploits: requests that target published vulnerabilities, like Spring4Shell.

The rules look at the path, the query string and the body, after decoding them twice (for whoever encodes twice to slip through) and without SQL comments. Which bodies are read depends on the connector:

ConnectorBodies read, up to 16 KB
Qlyne proxyform, JSON, file uploads (multipart) and XML, with or without a declared size
Cloudflare Workerform and JSON, only with a declared size

Events shows each match with its attack group, like “Managed rules, sqli”. Blocking needs Pro and the connector on “Enforce”; on Free the rules keep observing.

A page that sends HTML or code on purpose, like a rich text editor, goes in “Routes the managed rules skip”. * at the end covers everything below the route. The managed rules run after your rules, so a rule that lets a request through skips them too.

Under Configuration, “Your rules”, click “Add rule”. A rule has a name, a list of conditions that must all hold (“When”), and what it does:

  • Block: 403.
  • Challenge: the challenge page from Bot Management.
  • Let through, skip the other rules: goes to your app with no other rule applied, the waiting room included.
  • Only log it: shows up in Events as “Matched a log rule” and changes nothing.

Each condition is a field, a comparison and values:

FieldComparisonsExample
Pathstarts with, matches, contains, is any of/login
Hostis any of, is none ofstaging.shop.example
Methodis any of, is none ofPOST
Countryis any of, is none ofBR, PT
ASN (network)is any of, is none ofAS14061, AS16509
IP addressis any of, is none of203.0.113.0/24
User agentcontains, does not contain, is emptypython-requests
Verified search botis yes, is no
TLS fingerprint (JA4)starts with, is any of, is none oft13d1812h1

For “or”, put several values in one condition (BR, PT) or write two rules. Rules run in order, after blocked addresses and the scanner trap. The first one that blocks, challenges or lets through decides; “Only log it” never stops the next rule. Move rules with the arrows and switch one off without deleting it. “Done” closes the window; the rules apply after you save the page.

Examples:

  • Block the login for hosting networks: Path starts with /login, and ASN is any of AS14061, AS16509.
  • Challenge the checkout outside your countries: Path matches /checkout*, and Country is none of BR, PT.
  • Block API calls with no user agent: Path starts with /api/, and User agent is empty.

Start a new rule with “Only log it”, check Events for a day, then make it block.

Country and network come from Cloudflare on the Worker. On the Qlyne proxy they come from a local GeoIP base: download ip2asn-v4.tsv.gz and ip2asn-v6.tsv.gz from iptoasn.com, unzip both into a folder, mount it in the container and point QLYNE_GEOIP_DIR at it. The proxy loads the base when it starts and logs qlyne: geoip database loaded. The TLS fingerprint needs HTTPS in the proxy itself (see the proxy guide), or Cloudflare Bot Management on the Worker.

Under IP rules, type an address or a range (IPv4 or IPv6, like 203.0.113.7 or 203.0.113.0/24), an optional note, and pick “Block” or “Trust”. In Events, each row also has “Block IP” and “Trust IP”; the entry gets the note “From Events”.

  • Blocked: refused with 403 before any other rule. It stays blocked until you remove it.
  • Trusted: goes to your site with no rule applied, so it skips the challenge, the rate limits and the waiting room. Use it for your office, uptime monitors and partners calling your API.

Each list holds up to 500 addresses, and an address lives in one list only. Each entry shows its note, the date and who added it. In observe mode, blocked addresses are only counted; trusted ones already skip every rule.

Under Configuration, “Rate limits”, click “Add limit” and fill in:

  • Route: like /api/*. * at the end covers everything below it.
  • Limit: Strict (10 per minute), Normal (60) or Loose (300), in a 60-second window.
  • Count by: IP address (an IPv6 visitor counts by its /64), a header (like X-API-Key) or a cookie (like session_id).

Count per header or cookie on an API, or where many people share one address (mobile carriers, offices). Requests without that header or cookie count per IP. One IP never goes above 10 times the limit, so a new key on every request does not get around it. A site can have up to 20 limits.

Where the count lives depends on the connector. The Qlyne proxy counts in its own memory and keeps a header or cookie value only as a hash. The Worker uses Cloudflare’s rate limiting, which needs the connector deployed with Wrangler and the wrangler.toml from the dashboard (see Install the connector). With the dashboard install, rate limits let every request through. On Next.js, the Qlyne server adds up every instance of your app (see the Next.js guide).

Static files (scripts, styles, images, fonts) count too.

  • Blocked by an IP list, your rule or the managed rules: in a browser, 403 with the page “Access blocked”, which says “This site refused access from your connection. If you think this is a mistake, contact the site.” An API call gets 403 with {"code": "ACCESS_BLOCKED"}. Neither says which rule refused it.
  • Over a rate limit: 429 with Retry-After: 60. In a browser, the page “Too many requests” says “Wait 60 s and try again. The page reloads on its own.” An API call gets {"code": "RATE_LIMITED"}.
  • A rule with “Challenge”: the challenge page.
  • A trusted address: no page; the request goes to your app.
  • In observe mode: nothing changes for the visitor.

These pages set no cookie.

As of 2026-10-18:

  • On the Worker, the managed rules read form and JSON bodies with a declared size only. File uploads, XML and bodies sent in chunks are not read there.
  • The managed rules skip any body over 16 KB, on every connector.
  • On the Qlyne proxy, each instance counts its own rate limits. With three proxies behind a load balancer, a visitor can get up to three times the limit.
  • Rate limits use the three fixed presets and a 60-second window; you cannot type your own number.
  • On the Qlyne proxy, Country and ASN conditions need the GeoIP base. Without it they never match, and the dashboard can’t tell whether your proxy has the GeoIP database.
  • An IP block has no expiry; remove the entry to lift it.
  • A site holds up to 25 rules, 10 conditions per rule and 100 values per condition.

Do the managed rules replace validating input in my app?

Section titled “Do the managed rules replace validating input in my app?”

No. They catch the common, automated attacks. Keep validating input and using parameterized queries in your app.

IP lists and rate limits, in full. The managed rules observe and report what they would block. Blocking with them, and your own rules, need Pro.

Within a minute after you save, on every connector.

Does a trusted address skip the waiting room too?

Section titled “Does a trusted address skip the waiting room too?”

Yes. A trusted address skips every rule, the waiting room and the challenge included.

Yes. Managed rules, your rules, IP lists and rate limits are all part of the rules file in rules as code. The IP lists can also be changed from an AI assistant through MCP.

A real visitor was blocked by the managed rules

Section titled “A real visitor was blocked by the managed rules”

Open Events and find the request: the row shows “Blocked by managed rules” and the attack group. If the page sends HTML or code on purpose, add its route to “Routes the managed rules skip”. If one group keeps catching your own traffic, untick it under “Attacks to look for”. While you look into it, set “What they do” to “Observe only”: the matches keep showing up, and nobody is refused.

The dashboard runs on Qlyne’s servers, so you can still log in. Open Events and check what blocked you. An entry in IP rules comes off with “Remove”. Your rule can be switched off in its row. For the scanner trap, see Bot Management. Then add your address under IP rules as trusted, so no rule applies to it again. The connector picks it up within a minute.

Check the route first: a limit on /* also counts every image, script and style a page loads, so Strict runs out on the first visit. Put the limit on the routes bots go after, like /api/* or /login. If shoppers share one address (a mobile carrier, an office), count by the session cookie instead of the IP. Then move to Normal or Loose. In observe mode, “Would rate limit” in Events shows who would have been stopped before anyone is.