I am trying to set up a bastion host in AWS in order to perform administrative options on an RDS instance in a private subnet. I am following the instructions from the official documentation (https://docs.aws.amazon.com/quickstart/latest/linux-bastion/step1.html), but there it is not clear how the bastion will know which RDS instance to connect to. How would I make sure that it can 'talk to' my intended RDS? (as far as I understand, the key pair is just something I can create anytime and enter to connect to the bastion itself, but not the RDS, or am I wrong?)
The documentation you linked uses an AWS CloudFormation stack to deploy the Bastion. I'm not sure exactly what configuration it is using, so my answer will be generic, rather than applying to this specific situation.
The normal configuration is:
A database in a private subnet
A Bastion server (EC2 instance) in a public subnet
A connection is made to the Bastion, which then allows an on-connection to the database
There are a number of ways of connecting to the database through the Bastion. Here's one that I use:
ssh -i key.pem ec2-user#BASTION-IP -L 3306:DATABASE-DNS-NAME:3306
This tells the SSH connection to forward any traffic sent to my local port 3306 (the first number), through the SSH connection, but then send it to DATABASE-DNS-NAME:3306 (the database server). Any response from the database will come back the same way.
Then, when I wish to refer to the database from my computer, I reference:
localhost:3306
It appears that the database is on my own computer, but the traffic is actually sent across SSH to the Bastion, then onto the database.
There are newer and better ways of doing this forwarding that other people might (hopefully) add as a comment or another answer, but this is the way I make my connections through a Bastion.
Fun fact: A Bastion is the bit of a castle wall that sticks out, allowing defenders to shoot arrows at attackers attempting to climb the wall. In a similar way, the Bastion Server sticks out into the Internet, beyond the protected part of the network.
Related
We have a site to site VPN connection from our AWS cloud to the customer's on site network. Our web application login requires the authentication from the customer's active directory and hence the need for VPN connection.
When our application is not being used for a while the VPN tunnel goes down, due to which when a user tries to log into the application he is unable to due to downed tunnel. It takes some time for the tunnel to get up after which everything works properly.
I had a call with the customer's IT people and it seems they have set up a keep alive bit (DPD settings) on their end but still the tunnel keeps going down. AWS support isn't much of a help either.
I google around and discovered that one way we can keep the tunnel alive is by "sending a ping to the target from the device sourced from the outside interface. A possible destination for the ping is an instance within the VPC"
AWS documentation also suggests "to create a host that sends ICMP requests to an instance in your VPC every 5 seconds."
I already have an private subnet EC2 instance (with only private IP) in my VPC.
My question is, do I need to create another ec2 instance in my VPC private subnet and ping the first one from the other every 5 seconds?
Would I need to write a shell script for this?
I am basically confused about from where to ping, whom to ping and how to ping.
Ping any remote AWS instance from your on-premise site, thereby causing traffic over the vpn. Just schedule it in windows task scheduler, and use the basic command line ping.
AWS and network noob. I've been asked to migrate QuickBooks Desktop Enterprise to AWS. This seems easy in principle but I'm finding a lot of conflicting and confusing information on how best to do it. The requirements are:
Setup a Windows Server using AWS EC2
QuickBooks will be installed on the server, including a file share that users will map to.
Configure VPN connectivity so that the EC2 instance appears and behaves as if it were on prem.
Allow additional off site VPN connectivity as needed for ad hoc remote access
Cost is a major consideration, which is why I am doing this instead of getting someone who knows this stuff.
The on-prem network is very small - one Win2008R2 server (I know...) that hosts QB now and acts as a file server, 10-15 PCs/printers and a Netgear Nighthawk router with a static IP.
My approach was to first create a new VPC with a private subnet that will contain the EC2 instance and setup a site-to-site VPN connection with the Nighthawk for the on-prem users. I'm unclear as to if I also need to create security group rules to only allow inbound traffic (UDP,TCP file sharing ports) from the static IP or if the VPN negates that need.
I'm trying to test this one step at a time and have an instance setup now. I am remote and am using my current IP address in the security group rules for the test (no VPN yet). I setup the file share but I am unable to access it from my computer. I can RDP and ping it and have turned on the firewall rules to allow NB and SMB but still nothing. I just read another thread that says I need to setup a storage gateway but before I do that, I wanted to see if that is really required or if there's another/better approach. I have to believe this is a common requirement but I seem to be missing something.
This is a bad approach for QuickBooks. Intuit explicitly recommends against using QuickBooks with a file share via VPN:
Networks that are NOT recommended
Virtual Private Network (VPN) Connects computers over long distances via the Internet using an encrypted tunnel.
From here: https://quickbooks.intuit.com/learn-support/en-us/configure-for-multiple-users/recommended-networks-for-quickbooks/00/203276
The correct approach here is to host QuickBooks on the EC2 instance, and let people RDP (remote desktop) into the EC2 Windows server to use QuickBooks. Do not let them install QuickBooks on their client machines and access the QuickBooks data file over the VPN link. Make them RDP directly to the QuickBooks server and access it from there.
I have a database set up (use RDS) in a private subnet, and a bastion is set up in front of it in a public subnet. The traditional way to access this database from local laptops is to set up an ssh tunnel on that bastion/jumpbox and map the database port to local. But this is not convenient to development because we need to set up that tunnel everytime before we want to connect. I am looking for a way to access this database without setting up an ssh tunnel first. I have seen a case where the local laptop directly uses that bastion's ip and its 3306 port to connect to the database behind. I have no idea how it is done.
BTW, in that case I saw, they don't use port forwarding because I didn't find any special rules in the bastion's iptable.
There are several ways to accomplish what you are trying to do, but without understanding the motivation fully it is hard to say which is the "Best Solution".
SSH Tunneling is the defacto standard of accessing a resource in a private subnet behind a public bastion host. I will agree that SSH Tunnels are not very convenient, fortunately, some ide's and many apps are available to make this as easy as a click of a button once configured.
Alternatively, you can set up a client to site VPN to your EC2 environment which would also provide access to the private subnet.
I would caution anything you do which proxies or exposes the DB cluster to the outside world in a naked way such as using IP tables, Nginx, etc. should be avoided. If your goal is this, then the correct solution is to just make the DB instance publicly exposed. But be aware any of these solutions which do not make use of tunneling in (such as VPN or SSH Tunnel) would be an auditory finding, and open your database to various attack vectors. To mitigate it would be recommended that your security groups should restrict port 3306 to the public IP's of your corporate network.
To connect to a remote machine, my public key needs to be added to its authorized_keys. By that logic, the public key for bastion would have an entry in authorized_keys of an EC2. Doesn't that mean if someone gets access to my bastion they will automatically have access to my EC2 provided they have the right host and user? How did Bastion then enhance the security of my EC2? Wouldn't it be equally difficult for a hacker to get his public key added to either the Bastion or EC2?
You are quite correct. It is not a good idea to store keys on a Bastion host.
The purpose of a Bastion is to be the part of your architecture that "sticks out" onto the Internet, with the other resources hidden behind the "wall".
In fact, the Bastion name refers to "a projecting part of a fortification built at an angle to the line of a wall, so as to allow defensive fire in several directions.".
Just as a castle has a defensive bastion, you should also be defensive with your bastion by not storing keys on it.
Instead, you can use Agent Forwarding. This allows you to SSH to the bastion, then use the same keypair to login to another computer without having to store the keypair on the bastion.
There's plenty of information online to explain Agent Forwarding, such as: How to use SSH properly and what is SSH Agent Forwarding - DEV Community
We're using IronWorkers from http://www.iron.io/ to do some heavy image and PDF processing.
I want to connect an IronWorker instance to a RDS MySQL database on our Amazon AWS account, so that the our code running on the IronWorker can directly make chances in this database.
I'm not too sure how to go about this, as we have a few technical issues to work around.
My understanding is that IronWorkers that get launched won't be in the RDS instance's security group, and would be blocked from accessing our RDS MySQL instance. It won't be possible to create a security group, by creating an CIDR/IP entry either, since we don't know what the IP address for the launched server is going to be.
Another approach would be to somehow get the .pem file on the launched instance, and configure the MySQL connection to use a PEM file through SSH, but I'm not too convinced that it's the most secure way to go about achieving a connection.
Does anyone know of any means a direct connection can be made from an IronWorker instance to a MySQL RDS instance?
There's a tricky way to get around this by finding the internal IP of your RDS instance then using that instead of the dns entry AWS gives you, example:
$ ping myserverabcdefg.us-east-1.rds.amazonaws.com
PING ec2-X-XX-XXX-X.compute-1.amazonaws.com (10.111.222.33) 56(84) bytes of data.
Then add a dns entry using that internal host and and use the new dns entry in your workers.
Let us know how that works.