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!
Related
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
I was able to connect to the amazon rds aurora database locally, and run queries.
But on production EC2 server, the connection returns 500 server error "SQLSTATE[HY000] [2002] Connection timed out".
I've added the same credentials for the database to production, and can see they are being used in the error log.
I enabled the 'allow public access' setting.
I added all the security groups I have to the database (this is probably the problem, I didnt create any special groups, just whatever amazon suggested I let them do).
How could it be working locally but not on production?
Can you check your production server security group outbound rules. if it is connecting from local and not connecting from production machine , so should be some outbound traffic timeout.
It was a security group issue.
The default rds-setup-wizard security group was applied to my database instance, and this gave me local access. I guess it had my ip address or similar as an inbound rule.
I had to add a new security group and add that new group to the database instance.
My new security group needed an inbound rule that looked like this:
Type: MYSQL/Aurora
Protocol: TCP
Port Range: 3306
Source: my EC2's private ipv4 address with /32. Eg: 13.14.15.16/32
I have an EC2 instance with a few applications successfully deployed onto it, listening for connections on ports 3000/3001/3002. I can correctly load a web page from it by connecting to its public DNS or public IP on the given port. I.e. curl http://<ec2-ip-address>:3000 works. So I know that the apps are running, and I know that the port bindings/firewall rules/EC2 security groups are all set up correctly to receive connections from the outside world.
I also have an Application Load Balancer, which is supposed to route traffic to the 3 apps depending on the host name, but it always gives me "504 Gateway Time-out". I've checked all the settings but I can't see what's wrong and I'm not really sure how to troubleshoot it from here.
The ALB has a single HTTPS/443 listener, with a cert that's valid for mydomain.com, app1.mydomain.com, app2.mydomain.com, app2.mydomain.com.
The listener has 3 rules, plus the default rule:
Host == app1.mydomain.com => app1-target-group
Host == app2.mydomain.com => app2-target-group
Host == app3.mydomain.com => app3-target-group
Default action (last resort) => default-target-group
Each target group contains only the single EC2 instance, over HTTP, with the following ports:
app1-target-group: 3000
app2-target-group: 3001
app3-target-group: 3002
default-target-group: 3000
Given that I can access the app directly, I'm sure it must be a problem with the way I've configured the ALB/listener/target groups. But the 504 doesn't give me much to go on.
I've tried to turn on access logs to an S3 bucket, but it doesn't seem to be writing anything there. There's a single object called ELBAccessLogTestFile, and no actual logs in the bucket.
EDIT: Some more information... I actually have nginx installed on the EC2 instance, which is where I was previously doing the SSL termination and hostname-to-port mapping/routing. If I change the default-target-group above to point to port 443 over HTTPS, then it works!
So for some reason, routing traffic
- from the ALB to the EC2 instance over HTTPS on port 443 -> OK!
- from the ALB to the EC2 instance over HTTP on port 3000 -> Broken!
But again, I can hit the instance directly on HTTP/3000 from my laptop.
Communication between resources in the same security group is not open by default. Security group membership alone does not provide special access. You still need to open the ports in the security group to allow other resources in the security group to access those ports. You can specify the security group ID in the rule's source field if you don't want to open it up beyond the resources in the security group.
I've been using AWS for a few months without any problem. But from yesterday, I can't access the website. When I ping the IP (52.24.23.108) it displays request time out. Server's status is okay - that I checked from AWS console. Isn't it a network problem of Amazon Webservices?
You need to enable the specified network traffic type (ICMP) through your security groups for your instance. You can do this by choosing Security Groups > select your security group and choose Edit Inbound Rules
Choose "ICMP" from the dropdown and source (* if you want it from everywhere) then Add Rule
PINGs should work!
A couple things could cause this, most likely you provisioned the instance with a public IP, by NOT a n elastic IP. If you had a server restart, either by your doing or by AWS, then your public IP would be dropped. If you did use a elastic IP, then look at your security group to see if you allow icmp still or if the security group changed.
Another cause may be if a server level firewall had been disabled in the past, but if your server went through a restart it may have started again. What base OS are you using?