I had a very specific question regarding SGs speficcally around Inbound and Outbound rules.
Situation
Lets say we have an EC2 instance with SG-12345 which is trying to talk to a MYSQL database on SG-98765 and I want an Ec2 to talk to the database.
I read the AWS documentation that Security Groups are stateful. Given this the question I had was:-
Is there any difference between
adding the DATABASE SG (SG-98765) to the OUTBOUND RULES of the EC2 (SG-12345)
vs
adding the EC2 SG (SG-12345) to the INBOUND RULES of the DATABASE SB (SG-98765)?
Is there any difference between adding the DATABASE SG (SG-98765) to
the OUTBOUND RULES of the EC2 (SG-12345) vs adding the EC2 SG
(SG-12345) to the INBOUND RULES of the DATABASE SB (SG-98765)?
Yes. If you don't add both rules, the connection will be denied.
The statefulness of security groups does not apply across multiple security groups. It simply allows responses to requests that were permitted by the security group to also be permitted by the security group. Both security groups still have to allow the initial network request.
Often you will see security groups on an EC2 instance allow all outbound traffic by default, or allow all outbound traffic to the VPC CIDR perhaps. And then the inbound rules on the database would control what can actually connect to the database.
Related
My goal:
I have two instance EC2, one is an API that is public and another is a microservice, which needs only to communicate with API.
what I have tried so far:
I have one security group where both instances were attached. In this group, I created every possible rules. (I can ping each of them through private IP, but i can't make a request from my API to my microservice).
I made a simple diagram showing my goal and my problem
More details:
Both instance are running on the same VPC and subnet.
Trying telnet or curl, the response is connection refused
My inbound rules security group:
My outbound rules security group:
Security Group rules operate on each resource individually. Putting instances in the 'same' security group does not guarantee that they can communicate with each other.
The correct security setup would be:
One Security Group on the 'public' instance (Public-SG) that allows Inbound connections on port 80/443 from the Internet (0.0.0.0/0) and default rules that permit All Outbound traffic.
One Security Group on the 'private' microservice instance (Microservice-SG) that allows Inbound connections on port 8086 from Public-SG and default rules that permit All Outbound traffic.
That is, Microservice-SG should specifically reference Public-SG in its Inbound rules.
I have a license server that has a static IP set up inside the same security group and VPC as the EC2s I’m spinning up using terraform. Basically I want the license server and these EC2s to be able to communicate. At the moment they can’t because the security doesn’t add the EC2s as an inbound rule so that the license server also gets it as an inbound rule (same security group). I’m wondering how to add the IP of the EC2 I’m spinning up in terraform to the inbound of its security group so that it can talk to the license server?
There is no such concept as being "inside the same security group". Security Groups rules apply to each instance individually.
The correct configuration is:
Create a Security Group for the EC2 instances (EC2-SG) that permits appropriate Inbound access to use the instance, and
Create a Security Group for the licensing server (License-SG) that permits Inbound access on the licensing port from EC2-SG
That is, you need TWO security groups. License-SG will permit inbound access from any EC2 instance that has is associated with EC2-SG. You can have more security group as necessary for your instances -- simply add them as sources in License-SG.
Security Groups can also refer to themselves. In your current situation, where the instances and the licensing server are all associated with the same security group, you could add a rule that permits inbound connections from itself. However, this is also saying that the instances are permitting inbound connections from the licensing server, which would not be a correct configuration.
Please note that all communication within the VPC should take place via private IP addresses, otherwise the traffic exits the VPC and then comes in again, which does not allow Security Groups to operate correctly (and also costs you more money!).
I am trying to understand this statement:
"You can reference AWS Security Groups from other Security Groups."
What exactly does this mean?
This is how I understood this. I created a security group and call it "SG-10" and attached it to an instance "EC2-10". The SG "SG-10" has allow port 443 defined inside it.
Now, I create a security group and call it "SG-20" and attached this to an instance "EC2-20". This also has port 443 allowed. Now, if I call "SG-10" inside "SG-20" does this mean that "EC2-10" will be able to connect to "EC2-20" on port 443.?
Regards,
Nik.
if I call "SG-10" inside "SG-20"
No, you can not call a security group, this does not make any sense.
If a security group A references security group B, it does mean that the instance to which the security group A is attached allows inbound or outbound traffic to another instance to which security group B is attached. But if you want to send traffic form instance with security group A to the instance with security group B, you have to use the IP or the DNS of the instance B.
Usually the reason why we would want to reference a security group instead of an IP, is that the IP might change over time or it is not exposed at all. A fairly common example is having an application load balancer (ALB) and a group of EC2 instances which allow traffic only from the ALB. The IP address of the ALB changes over time, so in order to be able to receive traffic from the ALB, we can reference the security group attached to it.
In we want to reference a security group from another security group, we have to edit the rules of the initial security group:
As an example of referencing security groups, imagine a 3-tier architecture:
A Load Balancer receiving traffic from the Internet and sending requests to an Amazon EC2 instance
An Amazon EC2 instance receiving requests from the Load Balancer and sending queries to an Amazon RDS database
An Amazon RDS database receiving requests from the EC2 instance
This would involve 3 security groups:
A security group on the Load Balancer (LB-SG) that allows incoming traffic on port 80/443.
A security group on the EC2 instance (App-SG) that allows incoming traffic on port 80 only from the load balancer. It does this by setting the source to LB-SG.
A security group on the RDS database (DB-SG) that allows incoming traffic on the relevant port (eg 3306) only from the EC2 instance. It does this by setting the source to App-SG.
All security groups allow All Outbound Traffic.
By referencing other security groups, resources can be added/removed without having to change the security groups. For example, another EC2 instance could be launched and assigned the App-SG security group. This new instance would then be able to communicate with the database since DB-SG allows incoming traffic from App-SG, without being tied to any specific IP addresses.
If a resource is associated with multiple security groups, then all rules apply to the resource. Security Groups only say what is 'Allowed'. They do not include 'Deny' rules.
In your SG-10/SG-20 example, you do not mention the source of the traffic, so it is not possible to answer your question. If you want EC2-20 to accept connections from EC2-10, then the SG-20 security group should allow connections with the Source set to SG-10.
As an aside, I should mention that Network ACLs should normally be left at their default "Allow All" settings unless there is a specific networking requirement (eg creating a DMZ).
I've been burned on this before by trying to connect to an EC2 instance's public address... sounds very similar to your setup. Please check this question: Source Security group isnt working as expected in aws. Actually. When you wire up the inbound rule so that the source is a security group, you must communicate through the source instance's private address.
i have a jupyter notebook on one ec2 instance that want to get the data from data service that is deployed on other ec2 instance. should i put ingress and egress rules for each other on both instances? I'm quite new on the field, so any explanations are appreciated! :)
Yes, you can create 2 different security groups and attach to each one.
You can allow inbound traffic from a particular security group, all instances that have the security group attached can send traffic to the instance on the port you specify.
Another important thing no notice is that security groups are stateful, when you set outbound rules the response traffic is allowed regardless of the inbound rules.
Security Group Outbound rules allow all traffic by default. Typically, you should not modify these settings.
The best way to configure you setup is:
Create a Jupyter-SG security group and associate it with your Jupyter EC2 instance. Add whatever rules you use to connect with the instance (eg SSH).
Create a Data-SG security group and associate it with your "Data Service" EC2 instance. Add a rule permitting inbound access on the desired port, with Source set to the Security Group ID of Jupyter-SG.
This tells the Data-SG security group to permit inbound access from the Jupyter instance (or, more accurately, from any instance that is associated with the Jupyter-SG security group).
I have a security group assigned to an RDS instance which allows port 5432 traffic from our EC2 instances.
However, this security group has all outbound traffic enabled for all traffic for all IP's.
Is this a security risk? What should be the ideal outbound security rule?
In my perspective, the outbound traffic for the RDS security group should be limited to port 5432 to our EC2 instances, is this right?
What should be the ideal outbound security rule? In my perspective, the outbound traffic for the RDS security group should be limited to port 5432 to our EC2 instances, is this right?
It is a good idea to have a clear control over outbound connections as well.
In your RDS group: delete all outbound rules (by default, there is rule that allows outbound connections to all ports and IP's -> just delete this "all-anywhere" rule).
Your DB will receive inbound requests through port 5432 from your EC2 instance, and RDS will respond back to your EC2 instance through the very same connection, no outbound rules need to be defined in this case at all.
By default, all Amazon EC2 security groups:
Deny all inbound traffic
Allow all outbound traffic
You must configure the security group to permit inbound traffic. Such configuration should be limited to the minimal possible scope. That is, the fewest protocols necessary and smallest IP address ranges necessary.
Outbound access, however, is traditionally kept open. The reason for this is that you would normally "trust" your own systems. If they wish to access external resources, let them do so.
You are always welcome to restrict Outbound access, especially for sensitive systems. However, determining which ports to keep open may be a challenge. For example, instances may want to download Operating System updates, access Amazon S3 or send emails.
When using Security Goups (as opposed to ACL rules) all inbound traffic is automatically allowed in outbound traffic so outbound rules may be empty in your case.
Is this a security risk? What should be the ideal outbound security
rule? In my perspective, the outbound traffic for the RDS security
group should be limited to port 5432 to our EC2 instances, is this
right?
It's a risk only if you RDS is in a public subnet inside your VPC.
Best practices recommend in your scenario to have a public subnet within your web server and a private subnet for all private resources (RDS, other private services, etc).
As you can see in the image, hosting your RDS inside a private subnet there is no way to access it from outside your VPC