How I Investigated and Secured a Web Infrastructure After a DDoS Attack

Introduction

Recently, I was contacted by the CEO of a company operating in the travel and hospitality technology sector.

The company develops and deploys web platforms for travel agencies and hotel booking businesses.

The company had experienced a Distributed Denial-of-Service (DDoS) attack that caused several websites connected to its HAProxy infrastructure to become unavailable.

The objective of my intervention was to identify the root cause of the incident, understand the attack path, and design a more resilient architecture capable of reducing the risk of a similar attack in the future.

This article presents the technical investigation and the security measures I recommended.

Note:_ For confidentiality reasons, client names, domain names, IP addresses and infrastructure-specific information have been removed or anonymized._

1. The Initial Architecture

The infrastructure was based on a relatively common architecture:

Internet → Cloudflare → HAProxy → Web Servers

Cloudflare was intended to provide the first layer of protection before traffic reached the origin infrastructure.

However, during the investigation, I discovered an important weakness:

The origin HAProxy server was directly reachable from the Internet.

This meant that an attacker could potentially bypass Cloudflare and communicate directly with the origin server.

Legitimate traffic

User
 ↓
Cloudflare
 ↓
HAProxy
 ↓
Web Servers

User
 ↓
Cloudflare
 ↓
HAProxy
 ↓
Web Servers

Attack traffic

Attacker
 ↓
HAProxy directly
 ↓
Web Servers

Attacker
 ↓
HAProxy directly
 ↓
Web Servers

The second path was the critical issue.

The original incident analysis showed that the HAProxy origin IP was directly exposed. Large volumes of HTTP requests were then sent directly toward the proxy, exhausting its available resources and contributing to backend availability problems and 504 Gateway Timeout errors.

2. Identifying the Root Cause

At first glance, the incident looked like a classic availability problem caused by a large amount of malicious traffic.

But the deeper issue was architectural.

The question was not simply:

How do we stop the DDoS traffic?

The more important question was:

Why was the attacker able to reach the origin infrastructure directly?

The investigation showed that the origin IP was publicly discoverable.

Once the origin IP was known, Cloudflare could effectively be bypassed.

This is a fundamental security problem for any architecture relying on a CDN or WAF:

If the origin remains directly accessible, an attacker may simply go around the protection layer.

The first objective therefore became clear:

Protect the origin server itself.

3. Understanding the Traffic Flow

A secure architecture should distinguish between legitimate traffic and abnormal traffic.

Legitimate users should be able to access the application normally:

User → Cloudflare → HAProxy → Backend

At the same time, suspicious traffic should be detected and limited before it consumes the resources of the backend infrastructure.

The proposed architecture therefore introduced rate limiting as an additional layer of protection.

The goal was not to block everyone.

Instead:

• legitimate traffic should continue normally;
• abnormal traffic should be identified;
• excessive requests should be rate-limited;
• malicious traffic should be blocked when necessary.

This distinction is particularly important for travel and hotel booking platforms, where availability and user experience directly affect business operations.

4. First Remediation: Replace the Exposed Origin IP

One of the first recommendations was to replace the previously exposed public IP address of the HAProxy server.

Simply changing the DNS record was not considered sufficient because the old IP had already been publicly exposed and could remain present in historical datasets.

The remediation plan was therefore:

1. Provision a new IP address.
2. Migrate HAProxy to the new address.
3. Update the Cloudflare DNS record.
4. Verify that Cloudflare proxying remained enabled.
5. Decommission the old IP.

The objective was to prevent the previously exposed origin address from remaining a direct target.

The final validation was to ensure that public DNS resolution exposed only Cloudflare addresses rather than the origin server.

5. Second Remediation: Allow Only Cloudflare Traffic

Changing the IP address was only the first step.

A new IP could potentially be discovered in the future as well.

Therefore, I proposed an additional control directly at the HAProxy layer:

Only traffic originating from Cloudflare's official IP ranges should be allowed to reach HAProxy.

The logic becomes:

Cloudflare → HAProxy → Backend

while:

Internet → HAProxy → ❌ Blocked

This creates an important security property.

Even if an attacker discovers the new origin IP, simply knowing the IP is no longer enough to reach the application directly.

The HAProxy configuration was designed to allow Cloudflare source ranges and reject connections that did not originate from an authorized Cloudflare network. The configuration was also validated before being reloaded to avoid introducing a service outage.

This is an example of defense in depth.

The architecture no longer depends on the secrecy of the origin IP.

