Archive

Articles taggués ‘tunneling’

How to access a Linux server behind NAT via reverse SSH tunnel

18/05/2016 Comments off

reverse sshYou are running a Linux server at home, which is behind a NAT router or restrictive firewall. Now you want to SSH to the home server while you are away from home. How would you set that up? SSH port forwarding will certainly be an option. However, port forwarding can become tricky if you are dealing with multiple nested NAT environment. Besides, it can be interfered with under various ISP-specific conditions, such as restrictive ISP firewalls which block forwarded ports, or carrier-grade NAT which shares IPv4 addresses among users.

What is Reverse SSH Tunneling?

One alternative to SSH port forwarding is reverse SSH tunneling. The concept of reverse SSH tunneling is simple. For this, you will need another host (so-called « relay host ») outside your restrictive home network, which you can connect to via SSH from where you are. You could set up a relay host using a VPS instance with a public IP address. What you do then is to set up a persistent SSH tunnel from the server in your home network to the public relay host. With that, you can connect « back » to the home server from the relay host (which is why it’s called a « reverse » tunnel). As long as the relay host is reachable to you, you can connect to your home server wherever you are, or however restrictive your NAT or firewall is in your home network.

Reverse SSH Tunneling

 

Set up a Reverse SSH Tunnel on Linux

Let’s see how we can create and use a reverse SSH tunnel. We assume the following. We will be setting up a reverse SSH tunnel from homeserver to relayserver, so that we can SSH to homeserver via relayserver from another computer called clientcomputer. The public IP address of relayserver is 1.1.1.1.

On homeserver, open an SSH connection to relayserver as follows.

homeserver~$ ssh -fN -R 10022:localhost:22 relayserver_user@1.1.1.1

Here the port 10022 is any arbitrary port number you can choose. Just make sure that this port is not used by other programs on relayserver.

The « -R 10022:localhost:22 » option defines a reverse tunnel. It forwards traffic on port 10022 of relayserver to port 22 of homeserver.

With « -fN » option, SSH will go right into the background once you successfully authenticate with an SSH server. This option is useful when you do not want to execute any command on a remote SSH server, and just want to forward ports, like in our case.

After running the above command, you will be right back to the command prompt of homeserver.

Log in to relayserver, and verify that 127.0.0.1:10022 is bound to sshd. If so, that means a reverse tunnel is set up correctly.

relayserver~$ sudo netstat -nap | grep 10022
tcp      0    0 127.0.0.1:10022          0.0.0.0:*               LISTEN      8493/sshd           

Now from any other computer (e.g., clientcomputer), log in to relayserver. Then access homeserver as follows.

relayserver~$ ssh -p 10022 homeserver_user@localhost

One thing to take note is that the SSH login/password you type for localhost should be for homeserver, not for relayserver, since you are logging in to homeserver via the tunnel’s local endpoint. So do not type login/password for relayserver. After successful login, you will be on homeserver.

Lire la suite…

How to secure SSH login with one-time passwords on Linux

22/03/2016 Comments off

As someone says, security is a not a product, but a process. While SSH protocol itself is cryptographically secure by design, someone can wreak havoc on your SSH service if it is not administered properly, be it weak passwords, compromised keys or outdated SSH client.

As far as SSH authentication is concerned, public key authentication is in general considered more secure than password authentication. However, key authentication is actually not desirable or even less secure if you are logging in from a public or shared computer, where things like stealth keylogger or memory scraper can always a possibility. If you cannot trust the local computer, it is better to use something else. This is when « one-time passwords » come in handy. As the name implies, each one-time password is for single-use only. Such disposable passwords can be safely used in untrusted environments as they cannot be re-used even when they are stolen.

One way to generate disposable passwords is via Google Authenticator. In this tutorial, I am going to demonstrate another way to create one-time passwords for SSH login: OTPW, a one-time password login package. Unlike Google Authenticator, you do not rely on any third party for one-time password generation and verification.

What is OTPW?

