DDoS Protection and WAF Service in Romania

Network layer and application layer

Two layers solve two different problems. Network filtering absorbs volume: SYN floods, UDP amplification and other L3/L4 attacks that would saturate the link. It is part of our network and you do not have to ask for it. The WAF works on the HTTP request itself: SQL injection, XSS, path traversal, abused forms, brute-force logins and expensive queries that exhaust a database. A classic firewall never reads the request, so it cannot tell a normal query from one built to extract data.

• L3/L4: volumetric floods, SYN floods and amplification
• L7: injection, XSS, form abuse and login brute force
• Adaptive rate limits per IP, session and route
• Geo and ASN rules where real traffic justifies them
• Caching and queue pages for legitimate traffic peaks

Bots, virtual patches and machine-learning detection

A large part of web traffic is automated. Some of it is useful, such as search crawlers; some is scraping of content and prices, or credential stuffing. Attackers use LLM agents that rewrite a payload until it slips past a rule, so fixed signatures are no longer enough. On our side we use behavioural bot detection, machine learning, TLS fingerprinting (JA3/JA4), rate limits that tighten on their own when traffic turns abnormal, and virtual patches in the WAF for CVEs exploited within hours of publication, until the fixed version is installed.

Tuning rules without blocking customers

A WAF switched straight to blocking breaks file uploads, content editors and integrations. We start in monitoring mode, collect your application's real requests, exclude what is legitimate and only then enable blocking. Tuning is drawn from the hours included in your plan (1 h on cPanel from Advanced up, 1–8 h on VPS, 5–10 h on dedicated, 10 h on GPU) and requested from the client panel. After each larger release we review the ruleset, because a new route means a new traffic pattern and new false positives. Hours do not carry over, and extra hours are billed separately.

CDN WAF at the edge, WAF at the origin

Many sites already sit behind a CDN with a WAF, and that covers the public layer well. What it cannot cover is the origin: if an attacker finds your server's IP address, or an administrative port is open, the edge is bypassed. We therefore filter in our own network and on the server itself, and the setup works alongside a CDN if you use one. Rules are written per route: public pages stay open, while APIs, price lists and internal search get tighter limits.

How we work

1. Request from the panel

   Ask for WAF setup in the DevOps Services section of the panel, naming your domains, sensitive integrations and the window in which we may change rules.

2. Watch real traffic

   We run the WAF in monitoring mode, measure legitimate requests, spot bots and expensive routes, then propose the ruleset and the rate limits.

3. Switch to blocking

   Blocking is enabled gradually, route by route, with exceptions for known integrations. Together we test forms, payments and customer areas.

4. Handover and ongoing tuning

   You receive the rule documentation, alerts and a traffic dashboard. We return after big releases or when a CVE starts being exploited in the wild.

Use cases

Technology stack

• ModSecurity
• OWASP CRS
• Coraza
• CrowdSec
• Nginx
• HAProxy
• nftables
• Grafana

Frequently asked questions

• What is the difference between DDoS mitigation and a WAF?

  DDoS mitigation absorbs volume at the network layer so the link and servers stay reachable. A WAF reads each HTTP request and blocks injection, XSS, form abuse and automated abuse of the application. They address different attacks, and a site facing the internet normally needs both.

• Do I need a WAF if I already use Cloudflare?

  A CDN with a WAF covers the public edge well. The origin still needs its own protection: closed administrative ports, filtering in the network and rules on the server. Otherwise an attacker who finds your IP address skips the edge entirely. We protect both layers and work next to a CDN.

• How do I block AI crawlers without losing Google?

  Declare your policy in robots.txt and llms.txt, then enforce it per user agent: search crawlers stay allowed and verified against their networks, training crawlers are refused at the WAF. Bots that lie about their identity are caught by behaviour and TLS fingerprints.

• Can a WAF virtual-patch a CVE before I update the application?

  Yes, for many web-facing flaws a targeted rule blocks the exploit pattern until you can install the fixed version. It buys time and is not a replacement for the update. We use it when a patch needs testing or depends on a vendor release.

• Which attacks does a WAF block?

  SQL injection, XSS, path traversal, unsafe deserialisation, dangerous file uploads, brute force on logins, form abuse and application-layer DDoS. It does not replace patching: a virtual rule holds only until you update the vulnerable component, so we track both.