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
Related
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!).
So i am trying to build a private vpc having a private and a public subnet. I want to communicate 2 linux ec2 machines with each other within same vpc. Also please explain inbound and outbound rules with ACLs in simplest way.
If both Amazon EC2 instances serve the same function (are operationally the 'same'), then:
Create a Security Group
Add in Inbound Rule on the security group permitting access from the Security Group (itself) on the desired port number
Attach the Security Group to both instances
This will allow both instances to communicate with each other because security groups are applied to each instance individually, so the Inbound Rules must permit access from 'itself'.
If the EC2 instances serve different purposes, (eg one is an app server, one is a database server):
Create a Security Group on the App server (App-SG) with desired inbound permissions from the Internet
Create a Security Group on the Database server (DB-SG) with inbound permissions on the desired port from App-SG
That is, DB-SG specifically refers to App-SG when defining inbound permissions.
Do not modify ACLs in the VPC unless you have a very specific reason for limiting network access (eg creating a DMZ).
Could someone confirm on the security benefits if any of the following:
I have an Internet facing Web Server in a VPC, this is peered to
another VPC running an application firewall.
The Web Server will talk to an RDS instance which will only be accessible by the application and a
management server (for support purposes, hosted in another VPC).
The question is - Should the RDS instance be placed on the same VPC as the Webserver or hosted in a separate VPC
That is totally up to you! In general, you should minimise the complexity unless there is a reason.
Putting a database in a separate VPC is definitely overkill. Sometimes people put the database in a private subnet to add an additional layer of security.
You should certainly configure the security groups like this:
A Web Server security group (Web-SG) associated with the Web Server that permits desired traffic (eg HTTP, HTTPS) from the Internet (0.0.0.0/0)
A Database Security group (DB-SG) associated with the RDS instance that permits inbound traffic on the desired port from Web-SG
That is, DB-SG permits inbound access from Web-SG by referring to Web-SG specifically (instead of by IP address). This means that any EC2 instance associated with Web-SG will be permitted access to the database.
I am working fine with my current ELB, but for security reasons i want to restrict connections by allowing just instances in the same security group, so i created an aditional security group just for mange only the ELB, i have no problem while i allow 0.0.0.0/0 to the 443 port, but when i remove the rule i am losing the connection, if i allow the public ip of the instance it will work, but i have several instances so it is not an option, i also tried allowing private CIDR (10.0.0.0/24) of the instances and it does not work, and i also tried allowing same security groups with not success
Thanks in advance
The setup should be:
A security group on the Amazon EC2 instances running your app (SG-App) that permits incoming traffic from the appropriate locations to access the app
A security group on the Load Balancer (SG-LB) that permits inbound connections on port 443 from SG-App
That is, SG-App is permitting inbound connections from any instances associated with SG-App. This is much better than allowing connections "from the same security group" because the instances need different settings to the ELB.
When the instances resolve the DNS Name associated with the Load Balancer, it should resolve to a private IP address (10.0). You can test this by connecting to one of the instances and trying to ping/lookup the ELB DNS Name and seeing what IP address it is using.
I am very new to AWS and networking. I have been playing with network ACL. I realized that if I don't allow outbound port 443 (HTTPS) on the network ACL, I wouldn't be able to use a browser to go to https://www.google.com from within the EC2 instance in the subnet associated with this ACL.
Likewise, if I don't allow outbound port 80, I wouldn't be able to go to http://www.cnn.com.
This confused me. When I allow port 80 outbound on the ACL, am I allowing the EC2 to talk to port 80 on the CNN server, from an ephemeral port on my EC2, or am I allowing the EC2 to initiate a connection from port 80 on the EC2?
use the security groups at instance level to have security at instance level.And unlike security group, ACL is stateless and works at subnet level i.e if you want your instances to communicate over port 80(http) then you have add an inbound and outbound rule allowing port 80.
You don't have to add any rules. The default network ACL is configured to allow all traffic to flow in and out of the subnets to which it is associated. Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.
Rules allow all IPv6 traffic to flow in and out of your subnet. We also add rules whose rule numbers are an asterisk (Catch All) that ensures that a packet is denied if it doesn't match any of the other defined numbered rules.
A network ACL has separate inbound and outbound rules (Stateless), and each rule can either allow or deny traffic.
Out Bound Rules allow outbound traffic from the subnet to the Internet. In other words it is matching the traffic flow with the defined rules in the ACLs list and apply it (ALLOW/DENY).
If you have private instances that should not be accessible by public users in the internet it is best practice from security point of view to place these instances in a private subnet and use NAT instance in a public subnet and make all traffic flow goes through this NAT instance to make patch updates and get the public access.
For more information, Check Amazon Docs