DDoS & Web Application Firewall (WAF)

Why small sites go offline

Most Lao business sites we see sit behind one ISP link with the web server on a public IP. On a quiet day that works. When a cheap booter floods the link, the pipe fills before any on-prem box can react. Old plugins, open admin paths and direct-to-origin traffic give bots an easy way in, and one weak form can deface the homepage.

What we put in front of your site

For most offices with one or two sites we use a cloud scrubbing and reverse-proxy layer in front, with the existing firewall as the second layer. Floods are absorbed upstream instead of filling the office link. Our firewall work at the origin allows only proxy addresses. The WAF then checks requests for attack patterns, bad bots and login abuse.

• WAF rules for common web attacks, plus virtual patching while a plugin waits for update.
• Bot scoring, challenge pages and login protection that slows credential stuffing.
• Per-URL rate limits for search, forms and login pages.
• TLS with HTTPS redirect, and an origin locked to accept only proxy traffic.
• Alerts into monitoring so floods reach an engineer, not an unread inbox.

Tuning without blocking real visitors

Strict rules block real visitors, so we start log-only for a few days, allowlist payments and booking engines, then switch blocking on. For most shops under 50 staff we keep two login policies: staff portals get strict limits, public logins get slower limits with challenges, because staff can retry while guests simply leave.

What happens during an attack

When sensors trip, traffic shifts to scrubbing, suspects face challenges, and the origin stays reachable through the proxy. Afterward you get a short report: what arrived, what was blocked, and what to adjust. Send us your domain name and a screenshot of the last outage message on WhatsApp, and we will say where protection should sit.