OTPW consists of one-time password generator and PAM-integrated verification routines. In OTPW, one-time passwords are generated apriori with the generator, and carried by a user securely (e.g., printed in a paper sheet). Cryptographic hash of the generated passwords are then stored in the SSH server host. When a user logs in with a one-time password, OTPW’s PAM module verifies the password, and invalidates it to prevent re-use.

Step One: Install and Configure OTPW on Linux

Debian, Ubuntu or Linux Mint:

Install OTPW packages with aptget.

$ sudo apt-get install libpam-otpw otpw-bin

Open a PAM configuration file for SSH (/etc/pam.d/sshd) with a text editor, and comment out the following line (to disable password authentication).

#@include common-auth

and add the following two lines (to enable one-time password authentication):

auth       required     pam_otpw.so
session    optional     pam_otpw.so

16775121360_d1f93feefa_b

Fedora or CentOS/RHEL:

OTPW is not available as a prebuilt package on Red Hat based systems. So let’s install OTPW by building it from the source.

First, install prerequites:

$ sudo yum git gcc pam-devel
$ git clone https://www.cl.cam.ac.uk/~mgk25/git/otpw
$ cd otpw

Open Makefile with a text editor, and edit a line that starts with « PAMLIB= » as follows.

On 64-bit system:

PAMLIB=/usr/lib64/security

On 32-bit system:

PAMLIB=/usr/lib/security

Compile and install it. Note that installation will automatically restart an SSH server. So be ready to be disconnected if you are on an SSH connection.

$ make
$ sudo make install

Now you need to update SELinux policy since /usr/sbin/sshd tries to write to user’s home directory, which is not allowed by default SELinux policy. The following commands will do. If you are not using SELinux, skip this step.

$ sudo grep sshd /var/log/audit/audit.log | audit2allow -M mypol
$ sudo semodule -i mypol.pp

Next, open a PAM configuration file for SSH (/etc/pam.d/sshd) with a text editor, and comment out the following line (to disable password authentication).

#auth       substack     password-auth

and add the following two lines (to enable one-time password authentication):

auth       required     pam_otpw.so
session    optional     pam_otpw.so

Lire la suite…

Le tunnel GRE

06/11/2015 Comments off

Les tunnels

tunnel greGrâce à un tunnel, il est possible de passer directement d’un point à un autre, sans devoir subir les affres de la circulation à la surface. Les tunnels informatiques s’en rapprochent fortement, en proposant un moyen de relier « directement » deux réseaux privés distants, à travers un inter-réseau aussi complexe que l’internet.

Il existe une grande quantité de moyens pour réaliser des tunnels informatiques. PPP peut être considéré comme un tunnel dans des configurations comme PPPoE ou PPPoA. L2TP (Layer 2 Tunneling Protocol), est utilisé sur les réseaux des opérateurs, par exemple dans les connexions ADSL non dégroupées.

PPTP (Point to Point Tunneling Protocol), utilisé par Microsoft, ou encore les tunnels sur IPSec sont d’autres solutions. L’objectif de ce chapitre est de monter le fonctionnement d’un tunnel sur IP à travers une implémentation standardisée : le tunnel GRE, puis à travers une solution plus sécurisée : OpenVPN.

Merci à _SebF, créateur du site frameip.com, pour son aimable collaboration.

Le principe

Imaginons que nous ayons à intervenir sur deux réseaux privés différents, géographiquement éloignés, les réseaux A et B. Si nous voulons interconnecter ces deux réseaux, nous avons à priori deux possibilités :

  • L’une chère, qui consiste à utiliser une liaison spécialisée, proposée par tout bon opérateur de télécoms. Les technologies utilisées par ces opérateurs afin de créer notre réseau privé sont principalement du type ATM1), MPLS2) et, plus anciennement, Frame Relay.
    Les avantages apportés sont la garantie d’un SLA3) et d’une étanchéité renforcée,
  • l’autre, moins chère, qui consiste à interconnecter ces deux réseaux via de l’internet public.

