I am trying to connect my app, running on one EC2 instance, to MongoDB, running on another EC2 instance. I'm pretty sure the problem is in the security settings, but I'm not quite sure how to handle that.
First off, my app's instance is in an autoscaling group that sits behind an ELB. The inbound security settings for the instance and ELB allow access to port 80 from anywhere, as well as all traffic from its own security group.
The EC2 instance that runs Mongo is able to take connections if the security group for that instance accepts all inbound traffic from anywhere. Any other configuration that I've tried causes the app to say that it cannot make a connection with the remote address. I've set rules to accept inbound traffic from all security groups that I have, but it only seems to work when I allow all traffic from anywhere.
Also, my db instance is set up with an elastic ip. Should I have this instance behind an ELB as well?
So my questions are these:
1) How can I securely make connections to my EC2 instance running mongo?
2) In terms of architecture, does it make sense to run my database this way, or should I have this behind a load balancer as well?
This issue is tripping me up a lot more than I thought it would, so any help would be appreciated.
NOTE
I have also set the bind_ip=0.0.0.0 in /etc/mongo.conf
Your issue is that you are using the public elastic IP to connect to your database server from your other servers. This means that the connection is going out to the internet and back into your VPC, which presents the following issues:
Security issues due to the data transmission not being contained within your VPC
Network latency issues
Your database server's security group can't identify the security group of the inbound connections
Get rid of the elastic IP on the MongoDB server, there is no need for it unless you plan to connect to it from outside your VPC. Modify your servers to use the private internal IP address assigned to your database server when creating connections to it. Finally, lock your security group back down to only allow access to the DB from your other security group(s).
Optional: Create a private hosted zone in Route53, with an A record pointing to your database server's private IP address, then use that hostname instead of the internal IP address.
Related
I need to get the IP numbers that are connecting to the EC2 instance then add them to AWS security group as a security group rule. So only those machines will have the permission to connect to instance. I don't need the port number that they're connecting to instance.
I installed iptraf-ng but app is very slow on the instance. Any other suggestions to capture the connecting IP's to instance so I can add them faster to security group rule?
You can use VPC Flow logs to monitor the traffic to the VPC (which will include the traffic that is going to the EC2 instance).
I have create an architecture on AWS (hope it should not be wrong) by using the ELB, autoscaling, RDS and one node ec2 instance outside the ELB. Now I am not getting, that, how I can implement the SSL on this architecture.
Let me explain this in brief:
I have created one Classic Load Balancer.
Created on autoscaling group.
Assign instances to autoscaling group.
And lastly I have created one Instance that I am using for the node and this is outside the Load Balancer and Autoscaling group.
Now when I have implemented the SSL to my Load Balancer, the inner instances are communicating with the node instance on the HTTP request and because the node instance is outside the load balancer so the request is getting blocked.
Can someone please help me to implement the SSL for this architecture.
Sorry if you got confused with my architecture, if there is any other best architecture could be possible then please let me know I can change my architecture.
Thanks,
When you have static content, your best bet is to serve it from Cloudfront using an S3 bucket as its origin.
About SSL, you could set the SSL at your ELB level, follow the documentation .
Your ELB listens on two ports: 80 and 443 and communicates with your ASG instances only using their open port 80.
So when secure requests come to the ELB, it forwards them to your server ( EC2 in the ASG ). Then, your server, listening on port 80, receives the request; if the request have the X-FORWARDED-PROTO HTTPS, the server does nothing, otherwise it sets it and forward/rewrite the URL to be a secure one and the process restart.
I hope this helps and be careful of ERR_TOO_MANY_REDIRECTS
Have you considered using an Application Load Balancer with two target groups and a listener rule?
If the single EC2 instance is just hosting static content, and is serving content on a common path (e.g. /static), then everything can sit behind a shared load balancer with one common certificate that you can configure with ACM.
"because the node instance is outside the load balancer so the request
is getting blocked."
If they're in the same VPC you should check the security group that you've assigned to your instances. Specifically you're going to want to allow connections coming in to the ports 443 and/or 80 on the stand-alone instance to be accessible from the security group assigned to the load balancer instances - let's call those 'sg-load_balancer' (check your AWS Console to see what the actual security group id is).
To check this - select the security group for the stand-alone instance, notice the tabs at the bottom of the page. Click on the 'Inbound' tab. You should see a set of rules... You'll want to make sure there's one for HTTP and/or HTTPS and in the 'Source' instead of putting the IP address put the security group for the load balancer instances -- it'll start with sg- and the console will give you a dropdown to show you valid entries.
If you don't see the security group for the load balancer instances there's a good chance they're not in the same VPC. To check - bring up the console and look for the VPC Id on each node. That'll start with vpc_. These should be the same. If not you'll have to setup rules and routing tables to allow traffic between them... That's a bit more involved, take a look at a similar problem to get some ideas on how to solve that problem: Allowing Amazon VPC A to get to a new private subnet on VPC B?
I have a quick question regarding deploying a configuration in ARM mode.
I want to have two app servers behind a load balancer, with a database server on the same subnet.
Creating the load-balancer and rules for this seems to be working fine, but I have an issue with trying to access my database server via SSH.
I originally wanted to set up SSH access to my database server by setting up an inbound NAT rule to forward a port from my database server to the load balancer. This would allow me SSH access to my database via my DNS name and a specific port.
However, It seems you cannot forward a port to a load balancer outside of the machines availability set.
I don't want to have my database server in the same availability set as my app server as you should have an availability set per tier.
But I don't particularly want to give my database server a full public IP address and DNS name either, as it shouldn't really be accessible outside its own subnet.
If I have an availability set per tier, does that mean I also must have a public IP address per tier to allow for SSH access to each machine?
What is the recommended way to set up a configuration like this, with SSH access to each machine spread across avaiability sets?
I have an elastic beanstalk app that uses a rethink-db instance as its database. The obvious thing to do would be to restrict access to the the database to only this application.
But if I set the relevant port in the security group of the Rethinkdb instance to anything other than 0.0.0.0, the application can't reach the DB.
The application is using the private DNS of the database for resolution and is in the same amazon region... as far as I understand, this alone should already get me passt the security group without any rules. Not in this case, apparently.
I have tried adding an exception for the applications security group to the databases security group on that port, as well as the security group of the load balancer of the application. I have also tried both at the same time. No dice.
The beanstalk-app is scalable, so it usually communicates from several instances that can change at a whim. Going over an elastic IP and allowing that in the databases security group is therefore not an option, unfortunately.
In the end, I'm forced to leave the security group of the rethink db on the driver port wide open at 0.0.0.0... Anything else I've tried made it unreachable for my own application.
Can anybody tell me what I'm doing wrong?
as far as I understand, this alone should already get me passt the
security group without any rules
That's not correct. You always have to have a security group rule to allow access. All inbound traffic is blocked by default.
I have tried adding an exception for the applications security group
to the databases security group on that port
That sounds like exactly what you need to do. You need to create an inbound rule in the security group assigned to the database server. In that rule you would specify the ID of the security group that the Elastic Beanstalk instances belong to.
If that isn't working, then you might need to post more information in your question, like the actual security group settings.
Also, you need to make sure your EB instances are trying to connect to the database server via the private IP of the DB server. Your issue sounds like maybe they are using the public IP of the DB server. I know you said they are using the private DNS of the DB server, but you need to make certain that is the case, and make certain that DNS is correctly resolving to the private IP, when referenced from the EB instances.
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! :)