SecurityHub: locking down default VPC security group
- Xavier Schildwachter
Issue
We enabled SecurityHub on AWS accounts, one the findings is that the default VPC security group is too permissive.
[CIS.4.3] A VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. It is recommended that the default security group restrict all traffic.
Remediation
The recommended mediation for this finding is to lock down the security group by removing all its ingress and egress rules. There does not appear to be way to configure a locked down security group at creation time (https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/658 ) so solutions require deleting the rules after the VPC and the security group have been created (via console, API (CLI/script/custom resource).
Note: AWS Config ‘VPC_DEFAULT_SECURITY_GROUP_CLOSED’ says ‘The rule is NON_COMPLIANT if the default security group has one or more inbound or outbound traffic rules.’ so solutions that would add rules (to restrict to localhost for example) would fail.
Current usage of default VPC security group
Before making any change to the default VPC security group, we need to assess its use in each of our VPCs. Below are lists of VPCs in each Synapse account and the rules for the default security groups.
account | vpc | cidr | rules | comment |
|---|---|---|---|---|
synapsedev | sagevpc | 10.11.0.0/16 | ingress: all traffic from sg |
|
synapsedev | synapse-dev-vpc | 10.24.0.0/16 | ingress: all traffic from sg |
rds warehouse (in 3306 from 207.109.76.122/32, 67.160.76.137, workers; out all) ==> still used? |
synapsedev | na (vpc-2ae*) | 172.30.0.0/16 | ingress: 8787/443/8443/22 from anywhere |
|
synapsedev | fargate | 10.0.0.0/16 | ingress: all traffic from sg | Test |
synapsedev | na (vpc-0390*) | 172.30.0.0/16 | ingress: all traffic from sg |
|
synapsedw | synapsedw-vpc | 10.12.0.0/16 | ingress: 3306 from 10.12.0.0/16 and 10.50.0.0/16 egress: all traffic |
|
synapsedw | na (vpc-b17*) | 172.31.0.0/16 | ingress: 5439 from sg, hutch, all; 22 from hutch | This was used for Redshift |
synapsedw | na (vpc-19ea*) | 172.30.0.0/16 | ingress: 3306 from anywhere |
|
synapsedw | na ( | 172.30.0.0/16 | ingress: all traffic from sg |
|
synapseprod | sage-default-vpc | 10.11.0.0/16 | ingress: all traffic from sg |
|
synapseprod | synapse-ops-vpc2 | 10.30.0.0/16 | ingress: all traffic from sg |
|
synapseprod | synapse-prod-vpc | 10.20.0.0/16 | ingress: all traffic from sg |
|
A cursory look at the default VPC security group usage shows that we don’t use that security group so we can modify it as needed. Note: each account has quite a number of security groups (SynapseDev:152, SynapseDW:34, SynapseProd: 32), most of them should be unused and should be deleted.
Recommendations:
Remove all VPCs that are not needed.
Write a custom resource that removes all the rules from the default security group of a given VPC (and thus makes us compliant). Note: could also be done programatically in Stack builder but DW for example does not use stack builder (and custom resource could be used for other accounts managed by IT).
Remove all unused security groups from the Synapse accounts.