Cloudflare WAF Deployment for a Melbourne SaaS Platform

Background

A Melbourne-based HR and payroll SaaS platform serving 600+ small and medium businesses across Australia engaged CyberneticsPlus after their DevOps team identified unusual traffic patterns in their application logs.

The platform handles payroll processing, employee records, and tax compliance data for SME clients — making it a high-value target for credential-based attacks seeking access to employee financial data.

Identified issues at engagement start:

• 140,000+ failed login attempts per day against the /auth/login endpoint
• Application servers running at 60–70% CPU during off-peak hours (2–4 AM AEDT) due to bot traffic
• 23 confirmed account takeovers in the preceding 6 weeks (all via credential stuffing with leaked credentials from other breaches)
• No WAF in place — only the hosting provider’s basic DDoS protection

Assessment

CyberneticsPlus conducted a 2-day assessment before deployment:

Traffic analysis:

• 62% of login attempts came from known datacenter IP ranges (not residential/mobile — strong bot indicator)
• Attack traffic peaked 2–5 AM AEDT (11:30 PM–2:30 AM IST) — consistent with automated attacks timed to avoid detection
• Credential stuffing requests had no Accept-Language header and used a static User-Agent string
• 94% of attacking IPs were not previously associated with any legitimate login

Account compromise analysis:

• All 23 compromised accounts used passwords that appeared in the HaveIBeenPwned database
• Attack methodology: tested leaked email/password combinations at ~300 requests/second (below alerting threshold)
• Attacker accessed payroll data and in 7 cases, attempted to modify bank account numbers for payroll direct deposits

Deployment

Phase 1: Cloudflare Onboarding (Day 1)

• DNS migration to Cloudflare proxy
• SSL mode set to Full (Strict) with origin certificate validation
• Origin server firewall rules updated to accept only Cloudflare IP ranges
• HSTS enabled with 12-month max-age

Phase 2: WAF Configuration (Days 2–3)

Managed rules:

• Cloudflare Managed Ruleset: enabled with Block action
• OWASP Core Ruleset: enabled at Level 1 (paranoia), action Log (for tuning baseline)

Custom rules targeting the credential stuffing pattern:

Rule 1: Block known bot fingerprint
Expression: (not http.request.headers["accept-language"][0] exists) and
            (http.request.uri.path eq "/auth/login") and
            (http.request.method eq "POST")
Action: Block

Rule 2: Challenge datacenter traffic on login
Expression: (cf.verified_bot_category ne "Search Engine") and
            (ip.src.asnum in {datacenter_asns}) and
            (http.request.uri.path eq "/auth/login")
Action: Managed Challenge

Rule 3: Rate limit login attempts
Expression: http.request.uri.path eq "/auth/login" and
            http.request.method eq "POST"
Threshold: 5 per 60 seconds per IP
Action: Block for 300 seconds

Bot Management: Super Bot Fight Mode enabled (Business plan)

• Definitely Automated → Block
• Likely Automated → Managed Challenge
• Verified Bots (Google, uptime monitors) → Allow

Geography-based rule:

• All non-AU/NZ traffic hitting /auth/login → Managed Challenge (85% of attacking traffic was from non-AU sources)

Phase 3: Tuning (Days 4–10)

Two weeks of tuning in Log mode before switching to Block for OWASP rules:

False positives identified:

• Enterprise clients using API-based authentication from datacenter IPs (CI/CD pipelines, automated integrations)
• Added these specific client IPs to a WAF bypass rule

Legitimate bot traffic preserved:

• Uptime Robot and Freshping monitoring services added to verified bots allowlist
• Client’s own automated testing suite IP range allowlisted

Results

After 30 days of production operation:

Attack traffic:

• Login attempt volume: 140,000/day → 280/day (99.8% blocked or challenged)
• No new account compromises since WAF deployment
• Automated credential stuffing: completely eliminated

Infrastructure impact:

• Application server CPU utilisation: 60–70% peak → 40–45% peak (34% reduction)
• Database connection pool pressure: significantly reduced
• Application response time at login endpoint: 340ms average → 180ms average (48% improvement due to bot traffic elimination)

False positive rate:

• 0.003% of legitimate user logins received a challenge (all resolved within 5 seconds)
• Zero legitimate users blocked (block action only applied to confirmed bots)

Security posture:

• All account compromise vectors identified in the assessment have been eliminated
• Ongoing credential stuffing attempts automatically detected and blocked
• Security logging via Cloudflare Logpush integrated with the client’s SIEM (Splunk Cloud)

Follow-On Work

Following the WAF success, the client commissioned:

1. Penetration test of the web application (unrelated to bot/DDoS work)
2. AWS security assessment of their cloud infrastructure
3. Employee phishing simulation following the account compromise incidents (attackers had used compromised accounts to send internal phishing emails to employees)

The platform now operates with Cloudflare Enterprise, has undergone a full security assessment, and has implemented MFA as a mandatory requirement for all accounts — eliminating the credential stuffing risk at the authentication layer.