Managed WAF on Cloudflare: rules written from your store's real traffic, not from a template
Putting Cloudflare in front protects nothing by itself: the origin is still reachable by IP, the default rules let through the scrapers that exhaust your database and block the crawlers that rank you. Lynx Perímetro is not a licence: it is the configuration and ongoing operation of the protection.
><
Lynx Perímetro · Managed security at the edge
Web application firewall, anti-bot and rate limiting, configured and operated by us on Cloudflare
0
changes to your store's code: everything is applied at the edge
Real
every rule comes from analysing your traffic, not from a template
Bots
abuse is stopped without penalising Google, Bing or your customers
Ongoing
periodic event review and tuning against false positives
What happens when "we already have Cloudflare"
Cloudflare is an excellent tool. Unconfigured, it is a sticker.
The origin is still open
If the server answers anyone who calls its IP directly, all the edge protection can be bypassed. It is the first thing we check and the one almost nobody closes.
Scrapers that exhaust the database
Thousands of requests per minute to the internal search or category filters from rotating IPs. The store slows down or goes down, and the host tells you to upgrade your plan.
The rule that blocked Google
A generic "block all bots" also stops search engine crawlers, the payment gateway or the comparison site that brings you sales. You notice weeks later, in your rankings.
The admin panel, in plain sight
Brute force against the admin login and customer registration, day in, day out. From the edge it is limited before it ever touches the server.
What Lynx Perímetro includes
Set-up and ongoing operation. Everything is applied at the edge, without modifying the application.
Set-up
DNS migration, certificate issuance and end-to-end encryption. Review of what remains exposed at the origin and blocking of direct access by IP, without which the rest of the protection can be bypassed.
Web application firewall rules
Custom rules written from the site's real traffic. Specific protection for the admin panel and sensitive endpoints: login, registration, cart, checkout, internal search, forms and webservice.
Bots and scrapers
Mitigation of automated traffic that exhausts server and database, with selective challenges by reputation, origin and behaviour. Tuning aims to stop abuse without penalising legitimate search engine crawlers, which is where default configurations fail.
Rate limiting
Per-route limits on login, forms, search and expensive requests, sized to contain brute force and artificial peaks without affecting normal use.
Headers and content policy
Security headers and content security policy deployed from the edge, without touching the application, with a report-only phase first so nothing breaks.
Caching and ongoing operation
Cache rules and absorption of peaks, including those caused by the abuse itself. Periodic event review, tuning against false positives and new patterns, and a report of blocked traffic and why.
Lynx Perímetro protects. Watching that the store is still up, with its origin certificate current and no new admin accounts, is done by Lynx Monitor: two services that complement each other and are contracted together within maintenance.
How it works
First measure, then block. Never the other way round.
01
Real traffic analysis
Before writing a rule we analyse server logs and Cloudflare events: who requests what, how often and from where. That is where scrapers and brute force show up, and also the bots that must not be touched.
- Access log
- Events
- Legitimate crawlers
02
Set-up
DNS migration if needed, certificates, full encryption to the origin and closing of direct IP access to the server.
- DNS
- Certificates
- Origin closed
03
Rules in observation mode
Rules are deployed first in log-only mode. False positives are reviewed with data and rules are activated once the pattern is clear.
- Log only
- False positives
- Activation
04
Ongoing operation
Periodic event review, tuning against new patterns and a report of what was blocked and why. Rules age; someone has to maintain them.
- Review
- Tuning
- Report
Who it is for
Sites already suffering automated traffic, or that cannot afford to find out mid-campaign.
-
Stores with unexplained load peaks
The store is slow at odd hours, the host suggests upgrading and nobody has looked at who generates those requests. It is usually automated traffic, and it is stopped at the edge.
-
Sites that have already had an incident
After a clean-up, closing the vector from the edge is the fastest way to make sure it stops working while the application is fixed.
-
B2B sites with exposed forms and catalogues
Customer registration, sign-up forms and internal search are the usual targets of spam and price scraping. They are protected route by route.
Services that go with Lynx Perímetro
The edge protects; the application is maintained; someone keeps watch.
Lynx Monitor
Monitoring from two vantage points, origin certificate behind Cloudflare, versions and new admin accounts, with our team receiving the alert.
See monitoringLynx Auditoría Web
What the edge cannot cover (vulnerable modules, public backups, forgotten accounts) is found in the security audit and fixed in the application.
See the auditLynx Rescate
If the anomalous traffic turns out to be an active compromise, incident response contains, cleans and documents.
See incident responseFrequently asked questions
Do I need a paid Cloudflare plan?
Will you block Google or my payment gateway?
What about the LaLiga blocks at weekends?
What do I receive each month?
What if I would rather you did not touch my Cloudflare?
First we look at your traffic
Tell us which platform you use and whether you are already behind Cloudflare. With the server logs we can tell you what is going on and which rules are needed.