Externally allowed port range needs review

Description

Allowing ports with no confirmed purpose, or broad port ranges, from every IPv4 or IPv6 address can make unintended services reachable. A nonstandard port is not inherently vulnerable, and using a familiar port number does not establish safety. Review the actual service, protocol and need for public access.

Potential impact

Reachable temporary services or debug functions can face external connections and exploitation attempts.
Rules with unclear ownership or purpose can persist and complicate change management and incident response.

Remediation

Identify each port's service owner and communication purpose, and remove unnecessary rules. Limit required ranges to actual service requirements.
Permit only approved sources and restrict administration to private paths or controlled management services. Review IPv4 and IPv6 permissions.
Check actual listening services, every attached security group and host controls. Test that required communication works and unwanted connections are blocked.

Examples

Supply an actual VPC ID. Instance attachment and service configuration are not included. This comparison assumes TCP 23–25 is unnecessary and only an internal HTTPS application is required. Replace the second example's IPv4 range with actual clients; add a separately restricted rule if IPv6 clients need access.

Before

yaml

Parameters:
  VpcId:
    Type: AWS::EC2::VPC::Id
Resources:
  InstanceSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Unrestricted source access to a port range
      VpcId: !Ref VpcId
  PortIngress:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !Ref InstanceSecurityGroup
      IpProtocol: tcp
      FromPort: 23
      ToPort: 25
      CidrIpv6: "::/0"

This allows TCP 23–25 from every IPv6 address. The range includes ports commonly used by Telnet (23) and SMTP (25), but the actual services still need verification.

After