The main principle of a security group is that the most permissive rule wins.

A port is a concept specific to TCP and UDP protocols that operate at the transport layer (Layer 4). If you allow any IP protocol (-1) in your rule, you're essentially saying, 'I don't care about the protocol; just work at the IP network layer (Layer 3).' Such a rule not only disregards ports but also overrides any other protocol-oriented rules you have specified in your set (as it operates at a lower layer).

If used consciously, there is nothing wrong with this so far.

So let's check if the AWS tooling lets you do anything risky with that setting:

• UI doesn't even allow you to provide ports in such conditions(protocol set to -1),

• Terraform won't let you do this as well; with such a code:

resource "aws_security_group" "example" { name = "MySecurityGroup" description = "My security group" vpc_id = "*"

ingress { from_port = 666 to_port = 666 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } }

it throws an error: updating Security Group (*) ingress rules: updating rules: from_port (666) and to_port (666) must both be 0 to use the 'ALL' "-1" protocol!

• only the CLI allows that, but it must be admitted that in its output, it tells you exactly what it has done:

aws ec2 authorize-security-group-ingress \ --group-id $security_group_id \ --protocol -1 \ --port 666 \ --cidr 0.0.0.0/0

{ "Return": true, "SecurityGroupRules": [ { "SecurityGroupRuleId": "", "GroupId": "", "GroupOwnerId": "*", "IsEgress": false, "IpProtocol": "-1", "FromPort": -1, "ToPort": -1, "CidrIpv4": "0.0.0.0/0" } ] }

Consent on one matter: awareness! :)