Kistler

The Challenge

Kistler, a global leader in measurement technology and industrial sensors, operates web-based platforms that serve customers across manufacturing, automotive, and aerospace industries. These platforms provide access to sensor configuration tools, measurement data, and technical documentation that their customers depend on for mission-critical operations.

The company had experienced increasing frequency and sophistication of DDoS attacks targeting their web infrastructure. While previous attacks had been mitigated through manual intervention and upstream provider filtering, the growing threat landscape demanded a more robust and automated solution.

The technical constraints made this a particularly nuanced engagement:

• Zero tolerance for downtime: Kistler’s customers rely on continuous access to measurement platforms during manufacturing operations. Any service interruption during the cutover to a new protection layer was unacceptable.
• End-to-end TLS requirements: Kistler’s security policy mandated TLS encryption from client to origin with no termination at intermediate layers that could expose data in transit. The DDoS protection solution needed to preserve this encryption chain without introducing certificate management complexity.
• EKS-based architecture: Kistler’s web applications ran on Amazon EKS with Kubernetes ingress controllers managing traffic routing. Any protection layer needed to integrate cleanly with the existing ingress architecture without requiring application-level changes.
• Diverse traffic patterns: Kistler’s platforms serve both human users accessing web interfaces and automated systems performing API calls for sensor data retrieval. The protection solution needed to distinguish between legitimate automated traffic and malicious bot activity.

The Solution

Remangu designed a multi-layer DDoS protection architecture that placed CloudFront and AWS WAF in front of Kistler’s existing infrastructure, with careful attention to the zero-downtime cutover requirement and TLS encryption chain.

CloudFront as the Protection Layer

Amazon CloudFront was deployed as the entry point for all external traffic, positioned between end users and Kistler’s EKS-hosted applications. This architecture provided several immediate benefits:

Distributed edge absorption meant that volumetric DDoS attacks would be absorbed by CloudFront’s global edge network rather than reaching Kistler’s origin infrastructure. CloudFront’s capacity to absorb traffic at the edge is orders of magnitude greater than any single origin, providing inherent protection against bandwidth-exhaustion attacks.

Origin isolation was achieved by restricting origin access to CloudFront’s IP ranges only. Security groups on the EKS cluster’s load balancers were updated to accept traffic exclusively from CloudFront, effectively making the origin infrastructure invisible to direct attack. Origin Access Control ensured that requests reaching the origin were authenticated as coming from the authorized CloudFront distribution.

Caching at the edge reduced origin load for static and semi-static content including documentation, software downloads, and configuration templates. This both improved performance for end users and reduced the blast radius of any attack that bypassed WAF rules, since cached content could continue to be served even under origin stress.

AWS WAF Integration

AWS WAF was associated with the CloudFront distribution, providing application-layer filtering before traffic reached the origin.

Managed rule groups provided baseline protection against common attack vectors including SQL injection, cross-site scripting, and known-bad IP addresses. The AWS Managed Rules for Bot Control were configured to handle Kistler’s specific requirement of allowing legitimate automated API clients while blocking malicious bots.

Custom rate limiting rules were defined based on analysis of Kistler’s normal traffic patterns. Separate rate limits were configured for web interface endpoints and API endpoints, reflecting the different expected request rates for human and automated access. Rate limits were set conservatively during the initial deployment and tuned based on observed traffic during the first two weeks of operation.

Geographic restrictions were applied where Kistler’s business requirements allowed, blocking traffic from regions with no legitimate customer base. This reduced the attack surface without impacting any real users.

AWS Shield Standard was automatically enabled with CloudFront, providing protection against the most common network and transport layer DDoS attacks at no additional cost. The combination of Shield, WAF, and CloudFront’s native capacity created defense in depth across network layers 3, 4, and 7.

TLS Encryption Preservation

Maintaining end-to-end TLS encryption required careful configuration at each hop in the request path.

Client to CloudFront encryption used ACM-managed certificates with automatic renewal. CloudFront was configured with the TLSv1.2_2021 security policy, enforcing modern cipher suites and rejecting legacy TLS versions.

CloudFront to origin encryption was configured using HTTPS-only origin protocol policy. The origin’s existing TLS certificates were retained, and CloudFront was configured to validate the origin certificate, ensuring that the connection between CloudFront and the EKS ingress was both encrypted and authenticated.

This architecture meant that at no point in the request path was data transmitted unencrypted. CloudFront’s edge processing of WAF rules operated on encrypted connections without requiring TLS termination that would expose plaintext data.

Seamless EKS Integration

Integration with Kistler’s EKS infrastructure required changes only at the network boundary, not within the application layer.

Ingress controller configuration remained unchanged. CloudFront forwarded requests to the existing Application Load Balancer fronting the EKS ingress, preserving all existing routing rules, health checks, and backend service mappings.

Header forwarding was configured to pass original client IP addresses, host headers, and custom headers through CloudFront to the origin. This ensured that application-level logging, access controls, and routing logic continued to function correctly with the new architecture.

Health checking was implemented at both the CloudFront and Route 53 layers, providing automated failover capabilities and immediate visibility into origin health from the edge.

Zero-Downtime Cutover

The cutover was executed using a carefully orchestrated DNS migration strategy:

1. CloudFront distributions were fully provisioned and validated using test domains before touching production DNS.
2. WAF rules were deployed in count mode initially, logging what would be blocked without actually blocking traffic, to verify that no legitimate traffic would be impacted.
3. Route 53 weighted routing policies shifted traffic gradually from the direct origin to CloudFront, starting at 5% and increasing over 48 hours.
4. Once 100% of traffic was flowing through CloudFront with no issues detected, the weighted routing was replaced with a standard alias record pointing to CloudFront.

This phased approach ensured that any unexpected issues could be detected and rolled back at low traffic percentages before impacting the majority of users.

The Results

The DDoS protection implementation met every requirement Kistler defined, with measurable improvements in security posture and operational confidence.

Significantly stronger DDoS protection is now in place across all layers. In the three months following deployment, CloudFront and WAF absorbed and mitigated four DDoS events that would have previously required manual intervention. The largest event peaked at over 2 Gbps of attack traffic and was fully absorbed at the edge with zero impact on origin infrastructure. WAF rules blocked over 50,000 malicious requests per day on average, with a false positive rate below 0.01%.

Zero-downtime cutover was achieved through the phased DNS migration. Production monitoring confirmed no increase in error rates, latency, or failed requests at any point during the transition. End users experienced no service disruption, and Kistler’s operations team did not receive a single customer complaint related to the migration.

Preserved TLS encryption was validated through end-to-end testing confirming that all traffic remained encrypted in transit. Security audit confirmed that the new architecture maintained compliance with Kistler’s encryption policies and did not introduce any new exposure points for sensitive data.

Seamless EKS integration required zero changes to application code or Kubernetes configurations. The existing ingress controllers, service meshes, and deployment pipelines continued to function without modification. This meant that development teams experienced no disruption to their workflows, and the protection layer was entirely transparent to application-level operations.