EC2.180: ENIs with source/dest check off can route around controls

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub EC2.180 check?

EC2.180 fails any ENI with SourceDestCheck set to false, evaluated every 12 hours. When the check is on (the default), the VPC data plane drops any packet whose source or destination IP does not match the ENI's own addresses; turning it off lets the ENI forward traffic for other IPs.

Why does EC2.180 matter?

Disabling the check turns the ENI into a router from the VPC's perspective — the hypervisor stops filtering and the instance can relay traffic for arbitrary addresses. That is the legitimate foundation of NAT instances, software firewalls, and VPN concentrators, but on a normal application server it is either a misconfiguration or an attacker pivoting laterally and routing around network controls.

How do I fix EC2.180?

Inventory every ENI with the check disabled across all regions using describe-network-interfaces.
Tag the genuine appliances (NAT instances, firewalls, VPN concentrators) with a consistent marker like Role=NetworkAppliance.
Re-enable the check on every untagged ENI with modify-network-interface-attribute --source-dest-check — the change is online and instant.
Retire NAT instances in favour of managed NAT Gateways (which never trigger this control) and codify the exception list.

Remediation script · bash

# Move the highest-impact case first: an RDS instance in a public subnet group.
aws rds create-db-subnet-group \
  --db-subnet-group-name prod-db-subnets-private \
  --db-subnet-group-description "Private subnets only - no IGW route" \
  --subnet-ids subnet-0aa11bb22cc33dd44 subnet-0ee55ff66aa77bb88

aws rds modify-db-instance \
  --db-instance-identifier prod-payments-db \
  --db-subnet-group-name prod-db-subnets-private \
  --apply-immediately

# Provide a private path before moving compute, so it can still reach AWS services.
# A free S3 gateway endpoint, or a narrow interface endpoint instead of a NAT gateway.
aws ec2 create-vpc-endpoint --vpc-id vpc-0a1b2c3d \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.ssm \
  --subnet-ids subnet-0aa11 subnet-0bb22 \
  --security-group-ids sg-0ccfn33 --private-dns-enabled

# Force Redshift bulk traffic through the VPC (confirm an S3 gateway endpoint exists first).
aws redshift modify-cluster \
  --cluster-identifier analytics-prod --enhanced-vpc-routing

Full walkthrough (console steps, edge cases and verification) in the lesson Move resources into private networks (VPC isolation).

Is EC2.180 a false positive?

NAT instances, software firewalls, and VPN concentrators must have the check off to do their job. The control is intent-blind, so those ENIs need a documented exemption rather than being forced back on, which would break their forwarding.

Full lesson Move resources into private networks (VPC isolation) Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for EC2 controls ↗ Check your own account for EC2.180 →

Part of the learning path Tighten your databases

EC2.1 An EBS snapshot is publicly restorable by any account
EC2.2 Default security groups still allow traffic
EC2.3 Attached EBS volumes are not encrypted at rest
EC2.4 Long-stopped instances are abandoned attack surface
EC2.6 No VPC flow logs, so there is no network audit trail
EC2.7 New EBS volumes are not encrypted by default
EC2.8 IMDSv1 lets an SSRF steal instance credentials
EC2.9 Instances are directly reachable on public IPv4
EC2.10 EC2 API traffic leaves the VPC over the internet
EC2.13 SSH (port 22) is open to the entire internet
EC2.14 RDP (port 3389) is open to the entire internet
EC2.15 Subnets auto-assign public IPs to new instances