I have two AWS Linux AMI servers.
One with a Node.JS HTTPS server and the second running my Mongo DB.
The only way to connect to my Mongo DB server is through my Node.JS server.
In my in the AWS security group for the Mongo DB server I was able to put the name of the the AWS security group for the Node.JS server in the 'Source' column in the 'Inbound' tab and it allowed connectivity, but I'm wondering what setting the security group actually does?
More specifically, what IP addresses is this allowing?
If you click the 'i' next to Source it states:
I initially resorted to using the "private IP address" for communication between AWS instances because according to AWS documentation,
A private IP address is an IP address that's not reachable over the
Internet. You can use private IP addresses for communication between
instances in the same network (EC2-Classic or a VPC).
But after some discussion (see comments below) it seems the better solution may be to utilize AWS Security Groups. My initially hesitation in using AWS security groups was unfounded.
My fear was that if I added the same security group assigned to my Node.js server to the 'Source' for the inbound traffic tab of my MongoDB server, then my MongoDB server would inherit the same inbound traffic rules (all traffic).
The aforementioned fear is unfounded because setting the inbound source to a security group does NOT inherit the rules, but rather simply allows inbound traffic from any instance that has been assigned to that security group.
Related
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.
Pressing "Launch DB Instance" in the AWS RDS management console is the equivalent of launching a server daemon, if one were to do-it-oneself.
The console also has a setting to associate a "Security Group" to the DB Instance.
The Security Group itself has settings for "Inbound" and for "Outbound" traffic.
The "Inbound" traffic means requests to the server originating from some client somewhere.
What does "Outbound" traffic mean? Are these simply the responses of the db server? In that case, wouldn't it make sense for Inbound and Outbound to always have the same port range and IP addresses?
Relation to previous questions:
This RDS instance is to be coupled with an ElasticBeanstalk instance, not a VPC.
No, outbound traffic rules doesn't affect the responses coming from DB server for external requests(e.g Query, Update, Write & etc.) since security groups are stateful:
Security groups are stateful — if you send a request from your
instance, the response traffic for that request is allowed to flow in
regardless of inbound security group rules. Responses to allowed
inbound traffic are allowed to flow out, regardless of outbound rules.
Outbound traffic rules in Security Group is used for purposes like downloading patches from external sources for the DB Server in RDS.
AWS security groups are stateful which means you do not need to open the outbound for responses - open only inbound for requests. If you think your instances will be sending requests to certain IPs (for example: to upgrade/install a package), then you need to open the IP/port for that request.
My security group inbound rules are as follows:
WebAccess
HTTP TCP 80 0.0.0.0/0
SSH TCP 22 0.0.0.0/0
and
DB
MYSQL/Aurora TCP 3306 sg-0252186b (WebAccess)
My instances are setup like this:
Instance 1, web server - security group WebAccess
Instance 2, web server - security group WebAccess
Instance 3, DB server - security
group DB
If my understanding is correct, anyone should be able to access HTTP and SSH on my web servers, and only a member instance of WebAccess group should be able to access the DB server. However, the DB server is not accessible from the web servers.
When I change the 3306 rule to be open to allow inbound from anyone, I can access it fine (also from my local computer, as expected).
Please could somebody help me understand where I'm going wrong?
Thanks,
Chris
When you change the security-group to 0.0.0.0/0 and you are able to access the DB later on from your desktop that means your instance has been enabled for public access (i.e. having a public IP). When you connect to such a instance traffic leaves the subnet to the internet and comes back in. Because of that, the traffic no longer originates on your web instance but from the internet. You would need to use the web instances public IPs in that case.
Also please note, the way you have worded your question/comments, suggest you use the IP of the RDS instead of the hostname. This works if you use a single AZ RDS deployment. It won't work if you use multi-AZ or convert this RDS instance to multi-AZ (HA setup). The reason is, that during a failover AWS updates the DNS name to point to the new master. If your application is using an IP no fail over will occur.
Even worse: if you use an IP and single-AZ now but later decide to upgrade to a multi-AZ your application will continue to work until the first failover (most likely due to maintenance)
I am seeking some guidance on the best approach to take with EC2 security groups and services with dynamic IP's. I want to make use of services such as SendGrid, Elastic Cloud etc which all use dyanmic IP's over port 80/443. However access to Port 80/443 is closed with the exception of whitelisted IPs. So far the solutions I have found are:
CRON Job to ping the service, take IP's and update EC2 Security Group via EC2 API.
Create a new EC2 to act as a proxy with port 80/443 open. New server communicates with Sendgrid/ElasticCloud, inspects responses and returns parts to main server.
Are there any other better solutions?
Firstly, please bear in mind that security groups in AWS are stateful, meaning that, for example, if you open ports 80 and 443 to all destinations (0.0.0.0/0) in your outbound rules, your EC2 machines will be able to connect to remote hosts and get the response back even if there are no inbound rules for a given IP.
However, this approach works only if the connection is always initiated by your EC2 instance and remote services are just responding. If you require the connections to your EC2 instances to be initiated from the outside, you do need to specify inbound rules in security group(s). If you know a CIDR block of their public IP addresses, that can solve the problem as you can specify it as a destination in security group rule. If you don't know IP range of the hosts that are going to reach your machines, then access restriction at network level is not feasible and you need to implement some form of authorisation of the requester.
P.S. Please also bear in mind that there is a soft default limit of 50 inbound or outbound rules per security group.
I have an application hosted on Amazon AWS with backend database. Web application is controlled by Elastic Load Balancer with Autoscaling. MySQL databse is on the other instance within the same zone. The problem is that connection could be established only if I add rule in MySQL security group to connect on 3306 from 0.0.0.0. or if I add individual IP address of each instance. However, if I assign "Autoscale security group" or "Load Balancer security group" it doesn't work. Isn't that supposed to work if I assign security group where instances belongs to the MySQL security group?
Thanks,
I've finally solved the issue with the help of Amazon technical support for developers. It turned out that back-end instance is only accessible through the Amazon private IP address. I was always trying to access it through it's public IP address.
AWS allows ingress between two security groups only if they are configured in the same region. For your spcific case, modify the security group settings for the Mysql server allowing in-bound 3306 port traffic from AccountId/OtherSecurityGroup e.g 111122223333/OtherSecurityGroup