Even when I create EC2 instances in a private subnet, they must be able to send traffic to the Internet if I want to register them to a ECS cluster.
I am using a NAT gateway to do this, but I still feel insecure that the instances can send private information to anywhere in case of takeover.
What would be the most compact CIDR range that I can use for the instances' security group, instead of 0.0.0.0/0?
For the moment, you may have to rely on the list of public IP address ranges for AWS, allowing traffic bound for all the CIDR blocks associated with your region.
Part of design for resiliency of much of what AWS does relies on the ability of their service endpoints not to depend on static address assigments and instead to use DNS... but their service endpoints should always be on addresses associated with your region, since very few services violate their practice strict regional separation of service infrastructure.
(CloudFront, Route 53, and IAM do, maybe others, but these are provisioning endpoints, not operational ones. These provisioning-only endpoints do not need to be accessible for most applications to function normally.)
A super common pattern here is to create a proxy in a narrow CIDR and only allow outbound traffic to flow through the proxy. White-list AWS endpoints and log all traffic flowing through the proxy for monitoring/auditing.
AWS Endpoints = https://docs.aws.amazon.com/general/latest/gr/rande.html
Related
My lambda is getting ETIMEDOUT for hostname s3.amazonaws.com. I figured out that is is probably caused by the fact that my lambda is inside a VPC.
I suspect that I need to use an AWS Endpoint to reach S3. I know that we have endpoint set up and in AWS Console I can see and endpoint associated with this VPC called dev-s3-gateway with service name com.amazonaws.us-east-1.s3
How do I tell my lambda to use this endpoint?
Inside a VPC, your Lambda can be in either a private subnet or a public subnet.
Lambda in Public Subnets CANNOT access the internet.
Having Lambda access the internet
Being in a Private Subnet, your Lambda cannot have "direct" access to the internet. You need to provision a Public Subnet in your VPC and have both an Internet Gateway as well as a NAT Gateway in that subnet.
Route the traffic to 0.0.0.0/0 from your Lambda's subnet via the NAT Gateway.
From the routing table of the Public Subnet, route traffic to 0.0.0.0/0 via the Internet Gateway.
Your Lambda should now have access to the internet (and to S3).
Feel free to also check out this more detailed guide.
Accessing AWS services through VPC endpoints
Several AWS services offer VPC endpoints. These allow you to connect and interact with the respective services without your traffic ever leaving the AWS network.
For more information on them, please check out their documentation.
EDIT: Expanding a bit on your specific S3 use case.
S3 offers Gateway and Interface VPC Endpoints. Based on the endpoint name you provided in the question, I'm going to guess this is a Gateway VPC Endpoint. Once you set up the endpoint in your VPC, the Security Group(s) associated with your Lambda must allow outbound traffic to the endpoint.
You have two options.
First and simplest (but perhaps less secure - depending on your use case), you allow outbound traffic to 0.0.0.0/0. This will effectively allow you to call anything. However, if the Lambda is in a public subnet, it won't be able to access the internet, as explained above, but rather only the Gateway VPC Endpoint ranges.
The second option is to allow outbound traffic to the known Prefix List of the regional Amazon S3 endpoint. You can retrieve the PrefixList ID (looks like pl-xxxxxx) by invoking the DescribePrefixLists and looking for that Prefix List for service com.amazonaws.us-east-1.s3. Once you have the ID of the Prefix List, you can add it to the destination of an outbound rule of your Security Group(s).
I have two servers: ExternalSrv and InternalSrv, on the same EC2 VPC.
I have a very simple setup using Nodejs, Express and Axios.
ExternalSrv handles requests from the public, which, of course, come in to ExternalSrv's public IP address. ExternalSrv calls InternalSrv to do some of the work.
In order to simplify the security group inbound rules on InternalSrv, I would like to allow ALL VPC IP address, but nothing else.
I find that ExternalSrv always uses its Public IP address when making requests to InternalSrv's Private IP address. Therefore, the security group needs to be updated with ExternalSrv's Public IP address whenever that address changes (Stop/Start, new instance, more instances, etc.). That seems like a fragility point in ongoing maintenance.
This seems like this should be easy, but I've been searching for an answer for quite some time.
Any insight would be appreciated.
Bill
When two Amazon EC2 instances in the same VPC communicate with each other, it is best to perform this communication via private IP addresses. This has several benefits:
Security Groups can refer to other Security Groups
Traffic stays within the VPC (if communicating via Public IP addresses, the traffic will exit the VPC and then come back in)
It is cheaper (there is a 1c/GB charge for traffic going out of the VPC and then back in)
The best-practice security setup for your situation would be:
Create a Security Group on ExternalSrv (SG-External) that would allow inbound traffic as necessary (eg port 80, 443), together with default "Allow All" outbound traffic
Create a Security Group on InternalSrv (SG-Internal) that allows inbound traffic from SG-External
That is, SG-Internal specifically references SG-External in its rules. This way, inbound traffic will be accepted from ExternalSrv without needing to know its IP address. It also allows other servers to be added to the Security Group in future and they will also be permitted access.
Yes, you could simply add a rule that limits inbound access to the CIDR of the VPC, but good security is always about having multiple layers of security. Restricting access will cut-down potential attack vectors.
I have a resource (specifically, a Kubernetes service deployed to my AKS cluster) to which I want to limit access. I've looked around through the MSDN documentation on What is Azure Virtual Network?, VPN Gateway design, and more, but I don't see a clear way that I can either:
Require AAD authentication before a specific IP/Port is accessed, or
Whitelist access coming from a specific IP/subnet (eg, specifying CIDR format www.xxx.yyy.zzz/nn that should get access).
There seem to be ways to restrict access that require I install some a RADIUS VPN client, but I don't want to require this. It seems like there are a ton of hoops to jump through -- is there a way I can block all incoming traffic to my AKS cluster except from specific AAD roles or from specific IP ranges?
It would be helpful to understand what you intend to use AKS for (web site, batch computing, etc.)
First you should fully explore the networking options offered by the service itself. Start with locking down to your personal IP address and the service will likely (based on Azure docs) append a deny-all to the end of your networking rules. To get the IP address it sees you from, try IP Chicken.
I offer two additional options: Application Gateway or API Management.
One way to lock this down, based on the information you shared, is Application Gateway.
Application Gateway (Product Page)
Ingress Controller for AKS
"Application Gateway Ingress Controller (AGIC) allows you to use Application Gateway as the ingress for an Azure Kubernetes Service (AKS) cluster." - from Azure Docs
API Management
You also have API Management paired with policies on that resource. It can restrict by AAD (check pricing tier for details) and IP address (on any pricing tier).
If the organic networking options of AKS don't cover your use case, I would choose API Management. Price and options are better for what it seems you are aiming for.
I am building an cloud infrastructure on AWS.
I have some backend applications (like database servers) and other front end app (like webservers) that needs ingoing/outgoing traffic.
I also have some devops/dev app like Jenkins, and Airlfow (a workflow management tahts has a web UI) that i need to protect. Some of these apps, like Airflow, doesn't have security mechanism (for example login/password). And I still need access it on 80 port from Internet.
I was thinking to setup a AWS VPC, with a private subnet and public subnet. In the public subnet I will put the fron end apps and the private subnet I will put the backend services (like databases).
For the backend services, I need a way to my dev team to connect, for example, in a MySQL database (port: 3306).
What is the correct way of do this?
I need to expose port 3306?
Do I need a NAT or a bastion host? What is the difference between them?
If I setup a NAT/Bastion hosti will make a port foward rigth? If I have two instances of a mysql database, how can I connect to each other using the bastion? I need to allocate different ports on bastion and make the port foward?
For the devops/dev app:
Which subnet do I choose?
If i put on the private subnet, how can my team access it on 80 port?
Do i need a intranet/vpc foo this applications?
These are all quite common problems people are faced with on AWS. You have lots of options.
You could put all of your backend and dev opps services in the private subnet. You then have a number of choices to connect to them securely.
Option 1
Use Security Groups to limit access to these nodes. You can use Security groups to only allow specific IP addresses to connect to your resources.
Option 2
Use a bastion host.
Referring to your question "What is the difference NAT and bastion host?".
NAT simply allows instance inside a private subnet to connect to the internet by routing all their traffic through the NAT instance. The NAT instance then directs the return traffic from the internet back to the correct nodes in the private subnet. NAT alone does not allow you to connect to instances inside your private subnet from the outside, you'd need to combine it with Port Address Translation to achieve this.
A Bastion host is an instance that you place in a public subnet of your VPC. You can therefore connect to it from the internet. Once you're connected to your Bastion host, you can connect to any other instance inside your VPC using the private IP. Once you ensure maximum security to your bastion host, you're in business.
As a result, you could use a bastion host to connect to all those special nodes in your private subnet.
Option 3
Set up a VPN connection to your VPC using the built in functionality in VPC or setting up a VPN instance with something like OpenSwan running on it.
VPN connections are extremely secure but can often be a tad temperamental (*personal opinion from personal experience).
So, you have lots of choices. I'd recommend doing a few more google searches and digging deeper into the AWS docs as these are all commonly asked questions!
Good luck! :)
I am setting up a VPC on AWS. It has a public subnet and two private subnets. The public subnet is for web servers. The private subnets are for high availability databases. I am securing the resources using Security Groups, not Network ACL's.
The default security group which was created when I created the VPC allows all outbound traffic, and only allows inbound traffic from other subnets in the VPC. I'm not sure exactly what kind of servers I'll be deploying in the future - more web servers, more RDS instance, something else? In light of this, I think my default security group should allow no traffic inbound or outbound. Does that make sense?
In this way, if I forget to explicitly choose the security group when I launch an instance, the server is isolated from all other resources.
Given your design, a recommended security configuration is:
Put your load balancer in the public subnet: It is public-facing
Put your web servers in a private subnet: This keeps them secure by removing direct access from the Internet
This way, if you launch a future instance in the private subnet, it is more secure than launching in a public subnet. Security groups are then an extra layer of security.
Given that you are aiming for High Availability, also spread your web servers across multiple Availability Zones. An easy way to do this is to use Auto Scaling, which distributes instances evenly across Availability Zones and has the benefit of scaling in/out to meet demand while minimizing costs.
For an example architecture, see the Web Application Hosting reference architecture in the AWS Architecture Center.