6. Moving From Global Protection to Targeted Rate Limiting

During an active attack, stronger protection modes can be useful.

However, permanent aggressive protection can negatively affect legitimate users.

For a booking platform, a customer should not have to fight through unnecessary security challenges simply to:

• search for a hotel;
• check availability;
• browse destinations;
• make a reservation.

The objective was therefore to implement targeted rate limiting.

The proposed approach was to detect abnormal request rates and automatically limit sources generating excessive traffic.

The protection was designed at two levels:

Cloudflare

Rate limiting at the edge before traffic reaches the origin.

HAProxy

An additional rate-limiting layer close to the application infrastructure.

This creates a second defensive mechanism if abnormal traffic reaches the origin layer.

The report proposed request-rate tracking and automatic rejection once a defined request threshold was exceeded.

7. Additional Hardening: Disable HTTP TRACE

During the security review, another configuration issue was identified:

HTTP TRACE was enabled.

TRACE is generally associated with HTTP diagnostic functionality.

When it is not required by the application, disabling it reduces unnecessary attack surface and prevents the server from responding to TRACE requests.

The proposed remediation was to explicitly reject TRACE requests at HAProxy.

The expected response after remediation was:

405 Method Not Allowed

405 Method Not Allowed

The configuration was then validated before reloading HAProxy, followed by a functional test to confirm that TRACE was no longer accepted.

8. The Final Security Architecture

After implementing the different security layers, the target architecture became:

Internet

↓

Cloudflare

↓

HAProxy

↓

Web Servers

But each layer now had a specific security responsibility:

Layer 1 — Cloudflare

• DDoS protection
• WAF
• Edge filtering
• Bot and suspicious traffic management

Layer 2 — HAProxy Origin Protection

• Cloudflare IP allowlist
• Direct Internet access blocked
• Secure proxy configuration

Layer 3 — Rate Limiting

• Detect abnormal request rates
• Limit excessive traffic
• Protect backend resources

Layer 4 — HTTP Hardening

• Disable unnecessary HTTP methods
• Reduce unnecessary attack surface
• Prevent unwanted information exposure

The final architecture was therefore based on several independent security layers rather than relying on Cloudflare alone.

The report's final state describes the origin as no longer directly exposed through the public DNS path, direct non-Cloudflare connections being rejected, targeted rate limiting replacing the permanent global challenge approach, and TRACE returning 405 Method Not Allowed.

9. What This Incident Taught Me

This mission reinforced an important principle in infrastructure security:

A security product is only as strong as the architecture surrounding it.

Having Cloudflare in front of an application does not automatically mean the origin is protected.

You also need to ask:

• Can the origin IP be discovered?
• Can the origin be accessed directly?
• Can the WAF/CDN be bypassed?
• What happens if the origin IP becomes public?
• Is abnormal traffic rate-limited?
• Are unnecessary protocols or HTTP methods enabled?
• Can the infrastructure remain available during an attack?

These questions are often more important than simply asking which security product is installed.

10. Defense in Depth

The final solution followed a simple principle:

Never rely on a single security control.

The architecture combined:

Cloudflare

↓

Origin IP protection

↓

HAProxy access control

↓

Rate limiting

↓

Web application

Each layer provides a different defensive capability.

If one control is bypassed or misconfigured, another layer still provides protection.

This is the essence of defense in depth.

Conclusion

This mission started with a DDoS attack that affected the availability of production websites.

The investigation revealed that the most important weakness was not simply the volume of malicious traffic.

The critical issue was that the origin infrastructure could be reached directly, allowing an attacker to bypass the intended Cloudflare protection layer.

The remediation therefore focused on both mitigation and architecture:

• replacing the exposed origin IP;
• protecting the origin behind Cloudflare;
• allowing only authorized Cloudflare traffic;
• implementing targeted rate limiting;
• hardening the HAProxy HTTP configuration;
• validating each change before applying it to production.

The final objective was not just to stop the current attack.

It was to make the architecture more resilient against the next one.

Security is not about hiding the infrastructure. Security is about controlling who can reach it, how they can reach it, and what happens when they try.

Technologies & Skills

Cloudflare · HAProxy · Linux · HTTP Security · DDoS Mitigation · Rate Limiting · Network Security · Infrastructure Hardening · Web Security · Incident Response · Security Assessment

This case study is based on a real professional cybersecurity intervention. Client-specific information, IP addresses, domains and sensitive infrastructure details have been intentionally omitted.