System-Linux

Aller au contenu | Aller au menu | Aller à la recherche

Compilation, Installation et Configuration de SSLH.

iscsi jpeg

Joindre son serveur SSH sur le port 443 peut être utile, en particulier si vous êtes connecté derrière un routeur firewall qui fait du zèle.

Problème votre serveur Web utilise déjà ce port pour les connexions SSL ? SSLH a la solution.

SSLH est multiplexeur SSL/SSH, c'est lui qui va se chargera d'écouter sur votre port 443 (tcp) et de rediriger les requêtes qu'il reçoit vers le service approprié.

Dans notre exemple SSLH va être installé sur une machine CentOS 5.4, et aiguillera nos requêtes vers OpenSSH ou Apache.

Compilation

Pour la compilation c'est du classique, un seul fichier source (sslh.c) et un Makefile. Seul subtilité ici nous désirons installer le binaire généré dans "/srv".

# wget http://www.rutschle.net/tech/sslh-1.7a.tar.gz
# tar xvzf sslh-1.7a.tar.gz
# cd sslh-1.7a
# make PREFIX=/srv # PREFIX à modifier selon votre besoin. (/usr/local par défaut)
# make install

Installation du script d'init

Un script d'init pour CentOS est fournit avec l'archive de SSLH (scripts/etc.rc.d.init.d.sslh.centos), cependant se script est un peu buggé c'est pour cela que je vous propose d'installer ma propre modification de ce script.

# wget http://www.system-linux.eu/public/scripts/sslh -O "/etc/init.d/sslh"
# chmod 755 /etc/init.d/sslh
# chkconfig --add sslh

Configuration

La configuration de SSLH se fait via les arguments qui lui son passé sur ligne de commande. J'ai donc décidé de les conserver dans le script d'init. (même si cela n'est habituellement pas conseillé)

On édite donc le script d'init.

# vi /etc/init.d/sslh

Cette ligne précisément:

...

OPTIONS="-p 0.0.0.0:443 -l 127.0.0.1:8443 -s 127.0.0.1:22 -P $PIDFILE"

...

-p 0.0.0.0:443 :SSLH sera en écoute sur le port 443.

-l 127.0.0.1:8443 :SSLH redirigera les requêtes HTTPS en local sur le port 8443.

-s 127.0.0.1:22 :SSLH redirigera les requêtes SSH en local sur le port 22.

Configuration de Apache

Il faut maintenant changer le port d'écoute de Apache pour qu'il utilise désormais le port 8443 pour les connexions HTTPS.

Nous disposons d'un serveur Apache compiler par nos soins. Il utilise le fichier "conf/extra/httpd-ssl.conf" pour définir le port de connexion HTTPS. Si vous ne disposez pas de se fichier il vous faut chercher où ce situe cette configuration. (probablement dans le httpd.conf)

 
# grep -lr "Listen 443" *

Un fois trouvé on édite ce fichier pour remplacer:

Listen 443

par:

Listen 8443

Enfin nous devons changer la configuration de nos vhosts comme par exemple:

<VirtualHost *:8443>
...
  SSLEngine on
  SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
  SSLCertificateFile "/etc/chose/..."
  SSLCertificateKeyFile "/etc/truc/..."

</VirtualHost *:8443>

Pour que nos modification soit prise en compte on redémarre le service httpd.

# service httpd restart

On démarre aussi tôt SSLH

# service sslh start

Créaction d'un fichier de log pour SSLH

SSLH envoi ses logs de connexion par le protocole syslog. Pour plus de lisibilité nous allons donc configurer notre démon syslog pour qui dirige les logs de sslh dans un fichier dédié.

Nous utilisons rsyslog et voici notre filtre:

# echo "# sslh log file" >> /etc/rsyslog.conf
# echo -e ":programname, isequal, \"sslh\"\t\t /var/log/sslh.log" >> /etc/rsyslog.conf

Puis on relance le démon rsyslog:

# service rsyslog restart

Si vous avez un grand nombre de connexion SSL/SSH il peux être intéressent d'effectuer une rotation sur ce fichier:

echo "/var/log/sslh {
    weekly
    notifempty
    missingok
}" > /etc/logrotate.d/sslh

Et si tous se passe bien, vous devriez trouver dans vos logs quelque chose comme suit.

# tail /var/log/sslh.log
Mar 17 00:38:22 csbjix sslh[21726]: connection from x.x.x.x:42395 forwarded to SSL
Mar 17 16:45:27 csbjix sslh[21726]: connection from y.y.y.y:16112 forwarded to SSH

Amusez vous bien !

NB: Cette article fait suite à la découverte de SSLH sur le site de notre ami bloggeur, Billux13. Si vous utilisez Debian et Lighttpd je vous invite a consulter son article.

Par RaX | le jeudi, mars 18 2010 07:00

Commentaires

1. nyquist

jeudi, mars 18 2010 | 15:41

Juste pour dire que la partie compilation peut être éviter en prenant sslh dans les dépôts (pour les distributions debian/ubuntu). Sinon la partie configuration est identique et je n'avais pas penser à la partie log que je vais essayer de suite.

