Remove default security group from EC2-Instance

[elgohr]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave "+1" or "me too" comments. They generate extra noise for issue followers and do not help prioritize the request.

Tell us about your request When using aws:autoscaling:launchconfiguration:SecurityGroups (https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalinglaunchconfiguration) the defined groups are added to the EC2-Instance. Nevertheless a default group is also added to the instance. How can this be removed?

Is this request specific to an Elastic Beanstalk platform? If so, which one(s)? multi-container-docker-18.09.9-ce-(generic)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem. Security hardening.

Are you currently working around this issue? How are you currently solving this problem? No workaround. Edit 2023-02-05: You could try working around by putting the Beanstalk into a VPC with a private subnet (https://github.com/aws/elastic-beanstalk-roadmap/issues/44#issuecomment-1412494926).

[karl-cardenas-coding]

I don't understand why a security-group has to be created when we specify our own. From an enterprise perspective, this is often an anti-pattern as Cloud Enablement teams generate approved security groups.

[jbm00n]

If I understand this case correctly, it's not specific to a platform. We faced the same issue with the Java platform.

To work around it we had to implement couple of hacks.

1) Define "AWSEBSecurityGroup: { "CmpFn::Remove" : {} }" within an ebextension, that would remove the extra security group on the fly during deployment.

2) However, later we enabled the EC2 keypair access, and that forces the EB group to stay (previous statement does not work), as it defines the SSH port 22 to be open on all (due to the keypair). The only workaround left is that you can define the IP/group restriction on this port. As we use the keypair for SSH tunneling via SSM, the SSH port is not required at all in our case.

Therefore we set the port 22 "incomings" to the same security group of the EC2 instance (application security group). That limits the port 22 to be used by the EB instances only. (aws:autoscaling:launchconfiguration with OptionName: SSHSourceRestriction)

All in all, I agree that if we specify our own custom security group, EB shouldn't force a default, partly redundant and potentially less secure security group.

[derandreasberger]

Hello, we're seeing the same issue when specifying a EC2-keypair a new AWS generated Security Group gets added which opens Port 22 for 0.0.0.0/0. This group was not there before and using "https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/community-provided/security-configuration/securitygroup-disable-auto-use-existing.config" approach I would have assumed no new groups get added by such a change.

"All in all, I agree that if we specify our own custom security group, EB shouldn't force a default, partly redundant and potentially less secure security group." I totally agree.

[ExploHash]

We also have this issue, we currently deploy almost all environments with cloudformation and tried to restrict http access on our development environment. This wasn't possible because the default security groups allows everyone on port 80. Currently fixed it with the above proposal.

[rahulrajaram]

Thanks everybody for voicing your concerns. The default EC2 SG, and the additional EC2 SGs that customers are allowed to pass serve two different purposes. Whereas EB will use the default SG to open it to the LB, the additional SGs customer are allowed to pass are simply attached to the EC2 instances; EB maintains that these SGs will not be manipulated.

So, we cannot simply prevent the default security group from being created because doing so would break backwards compatibility. However, we can possibly look into providing a way for you to direct EB not to create the default SG through an option setting in the aws:autoscaling:launchconfiguration. This would also prevent creation of the default SG if EC2KeyName is specified.

Is this a feasible solution to your problem?

[KasperFranz]

Thanks everybody for voicing your concerns. The default EC2 SG, and the additional EC2 SGs that customers are allowed to pass serve two different purposes. Whereas EB will use the default SG to open it to the LB, the additional SGs customer are allowed to pass are simply attached to the EC2 instances; EB maintains that these SGs will not be manipulated.

So, we cannot simply prevent the default security group from being created because doing so would break backwards compatibility. However, we can possibly look into providing a way for you to direct EB not to create the default SG through an option setting in the aws:autoscaling:launchconfiguration. This would also prevent creation of the default SG if EC2KeyName is specified.

Is this a feasible solution to your problem?

For my use-case that would be a very viable option

[karl-cardenas-coding]

@rahulrajaram yes this would work for my organizations usecase.

[ExploHash]

@rahulrajaram Yes, that would be awesome! Thanks for noticing our concerns

[elgohr]

@rahulrajaram Looks good. The SG is also used in a single instance setup, guess this can be removed then?

[rahulrajaram]

