Shield (web application firewall)
Route your domain through Webforta Shield to filter traffic at the edge before it reaches your server.
Webforta Shield is a reverse-proxy web application firewall. You point your domain at Webforta with a DNS record; Shield then inspects each request against your rules at the edge and forwards clean traffic to your origin server. Nothing is intercepted until you change DNS, and Shield starts in monitor mode so you can see what it would block before enforcing.
Connecting a website
- Open a verified website and go to its Shield tab, then Connect to Shield. This issues a TLS certificate for your hostname under Webforta.
- Set your origin: enter your server's IP address (in cPanel, the Shared IP Address on the home screen). Webforta routes to that IP and asks for your domain name, so your server serves the site exactly as before - no extra DNS records or subdomains needed. Click Save and test origin to confirm Webforta can reach it.
- Add the DNS records Shield shows you - a CNAME that routes traffic, plus one _acme-challenge CNAME that lets the certificate be issued and renewed automatically. Each value has a copy button. Delete any old _acme-challenge TXT records first: they block the CNAME.
- Wait: the page checks your records by itself every few seconds (you can also click Check now), tells you exactly what is missing or wrong, and moves on as soon as each step completes. You get an email when the site is live.
- Shield starts in monitor mode. Watch the Overview and Activity tabs for a day or two, then click Start blocking threats. Fine-tune protections (attack filter, login brute-force protection, WordPress protection, under attack mode) on the Protection tab. If Shield flags something legitimate, click Not a threat - allow here on the Activity tab: that one rule stops applying to that page and everything else stays protected. Every Monday you get a weekly summary by email.
Rules
- Allow or block individual IPs and CIDR ranges (IPv4 and IPv6) or whole countries, with an always-allow list that bypasses other rules.
- Rate-limit abusive clients by requests per window, per IP or per IP-and-path.
- Block, challenge or allow specific paths; challenge known abusive crawlers.
- Edge hardening: force HTTPS, add HSTS and missing security headers, set clickjacking protection.
- Password-protect sensitive paths with HTTP Basic auth, and cache static assets at the edge.
Modes
- Monitor (default): logs what would be blocked without blocking anything - watch the event log here first.
- Enforce: applies your rules to live traffic.
- Off: forwards everything without filtering.
Under attack mode and browser checks
- Under attack mode makes every visitor opening a page pass a short browser check (about a second, no CAPTCHA) before reaching your site. It stops floods of automated requests; real browsers get through and are not asked again for a while.
- Page resources (CSS, JavaScript, images, fonts), robots.txt, sitemaps and /.well-known/ are not checked, so pages load normally. A visitor fetching an unusually large number of them a minute without having passed the check is checked too.
- These checks are precautions, not threats: they are counted under Browser checks on the Overview, with how many were passed, and do not appear in Threats or the Activity log. The same applies to the login-page check and to the check for IPs known from other sites. Requests that match an attack rule are still counted as threats.
- In Monitor mode nothing is shown to visitors, so under attack mode has no effect and nothing is counted.
- Automatic under attack mode (opt-in, Enforce mode only, on the Protection tab): Shield compares the current request rate with the site's normal rate every few minutes. When traffic reaches at least 8 times normal and at least 100 requests a minute, it switches under attack mode on and alerts you; it switches off by itself about an hour after traffic returns to normal. You can end it early from the Overview. Detection takes one to two checks (5 to 10 minutes).
Covering www and apex domains
Shield protects one hostname per connection. To cover both example.com and www.example.com, add each as its own website and connect each to Shield. Apex (root) domains can only be pointed at Webforta if your DNS provider supports CNAME flattening (for example Cloudflare DNS or Route 53 ALIAS); otherwise protect www and redirect the root to it.
More protection
- Network threat intelligence: IPs that attacked any Webforta-protected site in the last 24 hours must pass a browser check on yours too.
- Browser check: a short proof-of-work that real browsers solve automatically in about a second and scripts cannot fake.
- Admin area access: make /wp-admin (or any area) reachable only from your own IP addresses (Firewall rules tab).
- Purge cache (Settings tab) clears every cached file everywhere at once; add a custom message to the block page for visitors blocked by mistake.
Advanced: connect your own Cloudflare account
Separately from Shield, some deployments enable an optional feature to connect your own Cloudflare account with a scoped, read-only (or read-write) API token, to view and adjust edge settings on zones you control. It is off by default; ask your administrator if you need it.