One of the data providers, only offers transfer to an FTP server.
To test connection I started an FTP server in a public subnet and opened port:21 in Security Group, unfortunately the data did not reach there, so in VPC Flow Logs I checked that apart from port:21, there are other different ports that need to be opened, but they change so often that I am not able to add all of them to Security Group:
I want my ftp server in private subnet and some sort of network interface to handle incoming connections.
Therefore I want to set up either Network load balancer or EC2 Jump host (I need Bastion host because I don't want to assign elastic IP to another instance, just one with elastic IP and then rest of instances in private subnet).
Network load balancer has ports that it listens to, due to the fact that there are a lot of ports and they change, I am not able to add them all. Is there a way to bypass this?
The second approach is to setup an EC2 Bastion Host that would accept all connections but forward what is on port 21
Does this even make sense? Is there any pattern that is easier?
If you have any amount of choice of approach, commit to SFTP instead, last time I saw it it did do its job, exactly through bastion in a setup similar to yours.
https://dev.to/tanmaygi/how-to-create-a-sftp-server-on-ec2centosubuntu--1f0m
Related
I have a private RDS instance that I want to connect to using bastion host.
I've found a couple of tutorial on how to set it up which doesn't seem too advanced, but I struggle to understand what a bastion host actually is.
All the tutorials I've seen just creates an empty ec2 instance (bastion host) and edit the RDS security group to allow incoming traffic from it and voila, connection from local machine is working.
What I struggle to understand is that there's no configuration on the ec2 instance that enables this behaviour.
Wouldn't that mean that any server that have access to RDS could be used as a bastion host?
For example, I have an EKS cluster where I host a couple of services.
Some of these services are supposed to have access to RDS.
So in order for the services to access RDS I put RDS in the same VPC and Security Group as eks-nodegroups.
Even though the services that need access to RDS aren't publicly accessible, there are publicly accessible services that are running in the same VPC and Security Group.
Would I then be able to use one of the publicly accessible services as a bastion host in order to gain access to RDS from anywhere, thus making it public?
From Bastion - Wikipedia:
A bastion or bulwark is a structure projecting outward from the curtain wall of a fortification, most commonly angular in shape and positioned at the corners of the fort:
It 'sticks out' from the walled portion of the city and provides added security by being able to target attackers attempting to scale the wall. In a similar way, a bastion host 'sticks out' from a walled computer network, acting as a secure connection to the outside world.
When using an Amazon EC2 instance as a Bastion Host, users typically use SSH Port Forwarding. For example, if the Amazon RDS database is running on port 3306, a connection can be established to the Bastion server like this:
ssh -i key_file.pem ec2-user#BASTION-IP -L 8000:mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306
This will 'forward' local port 8000 to the bastion, which will then forward traffic to port 3306 on the database server. Thus, you can point an SQL client to localhost:8000 and it would connect to the Amazon RDS server. All software for making this 'port forward' is part of the Linux operating system, which is why there is no configuration required.
Yes, you can use anything as a Bastion Host, as long as it has:
The ability to receive incoming connections from the Internet
The ability to (somehow) forward those requests to another server within the VPC
A Security Group that permits the inbound traffic from the Internet (or preferably just your IP address), and the target resource permits incoming traffic from this security group
I am making a Slackbot on my AWS EC2, and I need to open port 3000 for public to listen post requests from Slack whenever users do some actions because Slack doesn't provide their IP range.
I wonder if there are any security issues with my EC2 if I open a port publicly ? I also use this EC2 to run Airflow.
Open ports can be dangerous when the service listening on the port is misconfigured, unpatched, vulnerable to exploits, or has poor network security rules.
Attackers use open ports to find potential exploits. To run an exploit, the attacker needs to find a vulnerability.
AWS works on Shared Responsibility Model - means AWS is responsible for “Security of the Cloud” and Customer is responsible for “Security in the Cloud”
It is suggested to put your EC2 instance in the private subnet and place a load balancer in the public subnet.
The public internet traffic shall only talk to the load balancer rather than the instance itself.
Then you can create a WAF and attach it to the load balancer to avoid the attack ( such as DDoS etc.)
I have configured and passed the health check for my AWS ELB(load balancer), but I was trying to do a ping or send a packet to the tcp port 9300 there is no ip address for the ELB.
I have an EC2 instance at the end of the ELB which has Elasticsearch running on it.
The ELB that I configured is an internal ELB so it doesn't have a public IP address for it.
I was wondering if there is a way I can ssh? or do something to ping the ELB?
I am pretty new to AWS and read all the trouble shooting from AWS official website, but couldn't find a solution.
The goal that I am trying to achieve is to test whether my internal Amazon EC2 load Balancer is working properly.
I got the internal ELB ip address with the ping command, however, I am not able to ping or crul to that IP address.
I what to know what I am doing wrong.
Is it the way that I want to access a private network is in correct?
An Elastic Load Balancer is presented as a single service, but actually consists of several Load Balancing servers spread across the subnets and Availability Zones you nominate.
When connecting to an Elastic Load Balancer, you should always use the DNS Name of the Elastic Load Balancer. This will then resolve into one of the several servers that are providing the load balancing service.
Load Balancers are designed to pass requests and return responses. The next time a user sends a request, it might be sent to a different back-end service. Thus, it is good for web-type traffic but not suitable for situations requiring a permanent connection, such as SSH. You can configure sticky sessions for HTTP connections that will use cookies to send the user to the same back-end server if required.
The classic Elastic Load Balancer also supports TCP protocol, but these requests are distributed in a round-robin fashion to the back-end servers so they are also not suitable for long-lasting sessions.
Bottom line: They are great for request/response traffic that needs to be distributed across multiple back-end servers. They are not suitable for SSH.
Site-note: Using PING to test services often isn't a good idea. Ping is turned off in Security Groups by default since it can expose services and isn't good from a security perspective. You should test connectivity by connecting via the expected protocols (eg HTTP requests) rather than using Ping. This applies to testing EC2 connectivity, too.
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.
With a webserver (apache or nginx) I am able to find the x-forwarded-for header and find the client IP rather than the ELB's IP.
Can I do the same thing using IPTables so that I am able to block certain IP addresses?
I can do this at the webserver level. However, I think this is a bit inefficient and I am hoping I can achieve this with IP Tables or something similar?
Since July 30th ELB supports Proxy Protocol. As stated in the end of this thread in the AWS forum:
Elastic Load Balancing (ELB) now supports Proxy Protocol version 1.
This feature allows you to identify the client’s connection
information when using TCP load balancing, providing additional
insight into visitors to your applications. Having this information
can be useful for analyzing traffic logs, gathering connection
statistics, troubleshooting, or managing whitelists of IP addresses.
You must enable Proxy Protocol in the ELB.
The developers guide has more information about Proxy Protocol.
You can't do this with iptables, because iptables will only ever see the IP address of the elastic load balancer, since the ELB is what is establishing the connections to your instance.
Using the web server to block certain x-forwarded-for values isn't particularly inefficient, but if you want to control who can access your ELB by IP address, that can also be accomplished with the Security Group attached to the ELB.
Update: Your comment is partially correct, because, at least as of now, ELB on EC2 "classic" does not support an inbound security group or network access control list, but ELB on VPC does.
Q: Can I configure a security group for the front-end of the Elastic Load Balancer?
If you are using Amazon Virtual Private Cloud, you can configure security groups for the front-end of your Elastic Load Balancer. — http://aws.amazon.com/ec2/faqs/#ELB6
Security groups are easiest to use when you need to allow a relatively small set of specific IP address ranges. If you want to allow most but block a few, then a VPC Network Access Control List is the easier approach.