Working with Network Access Scopes - Amazon Virtual Private Cloud

Working with Network Access Scopes

With Network Access Analyzer, you can specify your network access requirements by using Network Access Scopes. A Network Access Scope defines outbound (egress) and inbound (ingress) traffic patterns, including sources, destinations, paths, and traffic types. Each Network Access Scope consists of one or more MatchPath entries, and zero or more ExcludePath entries, that together define a set of network traffic patterns.

When you start an analysis on a Network Access Scope, Network Access Analyzer produces findings. It identifies network paths in the Network Access Scope that match at least one of the MatchPath entries, and none of the ExcludePath entries. By combining MatchPaths and ExcludePaths, you can refine the findings produced by Network Access Analyzer to identify unexpected connectivity in your network.

MatchPath and ExcludePath entries have a similar structure, consisting of ResourceStatements and PacketHeaderStatements that define network traffic to match or exclude. In the following sections, we first describe ResourceStatements and PacketHeaderStatements, before describing MatchPath and ExcludePath entries.

ResourceStatements

A ResourceStatement defines the network components that the match or exclude statement applies to. Each ResourceStatement consists of either a list of resource IDs (or ARNs), or a list of resource types. A single ResourceStatement can list either resource IDs or resource types, but cannot list both.

The following elements can be specified as resource IDs:

  • EC2 instances (source and destination fields only)

  • Network interfaces (source and destination fields only)

  • Security groups (source and destination fields only)

  • Subnets (source and destination fields only)

  • VPCs (source and destination fields only)

  • Internet gateways (source and destination fields only)

  • Virtual private gateways (source and destination fields only)

  • Transit gateway attachments

  • VPC peering connections

  • VPC endpoints

  • VPC endpoint services

  • NAT gateways (through fields only)

  • Network firewalls (through fields only)

  • Classic, Application, and Network Load Balancers (through fields only)

  • Resource groups (must contain resources of the preceding types)

Except for load balancers, all of the preceding elements can be specified as resource IDs (for example, vpc-XXXXXX), or as ARNs. Load balancers must be specified as ARNs.

The following elements can be specified as resource types:

  • AWS::EC2::InternetGateway (only in source and destination fields)

  • AWS::EC2::VPNGateway (only in source and destination fields)

  • AWS::EC2::TransitGatewayAttachment

  • AWS::EC2::VPCPeeringConnection

  • AWS::EC2::VPCEndpoint (not supported in source fields)

  • AWS::EC2::VPCEndpointService

  • AWS::EC2::NatGateway (only in through fields)

  • AWS::ElasticLoadBalancing::LoadBalancer (only in through fields)

  • AWS::ElasticLoadBalancingV2::LoadBalancer (only in through fields)

  • AWS::NetworkFirewall::NetworkFirewall (only in through fields)

PacketHeaderStatements

A PacketHeaderStatement defines the traffic type that a match or exclude statement applies to. If not specified, all traffic types are matched by default. All fields in a PacketHeaderStatement are optional, but if a PacketHeaderStatement is defined, at least one of its fields must be defined.

The following fields can be supplied in a PacketHeaderStatement:

  • Protocols — a list of protocol strings to match. Supported values are tcp or udp. Either or both can be supplied. If this field is omitted, packets with either tcp or udp protocol are admitted.

  • SourceAddress — a list of IP addresses or CIDR ranges. This option is mutually exclusive with SourcePrefixLists. If specified, only packets with matching source addresses are admitted. If neither SourcePrefixLists or SourceAddresses are specified, packets with any source address are admitted.

  • SourcePrefixLists — a list of prefix lists in ID or ARN form. This option is mutually exclusive with SourceAddresses. If specified, only packets with matching source addresses are admitted. If neither SourcePrefixLists or SourceAddresses are specified, packets with any source address are admitted.

  • DestinationAddress — a list of IP addresses or CIDR ranges. This option is mutually exclusive with DestinationPrefixLists. If specified, only packets with matching destination addresses are admitted. If neither DestinationPrefixLists or DestinationAddress are specified, packets with any destination address are admitted.

  • DestinationPrefixLists — a list of prefix lists in ID or ARN form. This option is mutually exclusive with DestinationAddress. If specified, only packets with matching destination addresses are admitted. If neither DestinationPrefixLists or DestinationAddress are specified, packets with any destination address are admitted.

  • SourcePorts — a list of ports or port ranges ("80","1024-65535"). If specified, only packets with source ports that match one of the ports or ranges are admitted. If omitted, packets with any source port are admitted.

  • DestinationPorts — a list of ports or port ranges (for example,"80","1024-65535"). If specified, only packets with destination ports that match one of the ports or ranges are admitted. If omitted, packets with any destination port are admitted.

