SSH over Openssl over Haproxy
###############################
:subtitle: \- contourner les blocages
:date: 2023-06-20 10:22
:authors: Victor
:slug: ssh-openssl-haproxy
:category: Réseaux
:tags: ssh, astuces, openssl, haproxy
:keywords: ssh, astuces, openssl, haproxy
:status: published
:summary: contourner les blocages

.. contents::

Contexte
=======================

Parfois, en entreprise ou dans les hôtels, des règles de sécurité sont mises en place pour empêcher les employés de sortir sur d'autres ports que l'http⋅s (ports 80 et 443)

Selon l'intelligence du matériel utilisé, il sera capable de détecter si le flux est de l'http, du ssh, ou un autre protocole interdit et en conséquence, contourner ce genre de protection peut s'avérer complexe.

Bien entendu, jamais je ne conseillerai de contourner les protections mises en place par votre entreprise 😇   
Par contre, rien n'empêche de donner un coup de main à votre SI en pointant les failles du système qu'une personne mal intentionnée pourrait utiliser.

Je vous invite à consulter votre charte informatique quand aux éventuelles conséquences, mais sachez que **si protection il y a, vous devez légalement en être informé par écrit**.

Cela étant posé, je vais ici vous proposer d'utiliser Haproxy pour passer outre 2 types de protections :

1. Un blocage des ports autres que 80/443 sans vérification du type de protocole
2. Un blocage des ports autres que 80/443, avec vérification du type de protocole

L'objectif sera de faire passer **un flux ssh** sur le port 443 (étape 1), puis de **l'encapsuler dans du SSL** (étape 2).

Je partirai du principe que vous avez un serveur avec Haproxy installé et fonctionnel, par exemple pour servir vos sites habituels.

**Disclaimer 1 :** Cette technique vous permettra d'utiliser toutes les fonctionnalités de SSH. J'écris cet article depuis le boulot en committant via un tunnel SSH sur openssl vers mon repo git. Toujours dans l'optique d'entretenir la forme de l'équipe sécurité bien sûr. 🤫 

**Disclaimer 2 :** Retrouvez à la fin de l'article les configurations complètes si vous êtes pressés ^^

PS: Dans le cas où le filtrage se ferait avec un système de `Deep Packet Inspection
<https://fr.wikipedia.org/wiki/Deep_packet_inspection>`_ qui désencapsule les flux SSL pour les analyser, cela ne fonctionnera pas. Mais si vous avez une protection de ce genre, ça sous-entends que l'entreprise peut (et le fait) voir absolument tout ce que vous faites en https, que ça soit les mots de passe de votre banque ou les messages privés envoyés sur votre discord. Je vous invite à insulter votre DSI (Avec virulence) puis à changer de boite 😄 

Étape 1 : SSH sur 443
=====================

La première étape va consister à assez simplement faire passer votre flux SSH sur le port 443. Si vous rencontrez un simple pare-feu qui bloque tous les ports sauf le 443, cela permettra de contourner le blocage sans problème.

Côté serveur on pourrait simplement faire écouter sshd sur ce port, ou utiliser iptables pour NATer le port 443 vers le port 22 de votre serveur **mais** c'est moins fun, et puis si vous avez déjà des sites web votre port 443 est déjà utilisé.

C'est là qu'Haproxy va intervenir car il est capable de détecter si le flux entrant est du SSH ou de l'http !  
Cette étape est assez simple, on va demander à Haproxy de rediriger le flux http (plus précisément, ssl) vers votre frontend habituel, et le flux ssh **vers un serveur particulier**. On verra ensuite une technique pour dire à Haproxy quel serveur ssh on souhaite joindre 😄 

.. figure:: {static}/images/ssh-openssl-haproxy/ssh_simple.png
    :width: 500px
    :alt: Description de l'objectif à atteindre : Un frontend Public 443 redistribue les flux vers un backend SSH et un backend SSL, ce dernier renvoyant ensuite vers le fronted HTTP SSL habituel

    Première étape : séparer SSH et SSL

Frontend TCP SSL/SSH
--------------------

Tout d'abord on va modifier votre frontend qui écoute sur le port 443. En toute logique, il devrait écouter sur l'adresse IP exposée vers l'extérieur, mais on va lui dire d'écouter plutôt sur l'adresse localhost, afin de créer ensuite un nouveau frontend qui s'occupera des accès entrants.  

Modifiez donc votre frontend existant :