Oui, mais la seconde solution, à priori moins chère, sera plus limitative.

  • Soit, comme c’est le plus souvent le cas, nous ne disposerons que d’une seule adresse IP publique pour accéder à chaque réseau et dans ce cas, nous ne pourrons pas faire facilement communiquer n’importe quelle machine du réseau A avec n’importe quelle machine du réseau B, puisque ces LANs seront montés avec des adresses IP privées. (Voyez le Partage de connexion, mis en œuvre dans de telles configurations),
  • Soit nous disposons de suffisamment d’adresses IP publiques pour monter nos réseaux avec ces adresses, mais alors, toutes nos machines seront directement exposées sur le Net. Cher et difficile (il n’est pas simple, et encore moins gratuit d’obtenir des plages, même petites,  d’adresses IPv4 publiques, encore qu’avec IPv6, ce sera tout à fait réalisable) et pour le moins dangereux.

Comment faire alors ?

Créer une ligne spécialisée virtuelle, qui passera par l’internet, mais qui fonctionnera presque comme une liaison spécialisée.  Bien sûr, pour ce faire, un tunnel est nécessaire afin de créer l’interconnexion, de garantir l’étanchéité. L’avantage est de ne pas être dépendant d’un opérateur et ainsi, de pouvoir choisir la sortie Internet de chaque site indépendamment les unes des autres. Rien en effet n’interdit de construire plusieurs tunnels, éventuellement sur des connexions internet différentes. Nous disposons de plusieurs technologies telles que PPtP, IPSec et celles qui nous intéressent dans cette documentation : Le tunnel GRE et OpenVPN.

Au niveau IP, un tunnel se présente comme ceci :

vpn-1

Et nous aurons l’impression d’avoir à peu près cela :

vpn-2

Bien que la première couche IP circule normalement sur l’internet, en suivant les routes définies par les opérateurs, celle-ci transporte une seconde couche IP et sur cette couche, tout va se passer comme si les deux routeurs communiquaient directement, par l’intermédiaire d’un réseau IP ne comportant que deux nœuds : les deux routeurs.

Grâce à ce tunnel, tout nœud du réseau A pourra communiquer avec tout nœud du réseau B, les deux réseaux étant construits avec des adresses IP privées.

Super non ?

Oui, mais souvenez-vous que IPv4 est un protocole qui n’est pas sécurisé, que nous allons l’utiliser et qui plus est, sur un réseau plutôt mal famé. L’opération n’est donc pas sans risques.

Lire la suite…

Set Up SSH Tunneling on a Linux / Unix / BSD Server To Bypass NAT

02/09/2015 Comments off

I‘m a new Linux / Unix system user. How can I set encrypted tunnel between my desktop/laptop computer and server in a remote data center to bypass the limits in a network? How do I create a reverse SSH tunnel on Unix-like systems?

SSH tunnelling can be thought as a poor-man’s-VPN. It is handy in situations where you would like to hide your traffic from any body who might be listening on the wire or eavsdropping.

You can use such tunnel between your computer and your Unix/BSD/Linux server to bypass limits placed by a network or to bypass NAT, and more.
Lire la suite…

Categories: Réseau, Système Tags: , ,

Using ssh as a SOCKS proxy on Mac OS X

28/01/2014 Comments off

Introduction

Many times it can be convenient to tunnel your web traffic through a proxy, particularly an encrypted one. This web page shows how to easily tunnel your traffic through an ssh-encrypted proxy on Mac OS X. This allows your traffic to traverse your local network without being visible to snoopers, even when visiting unencrypted sites.

It also allows you to appear to come from a different IP address, allowing you to defeat geolocation schemes. In particular, some credit card processors try to make sure that your credit card billing address is correlated with your IP address, which can be hard on us expatriates. Another example is the free credit report web site which doesn’t seem to work from outside the United States. There are undoubtedly many other practical, legitimate uses for this sort of redirection. Lire la suite…