I'm setting up a test VPC on AWS to see how I like different configurations.
Using the default Scenario 2 configuration:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
I'm not sure what the best practice process for accessing members of the subnet is. You can ssh into the NAT and then ssh into the instance in the subnet, but this of course requires having the pem keys for that instance on the NAT, which makes me uncomfortable.
Have I miss understood the configurations of the security groups, and should be able to ssh directly into the members of the subnet?
In general, instances in private VPC subnets do not have inbound access from the Internet and cannot be accessed directly. You can assign elastic IPs to instances in private subnets and inbound traffic would be routed to it. However, outbound return traffic would never reach the source since the NAT won't route asymmetric traffic.
There are at least two options for accessing those systems via SSH:
Use a bastion host in a public subnet to jump to the instances in the private subnet. The NAT could serve as this bastion, or you could set up another instance. You can have your private key on the bastion, or you can use the ForwardAgent option in your SSH configuration to use the private key from the bastion without requiring the key file to be present.
Establish a VPN from your network to the VPC using a VPN gateway. Allow access in the VPC security groups from your network's address space to the instances in the private subnet. You can then SSH to the private instances as if they're local to your network.
Leaving the private keys on the bastion host shouldn't make you uncomfortable if you harden the bastion sufficiently using security group rules, local firewalls, and other standard system security techniques.
Related
My Linux based EC2 instances have both public and private IPs. I am hosting two servers on it:
S3 server, which will be accessible over both internet/private network and
NFS server, which should be accessed only via private IPs/internal network.
I want to open NFS port in the Security Group but only allow the access over the EC2 instances's private IP. I don't think this can be achieved by using only security groups as when the request reaches EC2 node, the Internet Gateway has already replaced the public IP with the private IP of the EC2 instance and the instance is not even aware that there is an extra public IP associated with it.
Instead what can be done is to choose the sources and selectively allow NFS access only to the VPCs and on-premises network (in case there is a VPN connectivity) but that would also mean that every time a new VPC is created OR a new VPN endpoint is established, someone has to modify the Security Group to accommodate new IP addresses.
What I ideally need is a way to apply port and IP based rules on the Internet Gateway which is currently not available/exported. Looking for alternatives.
The simplest method would be to add an Inbound rule to the Security Group where the Source is the CIDR range of the VPC.
For example, if your VPC is 172.31.0.0/16, then use this as the Source in the security group. It would permit any inbound connection from that IP address range.
When you set up an EC2 instance in a private subnet to access the internet through a NAT gateway (with all the necessary routing and association through route table), how do you go about SSH'ing into the private EC2?
For example, EC2 in the NAT Gateway public subnet and making a connection through the public EC2 to the private EC2.
NAT Gateway is for outgoing traffic only.if you have to access the private EC2 instance then you need bastion on public subnet in same VPC.
OR VPN to connect or AWS system manager.
There are three options that are commonly used:
Use a bastion host in a public subnet. First you ssh to the bastion, and then ssh from the bastion to the private ec2. This usually requires copying private ssh key to the bastion so that you can use it there to ssh to the private subnet.
Use a SSM session manager. This probably would be the easiest option to setup as you already are using NAT and it requires special instance role.
Use a VPN. Probably the most complex solution but also used nevertheless.
As the instance is in a private subnet you will need to use a method to connect to this privately. There are many options to choose from, they will vary in cost and complexity so ensure you read each one first.
Site-to-site VPN - Using this method a managed VPN is added to your VPC and connected to your on-premise via hardware configuration. Your security groups will need to allow your on-premise CIDR range(s) to allow connection.
Client VPN - Using either AWS solution, or a third party from the marketplace (such as OpenVPN) you can establish a connection using either a local program or HTTPS in your browser.
SSM Sessions Manager - Access your EC2 instance via the AWS console or using the CLI, portrayed as a bash interface without using SSH to authenticate. Instead IAM is used to control permissions and access.
Bastion host - A public instance that you can connect to as an intermediary either using SSH to connect to before accessing your hsot, or as a proxy for your commands.
I am currently preparing for the AWS SysOps Administrator Associate exam using the study guide book (https://www.amazon.com/dp/1119561558/).
In the review question for chapter 8 - Bastion Hosts there are two questions about "Private VPC" which I cannot get my head around:
"2) Which of the following does a bastion host provide to a private VPC?"
My Answer: Access to the resources in the VPC through a host inside the VPC
Correct Answer: Access to the resources in the VPC through a host outside the VPC
"15) You have just inherited a new network architecture that has a private VPC with numerous resources within it and a bastion host for administrative access. Which of the following would you do first?"
My Answer: Remove any Internet gateways on the private VPC.
Correct Answer: Whitelist any IPs that need to access the bastion host.
As far as I understand it, a typical VPC architecture is to have a public subnet, with an Internet Gateway and the bastion host in it, and a private subnet with neither.
But what exactly is meant with "private VPC" here? If it is a VPC that is not accessible from the outside at all? But how can a bastion host outside the VPC then access it? Or do they really mean a private subnet? But how can a subnet be really private, if it has an Internet Gateway in it? In other courses the IG is defined as exactly the thing that makes a subnet public...
Am I totally misunderstand something conceptually here?
2)
Your answer and understanding is correct. Bastion host is inside vpc. This is also written in aws docs:
A Linux bastion host in each public subnet with an Elastic IP address to allow inbound Secure Shell (SSH) access to EC2 instances in public and private subnets.
15)
I would agree with: "Whitelist any IPs that need to access the bastion host". The rationale is that removing internet gateway can have many negative consequences, most notably, not being able to login to bastion host to do any admin work, instances in private subnets not being able to download patches, or newly launch instances in ASG not being able to download software they need by means of User Data.
So removing old IPs from Security Group of bastion host belonging to old admin and adding your own IP makes most sense.
Don't know what is meant here by "private VPC". For myself, a private VPC would be one only accessible through a peering connection, one which does not have any public subnet, or one which only provides access to your app through VPC PrivateLink. In such cases you could use SSH Session Manager to login to the instances without the need for any bastion host and internet gateway.
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.
I have the following issue:
I want to setup a NAT or WAF in the following scenario:
Internet->VPC->IGW->Rotuer->Subnet1->EB1
->Subnet2->EB2
->Subnet3->EB3
in short words, my scenario is: VPC, Internet Gateway, Route table (Default from VPC) and subnets with EB into.
I tried some steps where I have to create another route table, set NAT instanc as target to 0.0.0.0/0 in this second one and attach the EB subnets to this one; attach the NAT subnet to the main route table and this seems not work.
Tried to Amazon AWS scneario 1 example that is my current configuration without results.
What can be missing to setup correctly it?
Thanks in advance.
I'm not entirely clear about what you are wanting to achieve, but I think you want your subnets to access the Internet, and prevent the Internet from having a direct access to the instances the reside in your private subnet(s).
It's hard to visualize your workflow that way. But i think I follow:
(AWS VPC Internet Gateway) --> Internet
AWS VPC CIDR range contains:
a) public/private subnet #1
b) private subnet #2. private subnet #3.. etc.
A typical set up of achieving requires the following Amazon entities:
1) IGW - internet Gateway
2) VPC with CIDR range of how big or small you want.
for the VMs that you want to protect, while still having internet access, you need them to be assign subnets. The subnets have to be WITHIN the VPC CIDR range. But do not make the subnet to be the same CIDR of the VPC, if you do this, then it essentially makes your private subnet a public accessible one since you have consumed all of the IP range and in which case you must assign it to the IGW which is not what you want.
3) A bastion server - what is a bastion server? This is a server that you purposely put to take internet incoming requests, which protect your private subnets. This can be in the form of a server that acts as a router or NAT. This can be either
3a) a homebrew install of Ubuntu (my fave distro) with iptables and ipv4 packets forwarded, or you can do
3b) a Nat gateway in your amazon VPC, or
3c) a vpc-nat AMI that you can find in the AMI Community. So just chose what method you wish.
4)Create Security group #1 - create a security group for the Bastion Server. I usually call it "NAT SG" and have inbound 0.0.0.0/0 and outbound to TCP 80, 443, 22 and etc, according to your outbound port needs determined by whatever you are running.
5) Security group #2 - create a security group for the private subnet. This is for traffic that will allow all within the subnet(s) and to funnel all outbound non private data to 0.0.0.0/0 to the bastion server.
To implement this is a simplified conceptual order of operations you need to do:
1) Create a VPC with the CIDR range (let's say 10.0.0.0/16)
1.5) create an Internet Gateway and assign it to the VPC (10.0.0.0/16)
2) Create private subnets with CIDR range that's in the VPC CIDR (10.0.1.0/24, 10.0.2.0/24, 10.0.2.0/24, etc).
3) Create a public subnet that will contain the bastion server, or whatever you want the Internet to see. (10.0.254.0/24 (this is huge, allowing 256 servers in the subnet. You will most likely only have the bastion server consuming only 1 server, so it will probably auto assign 10.0.254.2)
4) create 2 routing tables - one called private and one called public. For the private routing table, edit, then add a new Route for 0.0.0.0/0 goes to the bastion server ID. For the public routing table, edit , then add a new route for 0.0.0.0/0 to the Internet Gateway ID (see step 1.5)
5) Either launch your own server and set it up to become a NAT router (if you know how to do that), or start up the vpc-nat AMI (amzn-ami-vpc-nat-hvm-2016.03.0.x86_64-ebs - ami-311a1a5b) is the latest one, so use that. When you create the instance, select the public subnet, the VPC, and assign it a public IP (don't wait and give it an Elastic IP, you will want the public IP),select the "NAT SG" security group, and then Launch it. After it is launched you will select it and select Network --> src/dest. check and DISABLE it. This allows all traffic to funnel in. You only need 1 bastion server, I'm not stating to do all 3.
6) Launch your AMI or custom VM that you want private, and be within the private subnets (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24... etc). And assign it a private security group, and the same VPC. If it is linux or windows you may want to generate a new private key (pem) for future login. Convert the pem to a ppk using puttygen.
Testing, in order to ensure you have internet connectivity:
the bastion server must be able to reach the world
the VM instance in the private subnet (if the routing was done accurately), should reach the internet by flowing packets to the 0.0.0.0/0 rule to pass through the bastion server, and the bastion server will allow resolution and flow to the internet for outbound requests.
I usually do a ping to google since they do not block ICMP requests and are quite reliable. So ssh into the bastion server, ping google.com. If you get the IP but it cannot get a reply then it means your Internet gateway or the Security group did not all all outbound traffic 0.0.0.0/0, so double-check that.
Now SSH into the private server (assuming linux) and ping the bastion server (10.0.254.X) and you should be able to get a response. That's a good sign. now ping google.com and see if you get a reply. I hope you do. If you get DNS resolution but it is stuck at get any responses, then you forgot to disable Src/Dest checking on the bastion server. Then go to your ec2 console, locate the bastion server and select, then actions, networking, and select src/dest check and confirm DISABLE and save.
That should make your private network resolve and hit the world, while still being protected from the internet.
I hope this helps.
Richard.