.. code-block:: bash

    frontend ft_tcpssl
        # Local frontend
        bind 127.0.0.1:1443 ssl crt /etc/your/certs accept-proxy

Modifiez bien sûr le chemin ``/etc/your/certs`` par votre répertoire habituel pour stocker vos certificats.

L'option `accept-proxy
<http://docs.haproxy.org/2.4/configuration.html#5.1-accept-proxy>`_ indique de n'accepter que les connexions de type PROXY, ce qui sera le cas via notre chaine de frontend/backend Haproxy et assure de garder un maximum d'information sur la connexion d'origine.

Ensuite, on va configurer un nouveau frontend qui se chargera de recevoir le flux sur 443 et de filtrer le flux chiffré en SSL (typiquement de l'https) de celui chiffré via SSH

Pour cela :

.. code-block:: bash

    frontend 443-in
        bind YOUR_IP:443
        mode tcp # On est bien sûr en TCP ici et pas encore en http

        # On verifie les types de trafics parmi tcp over ssl, http et SSH
        tcp-request inspect-delay 5s # Une connexion ssh peut être longuette à s'étblir, on prends le temps d'inspecter le flux
        acl trafic_ssl       req.ssl_ver    gt 0
        acl trafic_ssh_raw req.payload(0,7) -m str SSH-2.0

Ici on définit **deux ACLs** : 
 - L'acl ``trafic_ssl`` se base simplement sur le fait que le flux est chiffré avec ssl
 - l'acl ``trafic_ssh_raw`` quand à elle, vérifie les 7 premiers bits de payload de la connexion TCP, qui contiennent ``SSH-2.0`` dans le cas d'une transaction SSH !

 Sur la base de ces ACL, on peut facilement rediriger vers les backends qui vont bien

.. code-block:: bash

    # Si SSL on envoie au backend TCP pour dechiffrement
    use_backend bk_tcpssl if trafic_ssl
    # Si ssh direct on envoie au backend ssh
    use_backend bk_ssh if trafic_ssh_raw

Backends SSL et SSH
-------------------

On va pouvoir établir les backends :

.. code-block:: bash

    backend bk_tcpssl
        mode tcp
        timeout server 2h
        server ft_tcpssl 127.0.0.1:1443 send-proxy

    backend bk_ssh
        mode tcp
        timeout server 2h

        server ssh SSH_IP_SERVER:22

On retrouve ici le frontend ``ft_tcpssl``, votre frontend habituel qui gère l'https, avec le mot clef ``send-proxy`` pour transmettre le flux sur localhost en mode PROXY.

Le bk_ssh quand à lui reste très simple, vous indiquez l'adresse IP du serveur sur lequel vous souhaitez vous connecter en ssh comme cible du backend.
(Rappel, on verra ensuite comment se connecter à plusieurs serveurs ssh sans devoir en indiquer un en dur 😜 )

Cette première configuration est assez simple, et vous permettra simplement en lançant une connexion SSH sur le port 443 de vous retrouver sur votre serveur habituel.

Les connexions pourront se faire par clef ou par mot de passe, de la manière dont vous fonctionnez en général !

.. code-block:: bash

    ssh -p 443 YOUR_IP


Étape 2 : SSH sur SSL
=====================

Dans cette 2eme étape, on va ajouter une brique qui permettra d'injecter un flux SSH dans une connexion chiffrée avec SSL.

Bien que techniquement plus complexe à utiliser et à configurer, on ajoute ici 2 gros avantages.

1. Le fait qu'un pare-feu intelligent capable de faire la différence entre https et ssh sera par contre incapable de bloquer ce nouveau flux, qu'il ne pourra que considérer comme de l'https
2. La possibilité d'utiliser l'en-tête SNI des connexions SSL pour choisir dynamiquement la cible de notre connexion SSH

On garde la configuration précédente, mais on va ajouter une nouvelle vérification de flux **une fois le SSL déchiffré**, pour voir si on à affaire à de l'http ou du SSH !

.. figure:: {static}/images/ssh-openssl-haproxy/ssh_over_ssl.png
    :width: 700px
    :alt: Description de l'objectif à atteindre : Un frontend Public 443 redistribue les flux vers un backend SSH et un backend SSL, ce dernier renvoyant ensuite vers un nouveau frontend SSL. Ce nouveau frontend va se charger de déchiffrer le flux SSL, puis de rediriger le flux final vers le frontend HTTP habituel ou vers le serveur SSH demandé.

    Deuxième étape : Séparer SSH et HTTP depuis le flux SSL
