How does an Airlock WAF dashboard organize traffic visibility, and what's the role of "mappings"?
Airlock WAF (Swiss product) shows real-time stats on requests, attacks, and active sessions. Mappings define the route from the public-facing domain through the WAF to the backend application — they're the WAF's equivalent of an Apache reverse-proxy config.
The dashboard panels:
| Panel | What it shows |
|---|---|
| System Health | Uptime, CPU, memory, disk usage |
| Requests by Protocol | HTTPS vs HTTP traffic over time |
| Active Sessions | Authenticated vs total sessions |
| Bandwidth | Incoming vs outgoing |
| Requests Total (e.g. 57,479) | Volume metric |
| Attacks Total (e.g. 4) | Detected attacks |
| Attack Types | Distribution: Request Tampering, Failed Sanity Checks, etc. |
| Attack Heat Map | Geographic origin of attacks (world map) |
The 57,479 / 4 ratio is normal:
Even on a properly configured WAF in production, only a tiny fraction of all traffic is malicious. Most traffic is legitimate; the WAF's job is identifying the few bad ones without blocking the good ones.
Mappings explained:
Virtual Host Mapping Back-end Group
─────────── ─────────── ───────────
beratung-int.xxx ──→ int_xxx_BEG ──→ dev_int_xxx_BEG
login-int.xxx ──→ int_Auth-API_OAuth ──→ devint_Medusa_New
my-int.xxx ──→ int_Auth-API_Pin ──→ int_Medusa
www-int.xxx ──→ int_xxx_https ──→ int_Kobil
A mapping translates the external URL/host to the internal routing:
- Client requests
https://login-int.example.com/oauth - Airlock matches the URL to mapping
int_Auth-API_OAuth - Mapping routes to backend group
devint_Medusa_New - WAF inspects → if OK, forwards to backend
- Backend response goes back through same path
Why mappings matter for security:
Each mapping has its own security policy: which input validation rules apply, which authentication is required, which HTTP methods are allowed. A login endpoint has stricter rules (rate-limiting, CAPTCHA) than a static-content endpoint.
Why Swiss banks love Airlock:
Swiss banks (UBS, Raiffeisen, ZKB) use Airlock heavily. Reasons:
- Swiss-developed and supported (data sovereignty)
- Strong support for cIAM (customer identity management) and OAuth 2.0
- Integration with Suprema / eID Swiss authentication systems
- Compliance with FINMA (Swiss financial regulator) requirements
Tip: When evaluating a WAF for Switzerland, the data-residency story matters — Airlock keeps everything on-prem; Cloudflare and AWS are US-based which can complicate FINMA / GDPR compliance discussions.
Go deeper:
Web Application Firewall (OWASP) — vendor-neutral grounding for what a WAF inspects and the reverse-proxy mapping model.