Slide 24 of 28
Part 4 · PreventionSlide 24
Slide 24 · Mitigation 6
MIT 06
Run URL-fetching components in an isolated network segment with no internal access.

Separate the URL-fetching service from the rest of the infrastructure:

• Deploy a dedicated “fetch service” in a subnet with egress-only internet access — no routes to internal networks, no access to the VPC’s private subnets

• Block the metadata endpoint (169.254.169.254) at the subnet level or instance level (AWS IMDSv2 required, or metadata endpoint disabled entirely if the service doesn’t need instance credentials)

• Restrict outbound traffic from the fetch service to HTTPS on port 443 to the internet only — block all other protocols and ports

• The fetch service should have its own minimal IAM role with no permissions (or no IAM role at all)

MIT 01–05 are application-level defenses. Network isolation is an infrastructure-level backstop. If every application-level defense fails — the allowlist is bypassed, the IP check has a bug, redirects are followed — network isolation still limits the attacker. The fetch service can’t reach 10.0.0.1 because there’s no route. It can’t reach the metadata endpoint because it’s blocked at the network level.

For EC2 instances that must have a metadata endpoint, require IMDSv2 (which needs a PUT request for a session token before making metadata requests). Simple GET-based SSRF (the most common form) cannot exploit IMDSv2. This is an AWS-level control, not an application-level one — set it at the instance or account level.

💼 Business takeaway

Ask your infrastructure team whether your API servers have any network restrictions on what they can reach. A server that can connect to your database console or cloud metadata endpoint is a serious SSRF risk.

← Back MIT 07: Monitoring →