Remote and secure use of Docker API with Python (Part I of II)

This blog post is going to be divided into two posts, in the first one I will do an introduction to SSH tunnels, in the follow-up I will address the issue mentioned in the title, that is: how one can go about securely connecting to a remote instance running docker using Python.

Introduction

A SSH tunnel consists of an encrypted tunnel created through a SSH protocol connection. A SSH tunnel can be used to transfer unencrypted traffic over a network through an encrypted channel.

SSH tunnels also provide a means to bypass firewalls that prohibit or filter certain internet services. For example an organization may block HTTP requests using a proxy filter, but users may not wish to have their web traffic monitored or blocked by the organization’s proxy filter. If users can connect to an external SSH server, they can create a SSH tunnel to forward a given port on their local machine to port 80 on a remote web-server via the external SSH server.

Internet-based remote access also adds significant risk. Sensitive data can be intercepted, modified, or replayed anywhere between remote workers and the corporate firewall. Broadcast access technologies like cable and wireless are especially vulnerable. Whenever a computer is connected to the Internet, it becomes a potential target for intruders. Just imaging a common situation: travelers using a hotel or airport wireless LAN (Fig. 1).

Fig. 1: HTTP request in public LAN

Fig. 1: HTTP request in public LAN

In the situation described in Fig.1, Bernardo would like to connect in a secure way not susceptible to eavesdropping or interception. Some of the attacks that Bernardo could suffer are:

  • Sniffing attacks: HTTP protocol transfers unencrypted plain text so anyone using a sniffer such as Wireshark or Ettercap, could easily intercept our network traffic.

  • Man in the Middle (MitM): active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.

  • ARP Spoofing: technique whereby an attacker sends fake (“spoofed”) Address Resolution Protocol (ARP) messages onto a Local Area Network. Generally, the aim is to associate the attacker’s MAC address with the IP address of another host (such as the default gateway), causing any traffic meant for that IP address to be sent to the attacker instead, allowing it to intercept data frames on a LAN, modify the traffic, or stop the traffic altogether.

 

Example

Let’s say that HTTP traffic is being blocked using a proxy filter in the organization. Any kind of HTTP request to a web server will be blocked by the proxy. Furthermore, we want to connect in a secure way to not be susceptible to the attacks mentioned above.

To deal with this situation, we can use ssh port forwarding to create a ssh tunnel between our computer and the web server, redirecting all HTTP requests through the local forwarding bound port.

Let’s name the machine at the organization we will use as “mycomputer” and the web server we want to connect to as “webserver” (see Fig.2). First of all, we will need to install openssh-server in the web server and append our public key into ~/.ssh/authorized_keys to allow us to connect from “mycomputer” using our private key through ssh.

To create this ssh tunnel, we will use our local port 6000, executing the following command in “mycomputer”:

ssh -N -f -L 6000:localhost:80 bernardo@webserver

-f tells ssh to go into the background just before it executes the command

-L 6000:localhost:80 is in the form of -L local-port:host:remote-port. 

-N instructs OpenSSH to not execute a command on the remote system.

In this case port mycomputer:6000 is connected to webserver:80 through ssh. If the SSH server is separated from the web server instead of localhost it would be:

ssh -N -f -L 6000:webserver:80 bernardo@sshserver
Fig.2: Proxy allowing HTTP connection using ssh tunnel through localhost:6000 (in blue) and rejecting an HTTP request to webserver:80 (red)

Fig.2: Proxy allowing HTTP connection using ssh tunnel through
localhost:6000 (in blue) and rejecting an HTTP request to webserver:80 (red)

With that I conclude this first post. Stay tuned for the follow up.

Happy hacking, Bernardo

Posted in Tutorial

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories
%d bloggers like this: