What is the security concern in launching AWS EC2 instances in public subnet. I assume when an EC2 instance is launched in public subnet , it will have access to outside world provided security groups allow it. Is all traffic from internet allowed to public subnet? I assume even this could be restricted via NACLs.
About launching the ec2 instance in public subnet, it is recommended that EC2 instances which need direct Internet access need to be placed in the public subnet, else instances that need direct access to internal networks must be placed in a private subnet with routes to a virtual private gateway.
About NACL, you can control incoming and outgoing traffic at subnet level through NACL.
By default, NACL allows all inbound and outbound traffic.
Can customize NACL with required rules in order to provide the extra security at the subnet level.
Related
I have two EC2 instances, one on public subnet(10.1.1.0/24) and one on private subnet (10.1.2.0/24)
EC2 instance in public subnet works fine with internet connectivity and configured services.
There is a NAT Gateway configured in the public subnet 10.1.1.0/24 with Elastic IP.
Default route on private subnet is [0.0.0.0/0 --> NAT Gateway in public subnet].
I have a custom network ACL on private subnet, what I observed is when source and destination for inbound/outbound rules is set to 10.1.1.0/24 (public subnet) external connectivity breaks, but ssh works.
Only when source/destination are set to 'any' does internet connectivity restore.
I am trying to understand what exact source/destination should be used in network ACLs on private subnet for internet connectivity to work.
To allow instance from private subnet access internet using NAT gateway, your NACLs or SG must allow internet traffic. The NAT does not change the internet traffic into private VPC traffic. So if you remove 0.0.0.0/0 the internet connectivity stops.
This is explained in AWS docs on Instances cannot access the internet:
Ensure that the network ACLs that are associated with the private subnet and public subnets do not have rules that block inbound or outbound internet traffic.
Therefore, you must allow 0.0.0.0/0 (or some IP range if you want only part of internet traffic) in your NACL and SG for the instances in private subnet.
As a side note, generally NACLs are not modified, and default settings are usually used. Instead security groups are the first choice of controlling access to and from the instances.
I have configured lots of time, when my instance is in public subnet, I can distribute ELB traffic to them but instances in private subnet, it goes out of service. I had configure perfect SG between ELB to private instances and for ELB. Also added public subnet in ELB as same AZ where my private instances existing. I have done everything as per below URLs.
Amazon ELB for EC2 instances in private subnet in VPC
https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
As per first URLs, we don't require NAT in public subnet if we don't require to access any other service from private instances, "havak5" and "been Whaley" also commented afor same, still some websites tell that in this scenario, we need NAT gateway or instance in public subset for return traffic.
http://thebluenode.com/exposing-private-ec2-instances-behind-public-elastic-load-balancer-elb-aws
I had tried as per AWS URLs mention above but not work. So can any one tell me that really how this scenario work?
You can refer the following link from aws to understand use of NAT:
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html
If we want to make any kind of interaction with instances placed in private subnet we should use NAT
I have set up below VPC configuration but the SSH to the instance is not happening at the moment:
Created a new VPC
Created a public and private subnet
Launched an ec2 instance to the public subnet updated route tables for internet gateway
Launched ec2 instance to private subnet.
Associated a natgateway to the public subnet with in EIP
Route table updated for private subnet with natgateway
SSH from public instance to private instance is not happening with keypair.
Can you let me know what have I missed here.
First things first:
NAT Gateway in Public Subnet allows Instances from Private Subnet to reach internet for software updates etc via Internet Gateway.
NAT Gateway doesn't play any role in SSHing into an Instance.
Try this to test:
Attach Default NACL(allows all inbound and outbound) on Public and Private Subnet where your EC2 Instances resides.
Create 2 security groups for public(lets say Pub-SG) and private subnets(Prv-SG).
Allow SSH from everywhere/specific ip on Pub-SG.
On Prv-SG allow SSH from Pub-SG as source for better security reasons.
If both instances are launched using same key pair then with SSH-Agent Forwarding You can connect Private Instance through Public Instance.
I suspect you are missing a security group that permits SSH traffic between the instances on the two subnets.
AWS is secure by default - you need to explicitly permit traffic, roles, etc.
So in this case, the easiest thing to do would be to create a security group that spans the CIDR block of the VPC, and assign this to both instances.
Edit: I just noticed you say you added your NAT gateway to the public subnet - I presume you mean private.
This guide covers a similar scenario - public web subnet and private db subnet, and discusses all the routes + ACLs you need.
Also, when you say ssh with the keypair isn't happening - are you connecting at all, or does the connection time out?
When it comes to one EC2 instance communicating with another EC2 instance within a VPC, NAT Gateway has no role.
Make sure that the Security Group to which the private subnet instance belongs, allows SSH protocol from the Security Group to which the public subnet instance belongs.
Also, the NACL associated with the private subnet should allow inbound and outbound SSH traffic from CIDR block to which the public subnet instance belongs.
copy th ssh public key of the private instance to the public instance. open the ssh key material using vscode then use nano or vim to paste the content of the public key the save and exit. Now you can ssh into your private instance given the SG of the private instance allows traffic from the public instance.
I am trying to setup a nice and secure VPC for my lambda and RDS work. Essentially, I want my lambda to hit a site, get some data, and shove it into a database.
In isolation the parts all work. However the second I go to harden everything it all falls apart. Here is what I do:
Disable "Publically Available" from the RDS instance
Change the RDS instance to only accept connections from inside the VPC using the security group
Associate the lambda with a VPC (this kills the internet access)
Following this tutorial I created a NAT gateway, deleted the internet gateway from the VPC subnet, and replaced it with the NAT. Now, as expected, nothing can talk inbound, but things can talk outbound.
At this point I knew I needed a bastion instance, so I fired up an EC2 instance.
The EC2 instance is set to the same subnet the RDS and Lambda are on, and unfortunately this means that I have a problem - the NAT gateway is currently soaking up all the traffic via 0.0.0.0/0, which means there's no room for the internet gateway. Without the internet gateway I (obviously) can't SSH into my bastion instance so I can jump to access my RDS database.
How can I configure this all correctly? My guess is that I need to split the subnet up somehow and make a private and public subnet, the public having the bastion and internet gateway in it. However, I'm not sure how this will all work so the bastion instance can still properly jump to the RDS.
I'm really quite new to setting up AWS services so I'm hoping I didn't mess anything up long the way.
Following this tutorial I created a NAT gateway, deleted the internet
gateway from the VPC subnet, and replaced it with the NAT. Now, as
expected, nothing can talk inbound, but things can talk outbound.
Short Answer
The short answer is you shouldn't have "Killed the Internet Gateway"; thats not a step in the link you provided :) Leave the internet gateway as is in your current subnet. You're going to need a public subnet and the one that was routing 0.0.0.0/0 to IGW is an example of one you can could use.
The work involved is placing your NAT gateway in the Public Subnet, placing your bastion host in the public subnet, placing your lambda function in the private subnet, routing traffic in the private subnet to the NAT gateway in the public subnet, and providing your lambda function with access to your security group by putting it in its own lambda security group and "white listing" the lambda security group in the inbound rules for the security group protecting your database.
Background
Below I have an expanded answer providing background as to public/private subnets, granting internet access to private subnets, and allowing lambda access through security groups. If you don't feel like reading the background then jump to very end where I give a bullet point summary of the steps you'll need.
Public Subnet
A public subnet is one in which traffic originating outside your VPC, or destined for a target outside your VPC (internet), is routed through an internet gateway (IGW). AWS gives you initial default public subnets configured this way; you can identify them in the console by looking at their route table and seeing that under "destination" you find "0.0.0.0/0" targeting an IGW. This means a public subnet is more of a design pattern for "internet accessible" subnet made possible by simply configuring its default route to point to an IGW. If you wish to create a new public subnet you can create a new route table as well that point internet traffic at an IGW and link that route table to your new subnet. This is fairly easy in the console.
Private Subnet
A private subnet is a subnet with no IGW and not directly reachable from the internet, meaning you cannot connect to a public IP address of a system on a private subnet. With the exception of the AWS pre-configured default subnets, this is how new subnets your manually create are setup, as black boxes till you specify otherwise.
Granting Internet Access to Private Subnet
When you want things in your private subnet to be able to reach out to external internet services you can do this by using an intermediary known as a NAT gateway. Configure a route table the same as in the public subnet with the only difference being traffic destined for 0.0.0.0/0(Internet) you target for a NAT gateway sitting inside the public subnet. That last part is critical. Your NAT gateway needs to be in the public subnet but your private subnet is using it as the target for external traffic.
Security Group Access for Lambda
One simple way to allow your lambda function through your security group/firewall is to create a security group just for your lambda function and configure the security group protecting your RDS so that it allows traffic from the lambda security group.
In other words, in security group settings you don't have to specify just IP addresses as sources, you can specify other security groups and this is a pretty neat way of grouping items without having to know their IP address. Your lambda functions can run in the "Lambda Security Group" and anything protected by a security group that you want them to access can be configured to accept traffic from the "Lambda Security Group". Just make sure you actually associate your lambda function with the lambda security group as well as place it in the private subnet.
Lambda VPC Steps in a Nutshetll
Create a new NAT gateway and place it in the public subnet. This
point is important, the NAT gateway goes in the public subnet ( a
subnet whose route table routes 0.0.0.0/0 to an IGW)
Create a new subnet, you can call it Private-Lambda-Subnet. Unlike
the
default pre-configured subnets AWS gives you, this new subnet is
immediately private out of the box.
Create a new route table and link it to your Private-Lambda-Subnet
In the new route table for your private subnet add an entry that
routes 0.0.0.0/0 to a target of the NAT gateway. This is how your
private subnet will indirectly access the internet, by forwarding
traffic to the NAT which will then forward it to the IGW.
Your bastion host and anything else you want to be be publicly
accessible will need to be in the public subnet. This is probably
where you already have your RDS instances, which is fine if they are
firewalled/security group protected.
Create a new security group for your lambda function(s). You can
call it LambdaSecurityGroup.
Configure the inbound rules of your RDS guarding security group to
allow traffic from the LambdaSecurityGroup. This is possible because
you can use other security groups as sources in the firewall
settings, not just ip addresses.
You need a public subnet (default route is the Internet Gateway) and a private subnet (default route is the NAT Gateway). The NAT Gateway, itself, goes on the public subnet, so that it can access the Internet on behalf of the other subnets for which it is providing services. The bastion also goes on the public subnet, but Lambda and RDS go on the private subnet.
Anything can talk to anything on any subnet within a VPC as long as security groups allow it (and Network ACLs, but don't change these unless you have a specific reason to -- if you aren't sure, then the default settings are sufficient).
I started to mess around with aws a couple days ago and I have a question about VPCs.
I'm considering two options to make "private" a subnet and I want to know your opinion:
OPTION 1:
A subnet with an ig attached (a public subnet really) with an ACL to only allow traffic from the VPC.
Pros: cheaper!
Cons: public ip for each instance (is this a real problem?), different public Ip for each instance (a kind of messy stuff for ip's whitelists)
OPTION 2:
A subnet without an ig attached using a Nat gateway.
Pros: more secure?, same public Ip for each instance.
Cons: more expensive.
I consider the Option 2 the best technical solution, only a bit more expensive. But, do you consider the option 1 a bad practice? Has more pitfalls that I'm not seeing?
It appears that your requirements are:
Run some Amazon EC2 instances
Keep them "private" from the Internet (no direct access from the Internet to the instances)
Allow the instances to access the Internet (eg to download updates, or to communicate with AWS API endpoints)
Your Option 1 is a public subnet, made private by modifying the Network ACLs to allow traffic only within the subnet. You are giving public IP addresses to the instances, presumably so they can access the Internet. This will not work. The Network ACLs that limit access to the VPC will also block traffic from the instances to the Internet.
Your Option 2 is a private subnet, with instances accessing the Internet via a NAT gateway. There is no need to assign public IP addresses to these instances, since they are in a private subnet. Yes, this will work but, as you note, there is the extra expense of the NAT Gateway (or a NAT instance).
An alternative is to use a Public Subnet with Security Groups:
Use a public subnet and give instances auto-assigned public IP addresses. This will allow them to access the Internet. (Note: This is different to an Elastic IP Address, which is limited to 5 per region per AWS account.)
Use a Security Group on each instance to block Inbound access. The instances will still be able to initiate outbound access to the Internet (and responses will come back because Security Groups are stateful)
See documentation: Amazon EC2 Security Groups for Linux Instances
Of course, since the instances now block inbound traffic, you will need a way to connect to them. This is typically done by launching a Bastion Server (Jump Box) in your public subnet. You can connect to the Bastion Server via public IP address, then connect to the private servers via their private IP address. To allow this, configure the Security Group on the private instances to permit inbound traffic from the IP range of the VPC, or from the Security Group associated with the Bastion Server.