MatchPaths entries

A MatchPath entry consists of a source entry or a destination entry, or both, which define the types of network paths that should be produced as findings for a Network Access Scope. Source and destination entries have the same structure; each may define either a ResourceStatement or a PacketHeaderStatement, or both.

A Network Access Scope containing a MatchPath that specifies a source entry but no destination entry produces findings for network paths:

  • that end at any supported resource,

  • that start at a resource that matches the ResourceStatement condition of the source entry (if defined), and

  • with a packet header that matches the PacketHeaderStatement of the source entry (if defined).

Similarly, if the MatchPath specifies a destination entry (but not a source entry), the Network Access Scope produces findings for network paths:

  • that start at any supported resource, so long as the path ends at a resource that matches the ResourceStatement of the destination entry (if defined), and

  • with a packet header that matches the PacketHeaderStatement of the destination entry (if defined).

A MatchPath can optionally specify both a source and destination entry, in which case both the start and end of the path must match the source and destination entry, respectively.

A Network Access Scope must specify at least one MatchPath entry, and can optionally specify multiple MatchPaths entries. If more than one MatchPath entry is specified, the Network Access Scope produces findings for any path that satisfies at least one of the MatchPath conditions.

ExcludePaths entries

A Network Access Scope can optionally define one or more ExcludePath entries. If a Network Access Scope defines any ExcludePaths, the Network Access Scope produces findings only for paths that match at least one MatchPath entry, and that do not match any ExcludePath entries.

An ExcludePath entry consists of at least one of the following, or a combination: a source entry, a destination entry, and a ThroughResource entry. Each field is optional, but at least one must be defined. Source and destination entries have the same structure; each can define either a ResourceStatement or a PacketHeaderStatement, or both. A ThroughResource entry, if defined, must be a list containing exactly one element that contains a ResourceStatement.

If an ExcludePath statement specifies a source entry, only paths that start at a component that matches the ResourceStatement (if defined) and that start with a packet header that matches the PacketHeaderStatement (if defined) are excluded from the findings. If the ExcludePath statement specifies a destination entry, only paths that end at a component and with a packet header that matches the ResourceStatement and PacketHeaderStatement of the destination entry are excluded.

Unlike MatchPaths entries, an ExcludePath can optionally define a ThroughResource entry. A ThroughResource entry excludes paths that match a given ResourceStatement anywhere along the path (not just at the beginning or end of the path). An ExcludePath with a ThroughResource entry can be used to exclude paths that pass through a NAT gateway, load balancer, or other intermediate path, regardless of where the path starts or ends, or can be used in combination with a source entry, destination entry, or both.

Example Network Access Scopes

In this section, we show some examples of Network Access Scopes. These examples are provided in JSON format.

Example: Identify all traffic between two subnets

To identify traffic between two subnets (subnet-814424dd and subnet-d75133f9) that are intended to be isolated from each other, create an access scope with two MatchPath entries, as shown in the following example.

{ "MatchPaths": [ { "Source": { "ResourceStatement": { "Resources": [ "subnet-814424dd" ] } }, "Destination": { "ResourceStatement": { "Resources": [ "subnet-d75133f9" ] } } }, { "Source": { "ResourceStatement": { "Resources": [ "subnet-d75133f9" ] } }, "Destination": { "ResourceStatement": { "Resources": [ "subnet-814424dd" ] } } } ] }

The first MatchPath entry identifies any paths from ENIs in subnet-814424dd to ENIs in subnet-d75133f9; the second identifies any paths from ENIs in subnet-d75133f9 to ENIs in subnet-814424dd. Together, this network access scope identifies any traffic in either direction between the two subnets.

Instead of specifying the source and destinations as subnets, you can specify security groups (to identify any paths between the ENIs in those security groups), VPCs, or specific Amazon EC2 instances. You can also mix and match these (for example, to identify paths from a VPC to a security group).

Example: Use resource groups with Network Access Scopes

To identify paths to or from resources with specific resource tags, you can use AWS resource groups. With resource groups, you define a set of resources by their tags and their types. For example, to identify inbound (ingress) traffic to Amazon EC2 instances with the Bastion tag, create a resource group bastions as shown in the following example.