Merci pour cette article, sslh est le meilleur outil pour faire cohabiter une connexion ssh et https sur le même port.

2. Bougie

jeudi, mars 18 2010 | 17:43

Je me pose un question :

Comment cela se passe si le HTTPS passe par un proxy genre squid ? ce qui peut etre le cas dans une entreprise/administration.

Cette solution est-elle quand même viable ?

Merci d'avance pour vos réponses.

3. GanGan

jeudi, mars 18 2010 | 17:52

Très bonne question...

Aucune idée on a pas réussi à installer Squid en reverse proxy :p faut dire qu'on a essayé un quart d'heure :p

Si tu as une doc à ce sujet ou carement si tu es motivé pour faire un article :) on pourra tester la chose.

4. Dju

jeudi, mars 18 2010 | 19:46

Haa, voila un article qu'il est bien pratique :)

Et voila pour établir un tunnel par ssh depuis votre machine ver chez vous :
ssh -p 443 -D 9999 vous@chezvous.com
Y'a plus qu'a configurer votre firefox ou autre pour utiliser un proxy socks sur 127.0.0.1:9999

Bougie> pour le proxy (en sortie, si j'ai bien compris ta question :p), si il est bien fichu et qu'il vérifie ce qui passe, il verra que les données ne sont pas du http et il te jettera :(

gangan > désolé, j'connais pas trop squid... il fait que du proxy, ou également du reverse-proxy (comme NginX) ? et dans ce cas, dans quel sens tu parles ? :D

5. RaX

jeudi, mars 18 2010 | 20:27

Oui je pense que GanGan a un peu confondu le sens de la question de notre ami Bougie.

Pour lui répondre je dirais qu'il ne sera pas simple pour ton proxy de différencier les deux protocoles. Quand les flux sont cryptés difficile de faire la différence entre HTTPS et SSH, maintenant je ne peux pas te répondre avec certitude car il faudrait étudier l'établissement de la session tcp et si regarder quelles sont les requêtes HTTP qui passe en clerc avant le tunnel SSL (Même si après le cryptage dans tous les cas les échanges de clef seront forcement passer par ton proxy et qu'il est donc logiquement capable de décrypter le tout).

Donc je dirais que ce n'est pas impossible mais que dans 90% des cas ça devrait passer.

@Dju:

Squid est un bon ReversProxy, au boulot pour les sites a fort trafique il ne m'est pas rare de le retrouver.

Rien a voir avec vos questions mais une petite mise en garde.

SSLH pose un problème. Apache n'est plus en mesure de déterminer d'où provienne les requêtes SSL vu que c'est SSLH qui lui transmet les requêtes et donc Apache n'ai pas en mesure de connaitre l'IP client.

6. nyquist

jeudi, mars 18 2010 | 21:41

En fait, cette solution est viable même a travers 2 proxy (mon cas).

Tous l'intérêt de sslh est de permettre au utilisateur de passer par le port 443 (qui est généralement le seul avec le 80 qui est ouvert sur un proxy) via un proxy d'entreprise.

Il est possible de filtrer les connections ssh et ssl mais cela n'est pas fait de base (je suis même pas sur que ce soit une option de squid).

Bref a part dans des entreprises très porté sur la sécurité et compétante (et encore !), le ssh sur 443 passe très bien.

@ Rax : bien vu le problème des logs d'apache!

7. Dju

jeudi, mars 18 2010 | 22:13

argh ! en effet, rax. je viens de tester sur une machine virtuelle, ça marche très bien mais dans les logs apache et authd, on a effectivement une connexion venant de... 127.0.0.1, (même en installant le mod rpaf pour voir :p)
C'est bien dommage :(
Sinon SSLH existe dans les dépôts d'ubuntu 9.10 mais pas 9.04. donc faut compiler et le makefile passe pas. Heureusement, l'auteur a fait un readme ou il indique la commande. et la, ça roule :)

8. nojhan

vendredi, mars 19 2010 | 09:51

Quelques petites précisions : le proxy envisagé plus haut, entre le client et le serveur ssh, peut tout à fait différencier des paquets SSH de paquets HTTPS, il suffit de regarder ce qu'il y a dedans, en gros. Ceci étant dit, j'ai l'impression que ce genre de surveillance est rarement mise en place, parce que ça doit bouffer pas mal de latence.

Par contre, le proxy ne peut pas savoir ce que les paquets contiennent. Les clefs échangés ne sont que les clefs publiques, il est donc impossible que le proxy puisse déchiffrer quoique ce soit (il faudrait les clefs privées). Dit autrement, les paquets sont bien _chiffrés_ (avec la clef publique) et non _signés_ (avec la clef privée).

En résumé, le proxy pourrait voir que vous avez un tunnel SSH, mais ne pourrait pas savoir ce que vous y faites passer (sauf à utiliser des techniques statistiques peu fiables).

Si la question est d'arriver à faire passer un tunnel SSH à travers un proxy HTTP, il y a une solution simple :
http://nojhan.free.fr/article.php3?...