Skip to main content

Command Palette

Search for a command to run...

AWS Security Groups are tricky!

Updated
2 min read
J

I started my professional career in 2012 as Systems Administrator and continued it until 2018 to become DevOps Engineer. I work with AWS since 2016 and I am 5 times certified AWS Specialist.

Recently I was configuring a security group for a service that uses TCP and UDP ports for ingress connectivity.

Security Groups are an Amazon Web Services feature for Amazon VPC (virtual private cloud) to set up a stateful firewall.

I used Terraform (Terragrunt actually, but that's a detail) to configure the security group's ingress rules.

I wanted to be a smart guy, so I have set the protocol to -1 which means "all protocols", so I didn't need to specify separate rules for TCP and UDP for the same port.

Here comes my surprise, according to the AWS documentation:

Use -1 to specify all protocols. If you specify -1 or a protocol other than tcp, udp, or icmp, traffic on all ports is allowed, regardless of any ports you specify.

I was not aware of that and you might not be aware too!

Honestly, I would expect the AWS API to return an error, or at least a warning, when trying to set a configuration that is impossible to set - it either didn't happen or was silenced in the Terraform provider for AWS (I didn't verify, I suspect the AWS API doesn't give any feedback about that).

It was caught by my workmate who eventually made separate entries for TCP and UDP to get the configuration right - shortcuts, although tempting, are not always good solutions.

T

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! :)

1
J

Thank you for the clarification Tomek!

I was not really aware of the networking specifics that cause the behaviour of using all protocols, I'm not that fluent with networks - and I believe more people might also not understand the underlying reason so your comment brings a great value here!

I had successfully set -1 as protocol with Terraform but perhaps I used older provider when I did so - unfortunately I'm not able to verify that anymore as I don't continue that project.

More from this blog

Diving DevOps

11 posts

DevOps specialist in AWS, Terraform, Docker. Holder of five AWS certs, on the journey to becoming a Kubernetes pro. Navigating the ever-evolving tech landscape with precision.