org.sonar.l10n.py.rules.python.S6463.html Maven / Gradle / Ivy
Allowing unrestricted outbound communications can lead to data leaks.
When a security group allows all outbound communications, applications or services within the security group can send data to any external IP
address or port without restriction. If a resource within the security group becomes compromised, attackers could send malicious traffic or exfiltrate
data to external servers. This could happen even if the resource is not directly exposed to the internet, such as in case of a supply chain
attack.
When deciding if outgoing connections should be limited, consider that limiting the connections results in additional administration and
maintenance work.
Ask Yourself Whether
- The resource has access to sensitive data.
- The resource is part of a private network.
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
The principles of defence-in-depth and least privilege suggest that outbound connections should be restricted to a set of trusted destinations.
Consider restricting the security group egress rules so that it can only contact specific locations, such as trusted IP address ranges or other
security groups. If any resources require unrestricted outbound access, place them in their own security group.
Sensitive Code Example
For aws_cdk.aws_ec2.SecurityGroup:
from aws_cdk import (
aws_ec2 as ec2
)
ec2.SecurityGroup( # Sensitive; allow_all_outbound is enabled by default
self,
"example",
vpc=vpc
)
Compliant Solution
For aws_cdk.aws_ec2.SecurityGroup:
from aws_cdk import (
aws_ec2 as ec2
)
sg = ec2.SecurityGroup(
self,
"example",
vpc=vpc,
allow_all_outbound=False
)
sg.add_egress_rule(
peer=ec2.Peer.ipv4("203.0.113.127/32"),
connection=ec2.Port.tcp(443)
)
See
- AWS Documentation - Control traffic to resources using
security groups
- CWE - CWE-284 - Improper Access Control