Origin IP Found in DNS History and Certificate Transparency
Vantage Retail's origin is at 203.0.113.10 and is supposed to be hidden behind Cloudflare. A researcher found the IP in a 2023 DNS history dataset and in a certificate transparency log for origin.example.com. Last night attackers sent 28 Gbps of HTTP GET floods directly to 203.0.113.10; Cloudflare WAF logs show nothing because the traffic never reached Cloudflare. The origin firewall currently allows 0.0.0.0/0 to 80/443 and has a 1 Gbps uplink, which saturated. The Kubernetes ingress logs show SYN floods and complete GET requests, not just noise. The company has 30 minutes of downtime and a change freeze in 3 days. They run 12 microservices on Kubernetes behind an NGINX ingress. They cannot move to a new IP immediately because partner allowlists reference it.
1. What immediate changes stop the direct-to-origin flood without a new IP?
Read the worked answer
Change the origin firewall or security group to allow TCP 80/443 only from Cloudflare's published IP ranges, and deny all other sources. This immediately drops the attacker's direct traffic because the attack is not coming through Cloudflare. Enable Authenticated Origin Pulls so the origin also validates Cloudflare's client certificate at the TLS layer; the firewall is the primary control, but mutual TLS prevents misconfigured or spoofed paths.
The partner allowlist is the conflict. Partners that connect directly to 203.0.113.10 will break when the firewall is restricted. In the 30-minute window, move partners to a separate hostname or VPN path, or accept a known outage for direct partner traffic while restoring the public site. Record this as an emergency change; do not leave the origin open until the 3-day freeze ends.
2. Why did certificate transparency and DNS history expose the origin, and how do you prevent recurrence?
Read the worked answer
The origin hostname origin.example.com was issued a publicly trusted certificate. Public CAs submit certificates to certificate transparency logs, so anyone can search for hostnames and infer infrastructure. DNS history datasets preserved an earlier record that pointed to 203.0.113.10. Neither leak requires breaking Cloudflare; they expose the origin because the origin was directly reachable and used a public certificate.
Prevention: move the origin behind Cloudflare Tunnel so there is no public inbound IP, or at minimum use a Cloudflare Origin CA certificate, which is not publicly trusted and not CT-logged, and keep the origin hostname out of public DNS. Restrict the origin firewall to Cloudflare or to the tunnel. Rotate the origin IP after partner allowlists are updated. Search CT logs and DNS history for other origin hostnames before declaring the exposure closed.
3. What is the 3-day plan versus the 3-month plan?
Read the worked answer
Three days: keep the Cloudflare-only firewall rule, update partner allowlists or move partners to a separate endpoint, rotate 203.0.113.10 if partner dependencies allow, and add monitoring for direct-to-origin connection attempts. Use the emergency change process to bypass the freeze with documented approval.
Three months: migrate the Kubernetes ingress to Cloudflare Tunnel with outbound-only connectors, remove public origin IPs, and use Origin CA certificates. Put partners on a dedicated hostname with mTLS or IP allowlisting that does not expose the main origin. Add egress monitoring and periodic CT/DNS exposure scans. The goal is to make the origin unaddressable from the internet, not merely filtered.