Public IPs on Every Tier: Closing an Exposed Public Cloud Project
A Public Cloud project hosts a three-tier web application: one load balancer, three application instances and one managed database. Every instance has a public IP. Security groups allow SSH (22) and MySQL (3306) from 0.0.0.0/0, and the database accepts connections from the internet. Logs show roughly 40,000 SSH login attempts per day from rotating addresses, and a recent scan found the database port open. The application serves 2,000 requests per minute at peak and must stay online. A PCI-style audit requires that only the load balancer be internet-facing, administrative access be mediated and logged, and database traffic never cross the public internet. The operations team works remotely from home offices with dynamic IPs; there is no VPN or bastion yet. A 30-minute maintenance window is available on Sunday. The team wants to keep the load balancer's public IP and avoid changing DNS TTLs.
1. Redesign the network and access path. State what gets a public IP and how administrators reach SSH.
Read the worked answer
Make the load balancer the only public entry point. Put the three application instances and the database on a private network and subnet; remove their public IPs. Security groups: allow 443/80 from the internet only to the load balancer, allow the application port only from the load balancer's security group, allow 3306 only from the application group, and deny everything else. For administration, deploy a small bastion or VPN gateway with a public IP and MFA, reachable over WireGuard or OpenVPN; from there, SSH to instances using keys. Because the team has dynamic home IPs, a static allowlist is brittle; a VPN with per-user credentials is more defensible. Use a NAT gateway for outbound package updates. Keep the load balancer's public IP, so no DNS change is needed. In the 30-minute window, attach instances to the private network, apply groups, remove public IPs, then test health checks; roll back by reattaching public IPs if needed.
2. Will OVHcloud Anti-DDoS or the load balancer stop the SSH brute force? What controls do you add?
Read the worked answer
No. OVHcloud Anti-DDoS absorbs volumetric and network-layer floods; it does not stop password guessing against SSH. The load balancer does not front SSH and does not authenticate users. The 40,000 attempts are hitting the public SSH service directly. Removing public SSH is the primary control. On the bastion, disable password authentication, require keys, enforce MFA, rate-limit and run fail2ban, and alert on successful logins from new countries. Add a WAF in front of the application if the audit requires it, but do not confuse that with SSH protection. Also disable MySQL remote root and use named database users. After cutover, verify with an external port scan that only 443 and the VPN port respond. Review authentication logs weekly and rotate keys when staff leave.
3. What evidence would you collect to prove audit compliance after cutover?
Read the worked answer
Collect the security-group export showing default-deny and the narrow rules; the instance list proving no public IPs on application and database; private-network and route-table diagrams; load-balancer health-check results; bastion authentication logs with MFA; VPN logs; and a before/after external scan. Add flow logs if available, plus database connection logs showing only application-subnet sources. Record the change ticket and the rollback test. For PCI-style evidence, include a quarterly access review, key rotation, and a vulnerability scan of the public load balancer. Store the evidence with the audit package, not only in chat. Also document the emergency access procedure and show that it is logged and reviewed.