I am unable to use AWS SSM sessions manager for secure login to my private instances with NACL rules applied. Whereas AWS SSM works if I update NACL rules open To public(0.0.0.0/0).I want my private instances to be secure and not have open connections in NACL.
Please help.
I want my private instances to be secure and not have open connections
To use AWS SSM in a completely private subnet that has no inbound or outbound access to the internet, you need to use VPC endpoints. Follow the steps described in the AWS docs to do this:
Amazon EC2 instances must be registered as managed instances to be
managed with AWS Systems Manager. Follow these steps:
Verify that SSM Agent is installed on the instance.
Create an AWS Identity and Access Management (IAM) instance profile for Systems Manager. You can create a new role, or add the needed
permissions to an existing role.
Attach the IAM role to your private EC2 instance.
Open the Amazon EC2 console, and then select your instance. On the Description tab, note the VPC ID and Subnet ID.
Create a VPC endpoint for Systems Manager. For Service Name, select com.amazonaws.[region].ssm (for example, com.amazonaws.us-east-1.ssm).
For a full list of Region codes, see Available Regions. For VPC,
choose the VPC ID for your instance. For Subnets, choose a Subnet ID
in your VPC. For high availability, choose at least two subnets from
different Availability Zones within the Region. Note: If you have more
than one subnet in the same Availability Zone, you don't need to
create VPC endpoints for the extra subnets. Any other subnets within
the same Availability Zone can access and use the interface. For
Enable DNS name, select Enable for this endpoint. For more
information, see Private DNS for interface endpoints. For Security
group, select an existing security group, or create a new one. The
security group must allow inbound HTTPS (port 443) traffic from the
resources in your VPC that communicate with the service. If you
created a new security group, open the VPC console, choose Security
Groups, and then select the new security group. On the Inbound rules
tab, choose Edit inbound rules. Add a rule with the following details,
and then choose Save rules: For Type, choose HTTPS. For Source, choose
your VPC CIDR. For advanced configuration, you can allow specific
subnets' CIDR used by your EC2 instances. Note the Security group ID.
You'll use this ID with the other endpoints. Optional: For advanced
setup, create policies for VPC interface endpoints for AWS Systems
Manager. Repeat step 5 with the following change:
For Service Name, select com.amazonaws.[region].ec2messages.
Repeat step 5 with the following change: For Service Name, select com.amazonaws.[region].ssmmessages. You must do this if you want to
use Session Manager.
After the three endpoints are created, your instance appears in
Managed Instances, and can be managed using Systems Manager.
Related
I have an RDS in a public subnet in my default VPC. It's set to "Public accessibility: Yes". Its VPC security groups allow inbound access from a couple of CIDR blocks (basically, our office and VPN IP's) and a Lambda function.
I can connect to this database from anywhere, and I don't want to be able to.
My assumption was that, while "Public accessibility" would give it an external IP and domain, the security group restrictions would still apply: I could try to connect to myrdsdatabase.eu-west-1.rds.amazonaws.com but, unless I was on one of the whitelisted security group IPs, the connection would be refused. From the docs:
["Public accessibility"] lets you designate whether there is public access to the DB instance. Access to the DB instance is ultimately controlled by the security group it uses, and that public access is not permitted if the security group assigned to the DB instance does not permit it.
Am I misreading the above, or have I simply applied the security groups wrong? How do I allow RDS access from a whitelist of external IPs?
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.
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 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.
I set up a new region in EC2 and created a VPC network as well. The previous region was created by an offshore company and in the setup, the only security groups that I can see are from VPC. Security groups don't have a selection of EC2 and VPC as I'm only seeing one default.
In the second region, I see two defaults and a dropdown that lets me select/create security groups in both EC2 and VPC.
I can't seem to figure out how to remove the default security group in EC2. It says The security group 'default' is reserved Somehow this offshore team was able to do it in the other region. I tried from CLI and got the same error message
You cannot delete that Security Group.
The reason for the difference between your two Regions is that one has been configured for both EC2 and VPC (most probably the US-East-1 Region) and the other is only configured for "VPC". The available options can be viewed in the top-right corner of your EC2 Dashboard page under "Account Attributes / Supported Platforms".
VPC refers to Virtual Private Cloud, which allows you to configure your own private network configurations. It is the default now for all Regions.
EC2 (commonly known as EC2-Classic) pre-dates VPC and uses a shared network space for all AWS customers. It has been progressively phased-out.
So, it would appear that your "previous region" has only VPC, while your "second region" (probably US-East-1) has both. The Default Security Group that you are trying to delete is part of EC2-Classic, and you cannot delete it. It isn't in your "previous region" because that region is not enabled for EC2-Classic.
Documentation on EC2-Classic vs EC2-VPC: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html