I'm puzzled by the role played by several groups that seem to have been added automatically to my list of AWS security groups, connected in what I gather is the default configuration, and wonder how they work (and what about them it is safe to change). Specifically there are three that are mysterious:
launch-wizard-1 which has an inbound rule SSH, TCP, 22, 0.0.0.0/0.
default described as "default VPC security group" which has an inbound rule for all traffic and all ports that uses itself as a source.
default_elb_... described as "ELB created security group used when no security group is specified during ELB creation - modifications could impact traffic to future ELBs" which has an inbound rule allowing HTTP from all IP addresses
The first two do not appear to be connected to any other security groups, while the latter is the source for a for an inbound HTTP rule in each of the security groups for my Elastic Beanstalk environments.
What do these do three groups do? Can I change them? Or change connections to them?
For example, the latter rule seems to have the effect of allowing HTTP traffic from anywhere to all of my EB environments. Can I change this rule to limit IPs (to to all environments)? Can I "un hook" the rule as a source from a given EB environment (e.g. replacing it as a source with a range of IPs)?
Looks like you've got a handle on what a security group is: a stateful firewall that is applied to EC2 instances.
When you manually launch an EC2 VM from the web console, AWS will provide you with the option of reusing an existing security group or creating a new one. When you create a new one, the default rule is SSH (port 22) and a default security group name of "launch-wizard-#".
Unfortunately, since a security group can be used by multiple EC2 instances, they are not cleaned up when you delete a VM. So if you deleted the VM that launch-wizard-1 was created with, it does not delete the security group.
Onto the "default security group for VPC". When you create your VPC, a default security group is created alongside with it. When EC2 instances are launched into a VPC subnet, they will have the default security group assigned to them if another is not specified. (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#DefaultSecurityGroup).
So what does that rule mean that allows it to talk to itself? By default, all inbound traffic is denied by a security group. This 'talk to itself' inbound rule indicates that if two VMs both have this rule assigned to them, they will be allowed to communicate with one another on all ports. Should you use this default group? No. Create unique security groups that exercise the rule of least privilege (only open the ports you need to the instances that need them).
Unfortunately, I do not have much elastic beanstalk experience, so this is where my answer turns to assumptions. In the little that I have played with beanstalk, I recall that it created auxiliary resources in your account. This appears to the be the case with your Elastic Load Balancer (ELB). As the description indicates, when Elastic Beanstalk needs to launch a new load balancer, the load balancer will use this default group unless you specify another. I believe that this link documents how you would do this (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.elb.html).
In all cases, I would recommend against using the default security groups in favor of individual firewall rules unique to that instance's security needs.
Can you change or delete these?
launch-wizard-1: Yes, you can delete or modify this group. Since you mentioned he is unused, go ahead and nuke him.
default: VPC is finicky about some of the default resources that it creates. I tested it on my account and I cannot delete it. You can of course modify it, but I'd recommend instead just not using it.
default_elb: If I remember properly, elastic beanstalk uses cloudformation to create additional resources, such as an ELB security group. You can modify this security group, but it will create inconsistencies between the cloudformation definition and reality. For your specific question, you can change the range of allowable IPs, but if you're writing rules on a private IP you won't be able to cross environments if the environments are deployed to separate VPCs.
Related
I have an elastic beanstalk app that uses a rethink-db instance as its database. The obvious thing to do would be to restrict access to the the database to only this application.
But if I set the relevant port in the security group of the Rethinkdb instance to anything other than 0.0.0.0, the application can't reach the DB.
The application is using the private DNS of the database for resolution and is in the same amazon region... as far as I understand, this alone should already get me passt the security group without any rules. Not in this case, apparently.
I have tried adding an exception for the applications security group to the databases security group on that port, as well as the security group of the load balancer of the application. I have also tried both at the same time. No dice.
The beanstalk-app is scalable, so it usually communicates from several instances that can change at a whim. Going over an elastic IP and allowing that in the databases security group is therefore not an option, unfortunately.
In the end, I'm forced to leave the security group of the rethink db on the driver port wide open at 0.0.0.0... Anything else I've tried made it unreachable for my own application.
Can anybody tell me what I'm doing wrong?
as far as I understand, this alone should already get me passt the
security group without any rules
That's not correct. You always have to have a security group rule to allow access. All inbound traffic is blocked by default.
I have tried adding an exception for the applications security group
to the databases security group on that port
That sounds like exactly what you need to do. You need to create an inbound rule in the security group assigned to the database server. In that rule you would specify the ID of the security group that the Elastic Beanstalk instances belong to.
If that isn't working, then you might need to post more information in your question, like the actual security group settings.
Also, you need to make sure your EB instances are trying to connect to the database server via the private IP of the DB server. Your issue sounds like maybe they are using the public IP of the DB server. I know you said they are using the private DNS of the DB server, but you need to make certain that is the case, and make certain that DNS is correctly resolving to the private IP, when referenced from the EB instances.
I have 2 AWS EC2 instances living inside 2 different subnets of my vpc.
I would like to allow the ruby app running on the first instance (say App#1) to call the endpoints of the app (say App#2) running on the 2nd instance.
I would also like my users to directly call the endpoints of App#2 from their browser.
Here is what I have tried (and mostly failed):
[Sucess!] I added the known IP addresses of my users to the inbound rules of Load Balancer Security Group of App#2 and have confirmed that they can access App#2 endpoints from their browsers.
[Fail!] I added the Load Balancer Security Group ID of App#1 to the inbound rules to the Load Balancer Security Group of App#2. But my logs tell me App#1 cannot access the endpoints of App#2.
[Fail!] I added the VPC Security Group ID of App#1 to the inbound rules of the Load Balancer Security Group of App#2 - nope, still doesn't work.
(Somehow, when I launched the instance for App#1, aws automatically created 2 security groups for this instance - one for VPC and one for load balancer... I have no idea why/how this happened...)
[Fail!] I added the CIDR for the subnet App#1 was in to the inbound rules of the Load Balancer Security Group of App#2. Still no joy.
[Success...Sort Of] I assigned an elastic IP for the instance running App#1 and added that to the inbound rules of the Load Balancer Security Group of App#2. This works but I would rather not use this method since I would like to elastically scale my App#1 in the future and I do not know how to automatically assign more elastic IPs for the new instances when they spin up, add them to the inbound rules, and then somehow remove them when they shut down.
I feel like there has got to be a really clean solution to this problem and I am probably missing something painfully obvious. Can someone please give me a hint?
Any help would be appreciated!
It sounds like you might be using the public IP address of your load balancer, so it looks like the traffic is coming from the outside. Try using the private IP/DNS if there is one, or setting up a second, internally-facing load balancer.
So App#2 is in public subnet, App#1 is in private subnet. For example, the diagram will be something like:
Internet => LB#2 => App#2:80 (in public subnet) => LB#1 => App#1:4567 (in private subnet)
Let's open all inbound rules in all instances and loadbalancers, check if you can access it via internet,
then apply security groups on each layer each time, don't change all of them at same time.
Let me know which layer has issue.
I am operating in US-West Availability Zone.
I was trying to solve the problem for ELB and I courageously or stupidly changed the Source IP of my default VPC security group to fix it. It did not fix the original issue but now I am in to another issue.
Now I am trying to restore the default VPC security Group setting in my Amazon Web Service account.
As per my knowledge the default VPC is very restrictive.
I don't quite remember what was the value for inbound source IPs.
The issue is that I have changed the Inbound rule's Source IP (from its original value which I do not remember) to Anywhere (0.0.0.0/0) in the default VPC Security group on AWS Console.
So how do I bring back the original default VPC security rule inbound IP setting that is applicable to my availability zone?
What is the implication of this? As a precaution I am not using default VPC Security Group on any of the EC2 instance or ELB.
Default VPC security group can not be deleted
You can make changes though
The default VPC security group simply points to its own Group-ID.
So you know how to restore the default VPC rule if you mess up with it.
You can search the informations inside AWS Forum https://forums.aws.amazon.com/forum.jspa?forumID=58
Many people open tickets similar to your problem.
The AWS docs are almost useless when trying to describe an entire system. Is there any resource or compiled list of all the resources that can belong to a security group and the different types of security groups?
Here is what I have so far:
EC2-Classic instance
EC2-VPC instance
RDS
ElasticCache
Anything else I'm missing? Any really good doc resource I'm missing?
The main concept to understand about an AWS Security Group is that it determines what traffic is permitted in/out of a resource on a virtual network.
Therefore, think about what can be launched "into" a virtual network:
Amazon EC2 instances
Services that launch EC2 instances:
AWS Elastic Beanstalk
Amazon Elastic MapReduce
Services that use EC2 instances (without appearing directly in the EC2 service):
Amazon RDS (Relational Database Service)
Amazon Redshift
Amazon ElastiCache
Amazon CloudSearch
Elastic Load Balancing
Lambda
Resources do not "belong" to a security group. Rather, one or more Security Groups are associated to a resource. This is often a difficult concept to understand since Security Groups have similar abilities to firewalls, and firewalls generally "encase" a number of devices. Rather than "belonging to", or "being encased by", a security group, the virtual network simply uses the definitions contained within a security group to determine what traffic to permit in/out of the resource.
For example, imagine two EC2 instances that are associated with a "Web" security group and the security group is configured to permit incoming traffic on port 80. While both instances are associated to the same security group, they cannot communicate with each other. This is because they do not "belong" to the security group, and are not "within" the security group. Rather, the security group definition is used to filter traffic in/out of the instances. The security group can, of course, be configured to permit incoming traffic from the security group itself (a self-reference), which really means that incoming traffic is permitted from any resource that is, itself, associated with the security group. (See, I told you that it's a difficult concept grasp!)
Also, a security group is not actually associated with an EC2 instance within a VPC. Rather, the security group is associated with the Elastic Network Interface (ENI) that is attached to an EC2 instance. Think of the ENI as a "network card" that links an instance to a VPC subnet. An instance can have multiple ENIs and can therefore connect to multiple subnets. Each ENI can have its own association with security groups. Thus, the actual security groups being used depends upon where the traffic is flow in/out of the instance, rather than actually being associated with the instance.
There are only two "types" of security groups:
EC2 Classic (the legacy network configuration)
EC2 VPC (the modern private network configuration)
Either type of security group can be associated with any other resource, as long as they are in the same network type (classic or VPC).
A Lambda Function can also be associated with a Security Group. That might not have been the case in 2015, when the original answer was written.
Fargate tasks can also be assigned to security groups.
AWS EFS (Elastic File System) needs a security group attached.
From the AWS document:
To connect your Amazon EFS file system to your Amazon EC2 instance,
you must create two security groups: one for your Amazon EC2 instance
and another for your Amazon EFS mount target.
Reference: https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-create-security-groups.html
interface endpoints can also be associated with security groups, this is a good question and so far not easy to find on AWS documentation.
I'm using Amazon web service (AWS).
I have a web server installed on one server instance (ec2).
It's served on port 8080. The machine is on a security group called "web-secgrp".
I want to allow access to that web server ONLY from another set of ec2 instances. These instances all share the same security group called "client-secgrp"
I can do this via the security groups by adding each and every individual public IP's of the set of ec2 instances to "web-secgrp". But this is not easy to maintain as I may have more or less of these machines running at once and it's just painful to add all the IP's by hand.
I noticed that in the Source of the security group, I can enter the ID of another security group. I tried entering the ID of client-secgrp in the inbound rules of web-secgroup but that seems to have no effect.
For what it's worth, I also remember that in the (very distant) past, I had to add the security group of an ec2 to the security group rules of an RDS (mysql service).
Any insight on a better way to manage the firewall ports of AWS is greatly appreciated.