Hi have issues with securithy groups on aws.
Assume I have two sec groups:
sg-d774eeed (secA)
sg-d787eady (secB)
I want secA to have access to port 9999 on secB.
In the source input box I will add sg-d774eeed with port 9999.
Commit the changes.
Nothing works
So I need to input sg-d774eeed/0 sg-d774eeed/32 or something like that?
You can create just one security group with port 9999, enter the same security group name in the source and assign this security group to both instances that you want to communicate together. However, to make that happen, you need to use either Private IP i.e. 172.1.2.3 or Public DNS i.e. ec2-54-1-2-3.eu-west-1.compute.amazonaws.com.
Port Range Source
9999 sg-abcdef
The best is to use Public DNS because:
When an EC2 instance queries the external DNS name of an Elastic IP, the EC2 DNS server returns the internal IP address of the instance to which the Elastic IP address is currently assigned.
Related
I followed all the steps given on the tutorial page of AWS to create a subdomain(https://aws.amazon.com/es/premiumsupport/knowledge-center/create-subdomain-route-53/) and I'm pretty sure I got everything right because the tutorial is pretty straight forward. For context, before this I setup a LAMP stack on the server linked with my main domain (example.com).
My question is how to upload and manage files on my subdomain (subdomain.example.com). I thought that all I needed to do was to create a new EC2 instance and link it with the "hosted zone" of my subdomain, and after that I could just upload files and it would work (like I did on my original instance of the main domain). But after many tries clearly I'm doing something wrong, because the page of my subdomain (subdomain.example.com) keeps appearing blank with just the text "This site can't be reached."
You say that you installed a LAMP stack on the instance, so presumably there is a web server listening on port 80.
To test this, first login to the instance via SSH, then try curl localhost to test the web server. If that fails, then there is a problem with your web server.
If it works, the you should check the Security Group associated with the Amazon EC2 instance. It should be allowing incoming traffic on port 80 from 0.0.0.0/0.
Next, obtain the Public IP address of the instance. In a browser on your own computer, try accessing the IP address, eg http://1.2.3.4. That should work if the Security Group has been correctly configured.
By the way, you should be using an Elastic IP address (EIP) for the EC2 instance, which is a 'static' IP address that does not change. You can create an EIP in the EC2 management console, then associate it with the instance. This prevents the Public IP address from changing if the instance is stopped.
Next, try accessing the instance via the domain name. If this does not work, then test the name resolution by using ping with your domain name. The Ping itself won't work, but it should display the IP address that is linked to that domain name. Make sure that the IP address matches the Public IP address you used in the previous step.
If no IP address is provided, then you are missing an A-Record in the hosted zone. You should create the A-Record in the hosted zone and provide it with the Public IP address of the instance.
I have a network in GCP with configured firewall rules. I have couple of instances and two of them are as below.
instance 1 - with network tag "kube-master"
instance 2 - with network tag "kube-minion"
And I want to ping from kube-master to kube-minion So, I set up a firewall rule (master-to-node) for icmp as below.
But the problem is I can't still ping from kube-master to kube-minion. I logged into instance 1 (kube-master) and tried to ping the public ip address of instance 2 (kube-minion) but it doesn't ping
As above image, am I restricting this behaviour? But I have setup the priority as 2 so it will take the precedence.
When I set source as 0.0.0.0/0 instead of giving kube-master it works, but I need to only do this (send traffic to kube-minion) only from kube-master
Can someone tell me where am I doing the mistake? Thank you!
As you can see in the documentation
Thus, the network tags are still only meaningful in the network to which the instance's network interface is attached.
Therefore, if you access to the VM with the Public IP, you are going out of your network to reach it, and the tag information is lost. Use the private IP of the VM and it will work as expected.
Add 0.0.0.0/0 as source, or the public IP of the master in /32 (better) if you want to continue to use the instance 2 public IP
Source tags only apply to traffic sent from the network interface of another applicable instance in your VPC network. A source tag cannot control packets whose sources are external IP addresses, even if the external IP addresses belong to instances.
When you ping from instance-1 the external IP address of instance-2, the ICMP request is translated and therefore on the receiving side, the request appears to come from an IP address(external IP of instance-1) that is not associated with the network tag kube-master.
Edit:
I'm trying to set up an SFTP server managed by AWS that has a fixed IP address which external clients can whitelist in a firewall. Based on this FAQ this is what I should do:
You can enable fixed IPs for your server endpoint by selecting the VPC endpoint for your server and choosing the internet-facing option. This will allow you to attach Elastic IPs (including BYO IPs) to your server’s endpoint, which is assigned as the endpoint’s IP address
So I followed the official instructions here under "Creating an Internet-Facing Endpoint for Your SFTP Server". The creation settings look like this:
The result looks like this:
Compare with the result screenshot from the docs:
(source: amazon.com)
My result is almost the same, except that under the table "Endpoint Configuration" the last column says "Private IPv4 Address" instead of 'Public'. That's the first red flag. I have no idea why it's a private address. It doesn't look like one, it's the IP address of the Elastic IP that I created, and the endpoint DNS name s-******.server.transfer.eu-west-1.amazonaws.com resolves to that IP address on my local machine.
If I ping the endpoint or the IP address, it doesn't work:
451 packets transmitted, 0 received, 100% packet loss, time 460776ms
If I try connecting with sftp or ssh it hangs for a while before failing:
ssh: connect to host 34.****** port 22: Connection timed out
Connection closed
The other potential problem is security groups:
At this point, your endpoint is assigned with the selected VPC's default security group. To associate additional or change existing security groups, visit the Security Groups section in the https://console.aws.amazon.com/vpc/.
These instructions don't make sense to me because there's nowhere in the Security Groups interface that I can assign a group to another entity such as a transfer server. And there's nowhere in the transfer server configuration that mentions security groups. How do I set a new security group?
I tried changing the security group of the Network Interface of the Elastic IP, but I got a permission error even though I'm an administrator. Apparently I don't actually own ENIs? In any case I don't know if this is the right path.
The solution was to find the endpoint that was created for the server in the "Endpoints" section of the VPC console. The security groups of the endpoint can be edited.
The "Private IPv4 address" seems to be irrelevant.
The default security group controls access to the internet-facing endpoint for the new sftp server in a vpc. Mess around with the default security group ingress rules for the vpc selected for the sftp server. Or, white list the exact ip address connecting to the sftp endpoint in the default security group.
If the admin says ho hum, create a second vpc for the sftp server if isolation is absolutely necessary. Fiddle with the default group in the new, isolated vpc.
Link:
Creating an Internet-Facing endpoint for Your sftp server
Happy transferring!
I frequently have problem with AWS EC2 Security Group. It takes me long time to figure out what goes wrong in the setting.
I am wondering is there any available tool to test the security group much easier without having to manually check in AWS.
There's a new capability in AWS called AWS Route Analyser. With this service you can enter the instance id and your internet gateway, and it will advise you as to what (if anything) is stopping the routing of packets. See https://docs.aws.amazon.com/vpc/latest/tgw/route-analyzer.html
Hey you can use below link if your port is accessible from every where:-
https://ping.eu/port-chk/
you need two information:-
IP address or host name:
Port number:
or you can ask the remote user to:
telnet hostname port number
telnet ip address port number
I am setting up a redshift database on AWS and I've followed the instructions on this article - https://chartio.com/resources/tutorials/connecting-to-a-database-within-an-amazon-vpc/
I am unable to connect to the database.
Here's my setup -
I have a PostgreSQL database instance that I spun up with Amazon RDS. That is connected to an Amazon VPC with two subnets.
Subnet A is set in us-east-2c. It is associated with a Route Table that has two routes. The first has destination 10.0.0.0/16, target 'local', status 'active' and propogated 'no'. The second has destination 0.0.0.0/0 and is targeted to an Internet Gateway associated with the VPC.
Subnet B is set in us-east-2b. It has destination 10.0.0.0/16 and target 'local'.
The PostgreSQL db is associated with a Security Group with this inbound rule: Type: Custom TCP Rule, Protocol: TCP, Port Range: 5432 and Source: 10.0.0.0/32. There are no outbound rules.
Other details on the database:
-Publicly Accessible is set to No
-It is running in us-east-2b
Additionally, there is an instance on EC2. It is on us-east-2c.
It is associated with a Security Group with these inbound rules:
First- Type: Custom TCP Rule, Protocol: TCP, Port Range: 5432, Source: 10.0.0.0/32
Second- Type: SSH, Protocol: TCP, Port Range: 22, Source: (my-ip-address)/32
Third- Type: SSH, Protocol: TCP, Port Range: 22, Source: (group id for the security group)
Both of the Security Groups are associated with the same VPC that has the following settings: IPv4 CIDR: 10.0.0.0/16, IPv6 CIDR: (blank).
My understanding of the set up is that the EC2 instance is public and I can SSH into that from my SQL client (Postico). And then, the EC2 instance will connect privately to the Redshift Database.
Here's my problem-
a) I've never set this up before and I may have done something completely wrong without knowing it.
b) I am attempting to create an SSH connection from Postico. I do not know what value to fill in for 'Host' or 'Port'. Additionally, I do not know whether 'User' and 'Password' refer to the user and password for the account on my computer or whether it refers to something else altogether.
My goal is simply to be able to have a PostgreSQL database that is unavailable to the public, but allows me to access it from my SQL client (Postico).
I've attempted to research this problem, but there is a surprising lack of content that I was able to find to address these needs. I'm new to this, so if I'm missing required pieces to post this or if I've messed up in some way, please alert me and I will update accordingly.
Your inbound security group has "Source: 10.0.0.0/32" This means only 10.0.0.0 can connect to it, which is an invalid host address. Change the /32 to match your network (/16).
Redshift's port is usually 5439. You are referencing 5432.
I don't understand your "b" question. What are you trying to connect to?
[Update with new information]
I just realized an issue with what you are trying to do.
Your goal is to connect to EC2 from your desktop using SSH and then connect to RDS. This won’t work.
The solution is to setup a VPN such as OpenVPN that allows you to connect to your VPC in AWS and then OpenVPN will forward your client requests to RDS (VPN routing).
What I do is setup an EC2 instance using OpenVPN. I then turn on and off this instance when I need VPN access into AWS. I have batch scripts that do this from my desktop (start and stop an EC2 instance).
The other choice is to allow Internet access to RDS. You can use Security Groups to lock down Internet access to only your home/work IP address. Depending on your Internet provider your IP may change which means updating your security group with the new IP address, but this is simple to do.
This page will show you your public IP address that is put into the Security Group: What is my IP