SSH Tunnel

Overview

If you have a database that is not publicly accessible, you can allow Simon Data to connect to it by using an SSH tunnel. This is an alternative to VPC Peering Connections.

Advantages

  • Highly secure protocols are utilized for authentication, authorization, and the tunnel between the two points (even if the protocols used within the tunnel are not secure)
  • Keys are typically dedicated for the specific tunnel, limiting abuse capabilities if keys were somehow compromised
  • This is a common approach that network administrators are familiar with

Disadvantages

  • Relies on the public internet for transport
  • Requires secure key exchange prior to tunnel creation
  • Is a single point of failure (ssh tunnels are not highly available)
  • Requires ongoing maintenance to patch and harden

Use this guide to allow Simon Data to connect to your database via an SSH Tunnel. In this scenario, you will launch a publicly accessible SSH server (sometimes called a bastion server) in the same Virtual Private Cloud (VPC) as your database.

You will then configure Simon Data to connect to your SSH server instead of directly to the database. The public SSH server will forward Simon Data’s requests to the private database.

By using this type of connection, you can keep your database hidden from the public internet and instead rely on your SSH server to handle the security and access control for connections to that database.


Requirements

  • A database behind a firewall
  • A publicly accessible SSH server (sometimes called a bastion server) that can reach your database on your internal, private network.
  • Simon Data will provide a public key to access your SSH server
  • Database credentials
  • SSH User to be shared with Simon Data
  • You're responsible for all configuration within your account(s). Simon Data can't perform this work on behalf of customers, and Simon Data does not assume any responsibility for misconfigurations on your infrastructure.
  • Connections are initiated from Simon Data; all other incoming traffic must be denied. The following Simon Data public IP addresses should be allow listed:
    • 54.174.71.70
    • 54.165.60.44
    • 54.165.74.55
    • 52.7.12.28
    • 35.173.87.106
    • 54.152.155.89

Connection Process

πŸ“˜

First, open a support ticket requesting this connection.

Create an SSH Server

A Nested List

Lists can be nested (list inside list):

  1. Launch a new server instance, SSH is the only program required
  2. Configure Instance: ensure the following settings are configured:
    • Network: Select your database's VPC
    • Subnet: Choose a public subnet
    • Auto-assign thepublic IP
  3. Configure a Security Group
    1. Create and assign a new security group
      • Security group name:Simon-Data-SSH
      • Description: SSH server for forwarding requests from SimonData to
    2. Modify the rules to show the following values:
      • Type: SSH
      • Protocol: TCP
      • Port Range: 22 (or alternative if default SSH port is changed)
      • Source:
        • 54.174.71.70
        • 54.165.60.44
        • 54.165.74.55
        • 52.7.12.28
        • 35.173.87.106
        • 54.152.155.89
      • Description: Simon Data Inbound Connection
  4. Add Key Pair
  5. When launching the instance, you are prompted to select an existing key pair or to create a new key pair. Add your public key and the public key provided by Simon Data.

Key and connection exchange

  1. We'll generate a 2048 bit key pair that will be dedicated to each customer and host.
  2. We'll send you the public key via a secure communications method.

Enable Forwarding to the Database from the SSH Server

  1. Find the instance you launched in the previous step.
  2. Copy the Public DNS and Private IP address.
  3. Create a new security group with the following values:
    • Security group name: SSH to {database name}
    • Description: "allows traffic from the Simon Data SSH server to {database name}"
    • VPC: this is the same VPC used for the SSH server and database.
    • With the Inbound tab selected at the bottom of the window, click Add Rule. Enter these values:
      • Type: Custom TCP Rule
      • Protocol: TCP
      • Port Range: the port number of the database
      • Source: Custom; in the blank box to the right enter the Private IP address (from above) with /32 appended at the end
    • Add the security group to your database:
      1. From the AWS Management Console, click on Database>RDS.
      2. From the left side, click Databases.
      3. In the DB identifier column, click the link to your database.
      4. On the database details page, click Modify on the top right.
      5. Scroll down to the Network & Security section. From the Security group drop down menu, add the security group that you created in the previous section
      6. Save the changes by scrolling to the bottom of the page and clicking Continue
      7. On the following page, choose when to apply the changes, then click Modify DB instance

Configure an SSH User for Simon Data

  1. Open terminal and navigate to the directory where you stored the .pem file we provided you.
  2. Connect to your SSH server from the terminal using the default user for your instance.
  3. Once your connected to the server create a user group for Simon Data sudo group add simondata
  4. Create a user named simondata sudo useradd -m -g simondata
  5. Switch to the user sudo su - simondata
  6. Create a hidden directory called .ssh to upload the Simon Data public key:
mkdir ~/.ssh
chmod 0600 ~/.ssh
  1. Enable read and write permissions for the owner on that file.
  2. Add the public key to your authorized_keys file with the following command:
    echo "<Your Public Key>" >> ~/.ssh/authorized_keys
    (Include the quotation marks but replace <Your Public Key> with the key we provided.
  3. Let us know this is ready for testing.

SSH Hardening and Recommendations

πŸ‘

Consider these hardening recommendations

  • Patch SSH server at least monthly
  • Disable empty passwords
  • Change default SSH port
  • Disable root login via SSH (require sudo instead)
  • Disable ssh protocol 1
  • Configure idle timeout interval: to between 300 and 900 (5 to 15 minutes)
  • Allow SSH access to selected users/groups only
  • Disable X11 Forwarding
  • Disable password based SSH login