Hi I'm running memcached on my webserver on an AWS ec2 instance. So it has a public IP address and a private IP address.
I followed the following page to install memcached:
https://www.thefanclub.co.za/how-to/how-install-memcached-on-ubuntu-for-drupal
One step is to "Open firewall port 11211"
My question is what rule should I add to the ec2 security group? I want to know the source ip setting.
Right now in the ec2 security group, Inbound rules, I've added allow 11211 port tcp from source private ip address of the ec2 instance. Is that correct for memcached to work for anonymous users from the internet visiting my website? Thanks!
what rule should I add to the ec2 security group?
No rule at all.
If you are running memcached on the same machine your web server, then you do not need any security group settings for memcached. If the connection never leaves the machine, the security group settings have no impact on it.
Related
I have Jenkins running in a Windows server EC2 instance on a custom port. Firewall is open on that port, and security group's inbound rule matching it allowing any IP address (users can't sign up and anons can't even read).
Now I want to add an extra security layer, but if I remove that inbound rule in the security group and only allow that port to the vpn security group, I can't access Jenkins.
I'm currently restricting access to RDP using that same vpn security group and it works perfectly. What may be causing it?
I've already tried restarting Jenkins service, connecting and disconnecting to vpn and Jenkins url times out.
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 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.
I created a new instance of Amazon EC2 in Amazon Web Services (AWS) by referring to the documentation. I even added a SSH rule like this:
Port: 22
Type: SSH
Source: <My IP address>/32
I downloaded the .pem file, converted it into .ppk file by using PuTTYGEN. Then I added host name in PuTTY like this:
ec2-user#<public_DNS>
I selected default settings, added that .ppk file to PuTTY, logged in and I got this error:
Even trouble shooting link didn't help me.
I'm also getting this error in system logs:
How can I connect to my Amazon EC2 instance via PuTTY?
Things to check when trying to connect to an Amazon EC2 instance:
Security Group: Make sure the security group allows inbound access on the desired ports (eg 80, 22) for the appropriate IP address range (eg 0.0.0.0/0). This solves the majority of problems.
Public IP Address: Check that you're using the correct Public IP address for the instance. If the instance is stopped and started, it might receive a new Public IP address (depending on how it has been configured).
VPC Configuration: Accessing an EC2 instance that is launched inside a Virtual Private Cloud (VPC) requires:
An Internet Gateway
A routing table connecting the subnet to the Internet Gateway
NACLs (Network ACLS) that permit through-traffic
If you are able to launch and connect to another instance in the same subnet, then the VPC configuration would appear to be correct.
The other thing to check would be the actual configuration of the operating system on the instance itself. Some software may be affecting the configuration so that the web server / ssh daemon is not working correctly. Of course, that is hard to determine without connecting to the instance.
If you are launching from a standard Amazon Linux AMI, ssh would work correctly anytime. The web server (port 80) would require installation and configuration of software on the instance, which is your responsibility to maintain.
Ajay,
Try this. Go to your VPC dashboard. Click on Network ACLs - on the associated acl, update your Inbound Rules to allow SSH access on port22.
Go to vpc attached to instance and then add entry to route table with
0.0.0.0/0 - Destination
Internet Gateway of your VPC - As Target
Save It and try to connect it.
Go to VPC --> Security Group --> Edit inbound rules --> make the ssh source ip (anywhere) then save it and try to login with your putty-client. finally go back to your security group inbound rules and change the source IP from (anywhere) to (my ip) or any custom IP do you want then save it.
note: I assume that you have successfully stored and converted your private key
Security Group - This must accept traffic from your IP address
ex:
Protocol - SSH, PORT-22, IPAddress - SOME IP ALLOW
All Traffic On Any Port From 0.0.0.0/0 means from any IP Address ALLOW
Route Table - Make Sure you have outgoing traffic route enabled
ex:
Destination - 0.0.0.0
target- internet gateway
Use or generate private key
I struggled with this problem for ages after my EC2 instance suddenly started refusing a connection. I tried every answer on SO and Google but nothing helped!
The fix was to make sure that the Network ACL inbound rules were updated to match the rules on the security group.
I have no clue why it worked yesterday and stopped today, but this fixed it.
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