Skip to end of banner
Go to start of banner

SecurityHub: locking down default VPC security group

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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
egress: all traffic

docker registry runs with test-docker-registry-sg (in 5000/443/22/8080/all, out all/all) and vpc-VpnSecurityGroup-1USYMWX91V47W (10.1/10.50)

synapsedev

synapse-dev-vpc

10.24.0.0/16

ingress: all traffic from sg
egress: all traffic

build-system* run with synapse-dev-vpc-2-VpnSecurityGroup-1SXIOCN3K0C9S (10.50.0.0)

build-system-syanpse-2-agent* run with synapse-dev-vpc-2-VpnSecurityGroup-1SXIOCN3K0C9S and build-system-synapse-2-access-sg (access from master nodde)

dev instances run in synapse-dev-vpc with own 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
egress: all traffic

synapsedev

fargate

10.0.0.0/16

ingress: all traffic from sg
egress: all traffic

Test

synapsedev

na (vpc-0390*)

172.30.0.0/16

ingress: all traffic from sg
egress: all traffic

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

build-syanpse-dw runs in synapsedw-vpc with vpc-VpnSecurityGroup-1RPPAGWIIS4WM

redash runs in synapsedw-vpc with vpc-VpnSecurityGroup-1RPPAGWIIS4WM and sagebase-tgw-spoke-a-SecurityGroup-XDDFWGFLMUCV (???)

instances run in synapsedw-vpc with vpc-VpnSecurityGroup-1RPPAGWIIS4WM and awseb-e-8mm44ycdwj-stack-AWSEBSecurityGroup-T7YRYS56EVI1 (allow 22 from anywhere?)

RDS instances run in synapsedw-vpc with vpc-VpnSecurityGroup-1RPPAGWIIS4WM and dwapp2019-DBSecurityGroup-MIQXQT1OH0G

synapsedw

na (vpc-b17*)

172.31.0.0/16

ingress: 5439 from sg, hutch, all; 22 from hutch
egress: all traffic

This was used for Redshift

synapsedw

na (vpc-19ea*)

172.30.0.0/16

ingress: 3306 from anywhere
egress: all traffic

synapsedw

na (vpc-d5f9*)

172.30.0.0/16

ingress: all traffic from sg
egress: all traffic

synapseprod

sage-default-vpc

10.11.0.0/16

ingress: all traffic from sg
egress: all traffic

synapseprod

synapse-ops-vpc2

10.30.0.0/16

ingress: all traffic from sg
egress: all traffic

build-system-ops runs in synapse-ops-vpc-v2-VpnSecurityGroup-V299R6HJ8YM

docker instances run in synapse-ops-vpc-v2-VpnSecurityGroup-V299R6HJ8YM) and docker-reg-inst-sg

synapseprod

synapse-prod-vpc

10.20.0.0/16

ingress: all traffic from sg
egress: all traffic

all stack instances run in own security groups

rds run in their own stack 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:

  1. Remove all VPCs that are not needed.

  2. 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).

  3. Remove all unused security groups from the Synapse accounts.

  • No labels