Ensure no security groups allow ingress from wide-open non-RFC1918 address. False positive

[mikkoc]

Steps to Reproduce

Running prowler on AWS, sending findings to aggregate to SecHub.

The following finding is triggered with HIGH.

Ensure no security groups allow ingress from wide-open non-RFC1918 address.

The Security Group in question does not have any ingress rule. It has however 60 outbound rules.

Expected behavior

No finding should be triggered at all.

Actual Result with Screenshots or Logs

How did you install Prowler?

From pip package (pip install prowler)

Environment Resource

CodeBuild

OS used

AL 2023

Prowler version

4.3.3

Pip version

24.0

Context

The Security group is created via Terraform:

data "github_ip_ranges" "this" {}

resource "aws_security_group" "github" {
  name        = "github"
  description = "Allows outbound access to Github"
  vpc_id      = var.vpc_id
  tags = {
    Name : "github"
  }

  egress {
    description = "Allow Github SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = data.github_ip_ranges.this.git_ipv4
  }
  egress {
    description = "Allow Github HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = data.github_ip_ranges.this.git_ipv4
  }
}

[thejaywhy]

Hi @mikkoc , thanks for using Prowler 🚀 !

The ec2_securitygroup_allow_wide_open_public_ipv4 check looks at both ingress and egress, you can see the egress check here:

prowler/prowler/providers/aws/services/ec2/ec2_securitygroup_allow_wide_open_public_ipv4/ec2_securitygroup_allow_wide_open_public_ipv4.py

Lines 41 to 53 in d8d348f

	# Loop through every security group's egress rule and check it
	for egress_rule in security_group.egress_rules:
	for ipv4 in egress_rule["IpRanges"]:
	ip = ipaddress.ip_network(ipv4["CidrIp"])
	# Check if IP is public according to RFC1918 and if 0 < prefixlen < 24
	if (
	ip.is_global
	and ip.prefixlen < cidr_treshold
	and ip.prefixlen > 0
	):
	report.status = "FAIL"
	report.status_extended = f"Security group {security_group.name} ({security_group.id}) has potential wide-open non-RFC1918 address {ipv4['CidrIp']} in egress rule."
	break

For many organizations, public egress is a security concern. If you want to accept this finding, you can use the Prowler Mutelist feature: https://docs.prowler.com/projects/prowler-open-source/en/latest/tutorials/mutelist/ . This should keep Prowler from reporting the finding to Security Hub.

Does this make sense?

[mikkoc]

Hello, @thejaywhy.

In this case I suggest changing the title to ingress or egress, so it is clearer that both directions are checked. Or alternatively, have a separate check for egress ?
I also don't think egress should have the same criticality than ingress (HIGH)...

As a matter of fact, we have other Security Groups which allow egress and ingress to/from 0.0.0.0/0 on 443 but they are not flagged by Prowler. Is 443 considered OK?

The SG in question allows egress 443 and 22 on a /20 CIDR range, and it gets flagged. Very confusing.

[pedrooot]

Hi! @mikkoc how are you? Regarding to the SG not flagged by Prowler, are these SG in use? We check this inside the check, and if not used, it won't be flagged by Prowler. You can find more info related with this here.

Btw, we will change this check metadata to explain that currently, we are checking ingress and egress rules.

I created this issue-> #4945 so you can track the progress on these tasks

[mikkoc]

Hello @pedrooot, I'm fine thanks and you?

The SGs are definitely in use. One is attached to our public ALB, and it allows ingress on 443 from 0.0.0.0/0
The other one is attached to all our EKS EC2 nodes (100+) and allows egress to 443 to 0.0.0.0/0
I cannot find either of them in the Prowler findings, see screenshot.

[pedrooot]

Checking this! Thanks for the info, I'll ping you with the solution for this issue.

[pedrooot]

Hi! @mikkoc This check had a bad metadata, it only ensures that the netmask from the IPs are between 0 and 24 but both are not included. This is the reason why Prowler is not raising Failed findings for your SG configuration related with 0.0.0.0/0 and 443 port.