New Check - ec2_securitygroup_allow_ingress_from_internet_to_any_port_from_ip

[jmanduca-psfy]

New feature motivation

Due to a trend where developers add their personal home IP addresses to SGs for various connectivity, I want to know which Security Groups have these explicit holes in them. Especially if the developer no longer should have access to the resource.
Also, if an attacker gets hold of AWS credentials and wants to open ingress to an EC2 instance (or publicly accessible RDS or other resource), they are likely to use a single/small range of IPs, potentially on an obscure port.

Solution Proposed

An expansion of the ec2_securitygroup_allow_ingress_from_internet_to_any_port check to include any non-internal IP addresses, that way getting the SG itself checked and monitored.
Or could build off the ec2_instance_port_*_exposed_to_internet rule, check for any port exposed to an internet IP address.
Due to the nature of these kind of rules, it would likely be a medium or low severity finding.

Describe alternatives you've considered

N/A?

Additional context

No response

[christiandavilakoobin]

There are a lot of cases where is needed to open to a external IP and not for developers, such as integrations with third parties, or instances in another VPCs. I agree is a very bad practice to open SG to developers IP, and they should use another system (we have a SSO auth, check the user privileges, check the device compliance, and then we open temporary the SG to that IP), but add this restriction to prowler will cause a lot of people to mute this alert, and potentially hide real exposures.

[jfagoagas]

This is an interesting conversation, I'm adding @pedrooot @MrCloudSec here, what do you think?

[jmanduca-psfy]

My take is that these direct rules are the (cheap and easy and secure enough) way to connect between all sorts of services when VPN or other network tunnels are overkill or not feasible. However, these rules need to be inventoried and reviewed, and as stated before an easy way to get around other config checks if a bad actor has access to create them.
I would also rather have more rules to work with that can be muted than not have a rule at all - after all that is the purpose of the mutelist to ignore alerts on business requirement needs/risk tolerance differences.

[christiandavilakoobin]

I'm not sure if I'm following you. You say that those rules are cheap and secure, so is good to use them, but they may be reviewed. I agree, but this check won't do that. This check will throw an alert that there is some IP open. If they're using them, they'll mute this rule, and if any bad actor has access to create them, they won't see that. The rule will only be effective if the mutelist has some mechanism to mute only crertain IP or to know how many time passed since some IP was added to the SG.

[pedrooot]

Currently, the ec2_securitygroup_allow_ingress_from_internet_to_any_port_from_ip check will not trigger a FAIL even if an open IP is present in some cases configured through Prowler’s configuration. My point here is that a universal check cannot be created since each user has a unique use case and type of configuration for these scenarios. However, we could make this check a bit more flexible by allowing users to add certain IP ranges to Prowler’s configuration, marking them as “safe” for their use.

This also brings up the security dilemma: if it’s genuinely not a best practice, should we ignore it? On the other hand, it ultimately falls under the user’s responsibility—they configure it as they see fit.

Regarding the mutelist, it could have a positive impact as well. The downside is that its highest level of configuration is at the resource, tag, or region level, but not at the IP level. Could we consider introducing a list of valid IPs for certain types of resources?

[jmanduca-psfy]

My point here is that a universal check cannot be created since each user has a unique use case and type of configuration for these scenarios

My argument against that for not having a check is that this case already exists for other rules (ex. we need to ignore things like iam_root_hardware_mfa_enabled because our structure is not suitable to hardware MFA, yet this is listed as a critical item). There are also many low and medium findings that are only relevant depending on use case, but checks still exist.

Right now Prowler looks at the SG resources as a whole - is it possible to flag specific SG Rules? They have unique IDs, but I am not familiar with that part of the AWS API/Prowler check to know how much work that would be, but it would allow for mutelisting at the individual rule level instead of an SG level. It also has the potential to be much more noisy?

Maybe there is a case for an "informational" category, below "low"? Not sure if Prowler wants to get to that level of granularity, but it is a common category for vulnerability scanners.