@elgohr , yes, it would make most sense from the usability perspective to keep the behaviour consistent across all types of environments.

[vjsingh]

@rahulrajaram thanks that would solve our problem as well !

Any idea on an ETA? Thank you,

[marns93]

@rahulrajaram it works for our usecases as well. Do you have any updates for us? :)

[E-Rockalanche]

@rahulrajaram This is the solution I've been looking for. That would be awesome

[navaganeshr]

can i know if the new option setting to disable auto-creation of default security group under aws:autoscaling:launchconfiguration is released or not ?

[urkle]

@navaganeshr It seems they did add this (just not documented well) See SSHSourceRestriction in https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalinglaunchconfiguration

[fferreira-lucid]

@urkle I don't think that it's the same. We're asking them the ability to create EB envs/apps without creating a security group so we can use a pre-existing one managed by ourselves in its place. What the SSHSourceRestriction does is modify the SSH rules that exists in the SG that EB is going to create during creation-time.

It's a valid workaround IMO, but it still creates a new SG with a some-what random name.

[urkle]

It's a valid workaround IMO, but it still creates a new SG with a some-what random name.

@fferreira-lucid I totaly agree that it is a horrible workaround. IMHO it would be better to have a simple option to DISABLE the SG creation as I couldn't even get the SSHSourceRestriction to work (as it claims to be able to reference an existing SG).. So in the end I just turned off SSH completely for now.

[Nicko-13]

Any updates on this issue? I have created my own security groups for ALB and EC2 and created the stack with CloudFormation template. I need custom security group to allow traffic from EC2 to RDS instance. With this pesky default security group I am not sure that the traffic will go from desired security. For production https can be set, but still having default group is really disappointing

[rahulrajaram]

This is being actively worked on by the team as we speak.

[jameseggers]

Hi @rahulrajaram - do you have any updates here?

[ryota-saito-0309]

Hello I'm looking forward to the update. @rahulrajaram - Is there an update to the issue?

[brandong954]

This is bananas. How has such a security vulnerability not been resolved yet? At least there's a workaround for port 22 (i.e. SSHSourceRestriction), but there's also port 80, in my case, still being exposed to the outside world for a development server. Please update us on the status @rahulrajaram.

Here's the ebsextension config to restrict port 22 for anyone else in need of it:

option_settings:
  aws:autoscaling:launchconfiguration:
    SSHSourceRestriction: 'tcp, 22, 22, your-custom-sg-id'

[michaelbrewer]

Why would you assume opening port 22 to the world was something you would want to do? Please allow for security groups to be managed separately.

[mdesouky]

I'm surprised to see AWS opening holes in customers security on purpose ? nobody ever thought this was a good idea, at least give us a stack parameter/option to disable it

[michaelbrewer]

@mdesouky - i would recommend never assigning a public ip address to the EC2 instances or assigning a SSH keypair.

Instead, use SSM agent to access the servers via the AWS Console.

[mdesouky]

@michaelbrewer that's what I thought people did, I just actually found about this 30 minutes ago, I've just joined my team and they have been using EB so I wasn't around during creation and currently the devs use SSM to get in via the console like you said but unfortunately the instances are publicly accessible and they are getting hammered with SSH attempts

[michaelbrewer]

@mdesouky - yes, unfortunately as soon as you assign a key pair AWS will create a security group that opens port 22 to the world. Also the console won't let you remove the keypair, so you need to use the cli ($ENV would be your beanstalk name):

aws elasticbeanstalk update-environment --environment-name $ENV \ --options-to-remove 'Namespace=aws:autoscaling:launchconfiguration,OptionName=EC2KeyName'

Also note, if you manually part the security group, it won' last for long, as when you do an environment rebuild the port will be opened up again.

[dgagnon]

You can restrict the port using a .config file. I use the following in Terraform to restrict to our bastion host as a backup in case SSM as a problem:

  setting {
    name      = "SSHSourceRestriction"
    namespace = "aws:autoscaling:launchconfiguration"
    resource  = ""
    value     = "tcp,22,22,${var.wks_ip}/32"
  }

See : https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-autoscalinglaunchconfiguration

As for the port 80 being open by default, we use the application load-balancer and add a https 443 port with a AWS certificate and disable the port 80 in the load-balancer. As long as you use NAT instances and not a EIP, the port 80 won't be open from the outside.

