A homelab security architecture designed to isolate a self-hosted Splunk instance behind Cloudflare and validate Layer 7 DDoS mitigation through WAF rate limiting and SIEM telemetry analysis.

Project Overview

I built this project to protect a self-hosted Splunk Enterprise instance running on an Ubuntu server from direct exposure to the public internet.

The architecture uses an outbound-only Cloudflare Tunnel to isolate the origin, Cloudflare Access to enforce identity-based access control, and a WAF rate-limiting policy to mitigate high-volume Layer 7 HTTP traffic at the edge.

The primary objective was to simulate a Layer 7 DDoS attack against the public application endpoint and verify the complete security pipeline: the attack reaching Cloudflare, the WAF detecting and blocking the traffic, Cloudflare recording the resulting security events, and Splunk confirming what traffic actually reached the origin.

Architecture & Tech Stack

Origin: Ubuntu server running Splunk Enterprise
Edge: Cloudflare
Secure Access: Cloudflare Tunnel & Cloudflare Access
DDoS Mitigation: Cloudflare WAF Rate Limiting
SIEM: Splunk Enterprise
Telemetry: /var/log/auth.log and /var/log/cloudflared.log

Implementation Phases

Phase 1: Origin Isolation with Cloudflare Tunnel
I connected the Ubuntu server to Cloudflare using cloudflared. The tunnel establishes an outbound connection from the origin to Cloudflare, allowing the application to be published without exposing a direct inbound port on the Ubuntu server.

This established the foundation for the security architecture: internet traffic would first reach Cloudflare rather than directly reaching the underlying Splunk host.

Phase 2: Zero Trust Access Control
I configured Cloudflare Access to protect the public application endpoint. Unauthenticated requests were intercepted at the edge and redirected to the configured identity authentication flow.

This placed identity verification in front of the application, allowing the subsequent attack simulation to test the interaction between Zero Trust access controls and the WAF.

Phase 3: Layer 7 DDoS Attack Simulation
I then simulated a Layer 7 DDoS attack against the public application endpoint by generating a rapid sequence of HTTP requests. The purpose was to deliberately create a high-volume request condition and determine whether the Cloudflare edge controls would identify and mitigate the traffic before it reached the origin.

The initial requests returned HTTP 302 responses as Cloudflare Access intercepted the unauthenticated traffic. As the request volume continued, the configured WAF rate-limiting threshold was reached and subsequent requests returned HTTP 429 Too Many Requests.

This demonstrated the intended attack path: the simulated malicious traffic reached the Cloudflare edge, triggered the configured rate-limiting control, and was rejected before continuing toward the application.

Phase 4: Cloudflare Edge Mitigation & Security Events
After running the attack simulation, I reviewed Cloudflare Security Events to verify that the WAF had identified and blocked the request traffic.

The Security Events dashboard recorded blocked requests associated with the configured rate-limiting policy. This provided independent evidence from the edge that the WAF mitigation was actively responding to the simulated attack traffic.

Phase 5: Splunk Origin Telemetry Verification
The final step was determining whether the attack traffic actually reached the Ubuntu origin. I configured Splunk to ingest host-level telemetry from /var/log/auth.log and /var/log/cloudflared.log.

I then searched the ingested telemetry for "429", matching the HTTP status generated during the WAF mitigation test. The search returned zero matching events, while Cloudflare Security Events showed the traffic being blocked at the edge.

Comparing the two telemetry sources provided evidence that the rate-limited attack traffic was handled by Cloudflare before corresponding 429 events appeared in the origin-side logs.

Security Relevance

This project demonstrates a layered approach to defending a self-hosted security infrastructure environment. Cloudflare Tunnel isolates the origin from direct inbound exposure, Cloudflare Access adds identity-based access control, and WAF rate limiting provides an edge control for high-volume application-layer traffic.

The DDoS simulation also demonstrates the value of correlating edge and host telemetry. Cloudflare provided visibility into the attack and mitigation activity, while Splunk was used to determine whether corresponding traffic appeared in the origin environment.

Layer 7 DDoS Traffic
       ↓
Cloudflare Edge
       ↓
Cloudflare Access
       ↓
WAF Rate Limiting
       ↓
Blocked / HTTP 429
       ↓
Cloudflare Security Events
       
Allowed Traffic
       ↓
Cloudflare Tunnel
       ↓
Ubuntu / Splunk
       ↓
Origin Telemetry Verification

This project was built as a hands-on security homelab to demonstrate Zero Trust architecture, Layer 7 DDoS mitigation, edge security monitoring, and SIEM-based verification using Cloudflare and Splunk.