aws resource-groups create-group --name "bastions" --resource-query '{"Type":"TAG_FILTERS_1_0","Query": "{\"ResourceTypeFilters\":[\"AWS::EC2::Instance\"],\"TagFilters\":[{\"Key\":\"Bastion\"}]}"}'
{ "MatchPaths": [ { "Destination": { "ResourceStatement": { "Resources": [ "arn:aws:resource-groups:us-east-1:123456789012:group/bastions" ] } } } ] }

The preceding example identifies any inbound (ingress) paths to any Amazon EC2 instances with the bastion tag. To identify any inbound (ingress) paths to bastion hosts using a port other than port 22 (ssh), combine the MatchPath with an ExcludePath that specifies destination port 22, as shown in the following example.

{ "MatchPaths": [ { "Destination": { "ResourceStatement": { "Resources": [ "arn:aws:resource-groups:us-east-1:123456789012:group/bastions" ] } } } ], "ExcludePaths": [ { "Destination": { "PacketHeaderStatement": { "DestinationPorts": [ "22" ] } } } ] }

Example: Identify all inbound (ingress) traffic from the public internet, except for a trusted CIDR range

To identify traffic from the internet while excluding paths that start in a trusted address range, create a MatchPath entry with a source type of AWS::EC2::InternetGateway, and an ExcludePath entry that lists the trusted address ranges in SourceAddresses, as shown in the following example.

{ "MatchPaths": [ { "Source": { "ResourceStatement": { "ResourceTypes": [ "AWS::EC2::InternetGateway" ] } } } ], "ExcludePaths": [ { "Source": { "PacketHeaderStatement": { "SourceAddresses": [ "55.3.0.0/16" ] } } } ] }

In the preceding example, the MatchPath entry restricts findings to traffic starting at an internet gateway, while the ExcludePaths entry suppresses any findings where the packet starts with a source address in the range 55.3.0.0/16.

Example: Exclude traffic originating at the addresses in a prefix list rather than a CIDR range

To exclude traffic that originates at the addresses in a prefix list rather than a CIDR range, use the SourcePrefixLists field instead of the SourceAddresses field, as shown in the following example.

{ "MatchPaths": [ { "Source": { "ResourceStatement": { "ResourceTypes": [ "AWS::EC2::InternetGateway" ] } } } ], "ExcludePaths": [ { "Source": { "PacketHeaderStatement": { "SourcePrefixLists": [ "pl-02cd2c6b" ] } } } ] }

Example: Identify all outbound (egress) traffic to the public internet, excluding a trusted CIDR range

To create an access scope that identifies traffic to the public internet while excluding a trusted address range, specify destination fields in the MatchPath and ExcludePath entries, rather than source fields, as shown in the following example.

{ "MatchPaths": [ { "Destination": { "ResourceStatement": { "ResourceTypes": [ "AWS::EC2::InternetGateway" ] } } } ], "ExcludePaths": [ { "Destination": { "PacketHeaderStatement": { "DestinationAddresses": [ "55.3.0.0/16" ] } } } ] }

Example: Identify inbound (ingress) traffic that bypasses a network firewall

To identify any inbound (ingress) traffic into the ENIs in a subnet that bypasses a middlebox such as a network firewall or load balancer, use an ExcludePath entry with a ThroughResource argument. In the following example, we assume that the subnet in question is subnet-814424dd.

{ "MatchPaths": [ { "Source": { "ResourceStatement": { "ResourceTypes": [ "AWS::EC2::InternetGateway" ] } }, "Destination": { "ResourceStatement": { "Resources": [ "subnet-814424dd" ] } } } ], "ExcludePaths": [ { "ThroughResources": [ { "ResourceStatement": { "ResourceTypes": [ "AWS::NetworkFirewall::Firewall" ] } } ] } ] }

Example: Identify traffic to ENIs that are members of a particular security group

To identify any traffic to ENIs that are members of a particular security group rather than a subnet, you can specify a security group as the destination resource, as shown in the following example.

{ "MatchPaths": [ { "Source": { "ResourceStatement": { "ResourceTypes": [ "AWS::EC2::InternetGateway" ] } }, "Destination": { "ResourceStatement": { "Resources": [ "sg-f15d59b3" ] } } } ], "ExcludePaths": [ { "ThroughResources": [ { "ResourceStatement": { "ResourceTypes": [ "AWS::NetworkFirewall::Firewall" ] } } ] } ] }