SSH over Openssl over Haproxy - contourner les blocages

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 :

frontend ft_tcpssl
    # Local frontend
    bind 127.0.0.1:1443 ssl crt /etc/your/certs accept-proxy
    mode http
    [...] # Vos acl et traitement http classiques

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

L'option 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 :

frontend 443-in
    bind YOUR_IP:443
    mode tcp # On est 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'établir, 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

# 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 :

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 !

ssh -p 443 YOUR_IP

Modifications du frontend SSL

La première modification va se faire sur le frontend SSL, qui va porter en plus du déchiffrement classique du flux, de nouveaux tests pour détecter une connexion SSH.

On va en gros faire le même traitement sur les en-têtes des paquets que dans notre première étape de frontend-tcp-ssl-ssh, mais cette fois sur le flux SSL déchiffré.

Comme ce ne sera plus votre frontend http standard qui déchiffrera le flux, on va le modifier de nouveau pour écouter sur le port 80 sans chiffrement (rien ne sort, tout reste en interne)

frontend http_in
    # Local frontend
    bind 127.0.0.1:80 accept-proxy
    mode http
    [...] # Vos acl et traitement http classiques

Et on récupère le port 1443 du localhost vers lequel notre backend TCP déjà existant renvoie le flux pour traiter notre flux SSL :

frontend ft_tcpssl
    bind 127.0.0.1:1443 ssl crt /etc/haproxy/cert/ accept-proxy
    mode tcp # On reste en TCP pour le moment

    # On enrichit les logs avec les infos venant du TCP
    log-format "%ci:%cp [%t] %ft %b/%s %Tw/%Tc/%Tt %B %ts %ac/%fc/%bc/%sc/%rc %sq/%bq dst:%[var(sess.dst)] http:%[var(sess.ishttp)] ssh:%[var(sess.isssh)] "
    tcp-request content set-var(sess.dst) ssl_fc_sni
    tcp-request content set-var(sess.ishttp) req.proto_http
    tcp-request content set-var(sess.isssh) req.payload(0,7)

    # Une fois le flux ssl déchiffré on peut verifier la payload pour du SSH
    tcp-request inspect-delay 5s
    acl trafic_ssh req.payload(0,7) -m beg "SSH-2.0"
    tcp-request content accept if trafic_ssh   # accept SSH

    # Et enfin, on transmet vers les backends
    use_backend bk_local_https if HTTP
    use_backend bk_sshssl if trafic_ssh

On a déjà vu la plupart de ces options dans la première partie, mis à part le fait qu'on déchiffre le flux, rien de nouveau ici 😄

L'intelligence va se faire dans les backends ! Notamment celui du SSH

Backend SSH enrichit au SSL

Le premier backend est très simpliste, il va renvoyer vers votre frontend http classique, pour un traitement du flux HTTP sans plus de fioriture :

backend bk_local_https
    mode http
    http-request add-header X-Forwarded-Proto https
    server httplocal 127.0.0.1:80 send-proxy

Là où on va prendre un peu plus de temps, c'est sur le backend SSH :

backend bk_sshssl
    mode tcp
    timeout server 2h

    # Avec le SSL et ses headers SNI on peut choisir le serveur cible
    ## NEED haproxy > 2.0
    tcp-request content set-dst var(sess.dst)

    server ssh 0.0.0.0:22

Ici, on reste en TCP, mais la magie se passe avec la ligne set-dst. Grâce à ça, en utilisant la variable sess.dst définie plus haut dans le frontend, on est capable de modifier à la volée la destination de notre flux SSH.

Cela va nous permettre de taper sur n'importe quel serveur SSH, rien qu'en modifiant le champs SNI de notre commande ssh ! C'est donc beaucoup plus souple que la redirection en dure vers un mono-serveur comme dans notre première partie.

C'est également plus risqué, puisque techniquement n'importe qui sachant que vous avez implémenté ça pourrait s'en servir pour rebondir vers n'importe quel serveur en SSH, comme si la connexion venait de votre propre connexion. Notamment, on pourrait initier des attaques (DDOS, bruteforce, crawl, ...) en traversant haproxy et en se planquant derrière votre IP.

On va donc voir comment limiter ces exploits !

Sécuriser l'accès SSH

J'ai mis en place plusieurs garde-fou :

• Frapper avant d'entrer : pour tromper les bots, on va faire en sorte qu'il faille initier 3 connexions à la suite avant de réellement se connecter
• Pas plus de 50 connexions simultanées autorisée
• Connexion uniquement à une liste de serveurs autorisés

On va devoir créer une sticky table dédiée à travers un backend dummy, car de base il n'existe qu'une seule stick-table par proxy (http://docs.haproxy.org/2.8/configuration.html#stick-table)

On va également enrichir notre backend bk_sshssl Note : À l'exception de l'acl utilisant le SNI, ces sécurités peuvent être ajoutée au backend ssh bk_ssh tout simple vu plus haut !

# Pour avoir plusieurs sticky-table, on utilise un dummy backend
backend dummy_st_sshssl_src
    stick-table type ip size 1m expire 12h store conn_rate(30m)

backend bk_sshssl
    mode tcp
    timeout server 2h

    # Serveurs autorisés
    acl allowed_destination var(sess.dst) -m ip RESEAU/24 IP/32
    tcp-request content reject if ! allowed_destination

    # On frappe avant d'entrer !
    tcp-request content track-sc0 src table dummy_st_sshssl_src
    tcp-request content reject if { sc0_conn_rate(dummy_st_sshssl_src) le 3 }

    # Pas plus de 50 requêtes simultanees
    tcp-request content reject if { sc0_conn_rate(dummy_st_sshssl_src) gt 50 }

    # Avec le SSL et ses headers SNI on peut choisir le serveur cible
    ## NEED haproxy > 2.0
    tcp-request content set-dst var(sess.dst)

    server ssh 0.0.0.0:22

Modifiez comme bon vous semble RESEAU/24 ou IP/32 pour indiquer les réseaux ou serveurs autorisés à être joint par ces connexion SSH. Il vous suffit de les séparer par des espaces.

Et comment qu'on s'y connecte ?

Pour vous y connecter, il faudra indiquer à SSH d'encapsuler son flux dans du SSL :

ssh  -o ProxyCommand="openssl s_client -quiet  -connect IP_HAPROXY:443 -servername IP_A_SSH"  -l USER dummy.name

Avec :

• IP_HAPROXY: Le hostname ou l'adresse IP de votre proxy
• IP_A_SSH: L'adresse IP que vous souhaitez réellement atteindre en ssh
• -l USER : L'utilisateur ssh à utiliser
• dummy.name: Contrairement à une connexion ssh classique, ce nom ne sera jamais ni résolu ni utilisé pour joindre le serveur ssh. Néanmoins c'est sous ce nom que l'empreinte SSH du serveur sera enregistrée dans votre fichier known_hosts, donc je vous conseille de le changer pour un nom pertinent en rapport avec IP_A_SSH

Au passage petit conseil d'expérience, par défaut haproxy traite les flux dans un contexte "question/réponse", puisqu'après tout http fonctionne rarement en flux continu, contrairement à SSH. Du coup, ça génère des déconnexions de vos sessions SSH si elle ne font rien pendant quelques minutes/secondes, ce qui est un peu chiant.

Je vous invite à ajouter côté client ssh une configuration keepalive pour que votre client se charge d'envoyer des ping dans le tunnel et ainsi maintenair la connexion :

$ cat ~/.ssh/config
Host *
    ServerAliveInterval 10

Ici on envoie un ping au serveur toutes les 10 secondes, à ajuster selon votre configuration de timeout haproxy.