[michaelbrewer]

@dgagnon i would just use SSM and then there is no more need of a bastion host. And then you can use Amazon SSO to control who has access.

[U3R1YXJ0]

I would like to mention my use case here. I (try to) use security groups to prevent access to my ELB servers other than from CloudFront. This is essential to our security as without CloudFront, our server is open to all sorts of direct attacks, such as DDOS.

The instructions I use to set this up are from AWS: https://aws.amazon.com/blogs/security/automatically-update-security-groups-for-amazon-cloudfront-ip-ranges-using-aws-lambda/ https://github.com/aws-samples/aws-cloudfront-samples

"When you use CloudFront to secure your web applications, it’s important to ensure that only CloudFront can access your origin"

Unfortunately this post and the effort I went to is rather pointless, as ELB keeps adding the default security group back in.

[cafuentes]

direct EB not to create the default SG

Any chance the option to direct EB not to create the default SG will be available in the AWS Console as well. I don't use the cli much nor have the need for .ebextensions for our setup so I would prefer to just tick a checkbox during create in the console. Currently my non load balanced environments end up with port 22 and 80 open to the world even tho I have specified specific security groups to specifically restrict/manage this access.

[icc]

Is the team still actively working on this? @rahulrajaram

[racsus]

+1

[connerat]

@rahulrajaram since it appears from your LinkedIn page that you no longer work at AWS, is there a way you can assign this to a former colleague? Thanks!

[Ati59]

👍

[benmotyka2]

+1

[mspell-foreflight]

@1tonyca This issue seems to be assigned to someone who no longer works at AWS. I see you moved it to in progress in September of 2021 and there are still no branches or PRs. Can we do something to jiggle the handle here and get this worked on? There is a ton of interest for this and it's a massive security issue that requires custom solutions to resolve currently.

Thanks!

[andrius-paurys]

Much needed update - the default rule is a really annoying security pitfall.

[elgohr]

We solved this issue by stopping to use Beanstalk.

[lisenet]

So Beanstalk won't let you select a previous version of a platform calling it a "security risk to our customers", but this is acceptable?

[dgagnon]

@lisenet the recommended setup includes private subnets, which won't allow inbound connections to your instances from the internet. See https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.vpc.html

[lisenet]

@dgagnon but it does allow all outbound traffic to the Internet which is a security risk. How does one remove the default Beanstalk SG?

[dgagnon]

@lisenet The default security group only opens inbound SSH. Outbound is open by default on all security groups.

To completely remove outbound internet access from EB instances, you would need VPC endpoints for every service you use from AWS plus all the updates and packages already built in to your AMI.

EB also allows you to specify specific security groups for LB and instances, you can add restrictions using these.

[elgohr]

@dgagnon where did you get the information that this is the recommended setup?

Didn’t find a word in the security best practices (https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/security-best-practices.html) or general Beanstalk security guidelines (https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/security.html).

I’m sorry, but letting customers tinker custom VPC-solutions to stuff default security holes isn’t my understanding of Cloud security at AWS is the highest priority.

[dgagnon]

@elgohr that link pertains to the security aspects specific to elastic beanstalk. For VPC related security, you can look at this link: https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html

Edit: I recommend the following guide as well: https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html

[elgohr]

@dgagnon so I'm buying a PaaS solution to patch the IaaS inside the solution? Did I get that correct?

[dgagnon]

@elgohr no you did not.

[lisenet]

@dgagnon

Outbound is open by default on all security groups.

That's precisely the problem. We want to be able to control outbound traffic by using SGs. How is having a default SG that allows all traffic to leave the network best practice?

[dgagnon]

@lisenet If you need that level of security, manage the NAT instances yourself instead of using NAT Gateways. We use pfSense and it works great in that regard. You can even install SSM agent on it although not many of the automations supports FreeBSD properly.

[janzelc-trifecta]

@lisenet If you need that level of security, manage the NAT instances yourself instead of using NAT Gateways. We use pfSense and it works great in that regard. You can even install SSM agent on it although not many of the automations supports FreeBSD properly.

This doesn't resolve the issue. Egress for instances should explicitly defined and that cannot be achieved by using the default security group. It's not just instance traffic egressing to the internet.