European Central Bank Identifies Gaps in Its DDoS Protection Stack

For central banks, maintaining uninterrupted digital operations is a matter of national confidence. Recognizing this, a European central bank commissioned a DDoS resilience test to validate the strength of its layered defense architecture, with particular focus on its Verification of Payee (VOP) system — a critical safeguard in preventing payment fraud.

The national bank uses a layered design to protect its online assets from malicious requests and targeted cyberattacks. Incoming traffic first passes through a Cloudflare WAF, which inspects certificates and enforces rate limits. A Cloudflare Worker then carries out additional checks for authenticity and integrity, and valid requests are forwarded to an on-premises Certificate Validation Service to verify PSD2 compliance. Finally, the API Gateway ensures that the traffic originates from Cloudflare, validates payload integrity, and checks timestamps and request IDs before routing requests to the backend services.

The Solution

Our team conducted a DDoS simulation to assess the effectiveness and resilience of the bank’s multi-stage traffic filtering. We deployed two globally distributed botnets, one comprising 300 bots and another 400 bots, to emulate realistic large-scale DDoS traffic patterns.

The simulation included one protocol- and one network-layer attack vector, along with seven application-layer attacks targeting the VOP service. In addition, the organization’s public website was retested with three additional application-layer attacks after suffering disruption during earlier DDoS testing. The simulation was executed within geo-restrictions set to block all traffic coming from countries like North Korea, Russia and Iran (known to sponsor or enable top-tier cyberthreats), and with two newly configured rate-limit rules.

The Results

During the network- and protocol-layer attack simulations, the ISP’s infrastructure became saturated, resulting in service disruption and dropped traffic. This was despite properly configured ACLs on the ISP cleanpipe, a critical layer of defense against such DDoS attacks.

Two out of seven application-layer attack vectors targeting the VOP service were not detected, compromising its availability.

The three additional application-layer attacks directed at the bank’s public website went undetected and unmitigated, although only two disrupted online services. Interestingly, the system absorbed all the attack traffic in an HTTPS POST Flood attack executed at steadily increasing rates, even after it exceeded the rate-limit threshold.

Recommendations

To address the identified DDoS protection gaps, our team recommended that the central bank take the following measures:

• Enhance upstream DDoS mitigation: Work with the ISP to strengthen protection and ensure sufficient capacity to handle large-scale attacks. This will reduce the risk of service disruption during future high-volume network events.
• Enforce HTTP payload size limits: There were no restrictions on the size of HTTP payload requests, which leaves the bank’s system open to certain application-layer attacks intended to exhaust server resources. Strict HTTP payload size thresholds need to be implemented in alignment with expected service usage to mitigate malicious resource-heavy requests.
• Collaborate with Cloudflare: Some attacks exceeded defined rate-limit thresholds without triggering Cloudflare rules, suggesting either configuration issues or limitations in Cloudflare’s mechanics. Collaborate with Cloudflare to ensure that traffic controls are correctly configured, bound to the right endpoints, and reliably enforced in real time.
• Fine-tune Cloudflare WAF rate-limit thresholds: Current thresholds are highly permissive. They should be reviewed and adjusted to a baseline set in accordance with observable normal user behavior and legitimate traffic patterns.

• Cache static assets in the CDN: While a GET Flood attack caused downtime in the origin server of the bank’s public website, cached resources continued to be served successfully by the CDN. Caching all static content will reduce the attack surface, lessen origin load, minimize latency, and maintain service availability during periods of high demand.