Ensure no security groups allow ingress from 0.0.0.0/0 to SSH (TCP:22)
AWS Security Groupgsl logic
Dome9 rules are powered by the Governance Specification Language (GSL). GSL allows our customers to write and run custom security and compliance checks that can be easily read
Learn more:
Compliance Engine
GSL Language
Remediation
Removing unfettered connectivity to remote console services, such as SSH, reduces a server's exposure to risk.
From Portal
1. Login to the AWS Management Console and open Amazon VPC console https://console.aws.amazon.com/vpc/home
2. In the navigation pane, choose Security Groups.
3. For each security group, perform the following:
4. Select the security group
5. Click the Inbound Rules tab
6. Identify the rules to be removed
7. Edit the inbound rule , change the source cidr range or Delete the rule.
8. Click Save
From TF
Add CIDR range to restrict ingress access to port 22.
resource "aws_security_group" "test" {
name = "allow_tls4"
description = "Allow TLS inbound traffic"
ingress {
description = "TLS from VPC"
from_port = 22
to_port = 22
protocol = "tcp"
- cidr_blocks = ["0.0.0.0/0"]
+ cidr_blocks = ["10.92.168.0/28"]
}
}
From Command Line
To make sure security groups doesn't allow ingress from 0.0.0.0/0 to SSH (TCP:22), run:
aws ec2 revoke-security-group-ingress --region REGION --group-name GROUP-NAME --protocol PROTOCOL --port 22 --cidr 0.0.0.0/0
References
1. https://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf
2. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
3. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/revoke-security-group-ingress.html?highlight=ingress
4. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group#ingress
Auto Remediation Using Cloudbots
What it does: Deletes a single rule on a security group Usage:
sg_single_rule_delete split=<true|false> protocol=<TCP|UDP>
scope=<a.b.c.d/e> direction=<inbound|outbound> port= Example: sg_single_rule_delete split=false protocol=TCP
scope=0.0.0.0/0 direction=inbound port=22 Sample GSL: SecurityGroup
should not have inboundRules with [scope = '0.0.0.0/0' and port<=22
and portTo>=22] Conditions and caveats: Deleting a single rule on a security group can
be difficult because the problematic port can be nested within a wider
range of ports. If SSH is open because a SG has all of TCP open, do you
want to delete the whole rule or would you break up the SG into the same
scope but port 0-21 and a second rule for 23-end of TCP port range?
Currently the way this is being addressed is using the 'split'
parameter. If it's set as false, CloudBots will only look for the
specific port in question. If it's nested within a larger port scope,
it'll be skipped. If you set split to true, then the whole rule that the
problematic port is nested in will be removed and 2 split rules will be
added in its place (ex: if port 1-30 is open and you want to remove SSH,
the new rules will be for port 1-21 and port 23-30). If you want to delete a rule that is open on ALL ports:
Put Port 0 as the port to be deleted and the bot will remove the rule.
If you want to delete a rule that is open to ALL :
Put protocol=ALL and the bot will remove the open rule that configured with ALL as protocol
If you want to delete a rule that is open no matter to the configured protocol
Put protocol=* and the bot will remove the open rule Limitations: IPv6 is not supported
cloudbot_name: sg_single_rule_delete
Set Split to True
sg_single_rule_delete split=true protocol=TCP scope=8.8.8.8/32 direction=inbound port=0
AWS Security Group
A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign up to five security groups to the instance. Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC could be assigned to a different set of security groups. If you don't specify a particular group at launch time, the instance is automatically assigned to the default security group for the VPC.
Related Links:
Security Groups for Your VPC
Compliance Frameworks
