Transformation du protocole SSH en HTTPS sur un serveur CentOS7
Sommaire
I. Présentation
Il peut arriver de se retrouver dans un contexte où le protocole SSH n’est pas autorisé et où il faut alors contourner cet interdit, pour proposer un autre moyen de communication. C’est généralement le cas, lorsque l’on dispose de services ou de flux sortant, nécessitant d’entrer à nouveau dans le réseau d’entreprise.
En effet, la majorité des sociétés refusent d’autoriser, dans leur politique de sécurité, les flux entrant SSH. Il convient alors de trouver une astuce pour permettre aux utilisateurs d’entrer dans le réseau d’entreprise sans violer les règles de sécurité. Pour se faire, on peut alors mettre en œuvre l’utilitaire "shell in a box". Il s’agit d’une fonctionnalité permettant d’accéder au serveur concerné via le protocole web HTTP/HTTPS, tout en fournissant la possibilité d’un shell mais encapsulé en mode web.
Nous verrons aussi comment améliorer les fonctionnalités de cet utilitaire en y installant Limited Shell (abrégé en LShell), développé en Python permettant de limiter l’activité d’un shell utilisateur et ses interactions au travers d’un client web.
REMARQUE : le projet ShellInABox ainsi que LimitedShell sont tous deux des projets maintenus facilement utilisables. Ils peuvent être mis en œuvre sur n’importe quelle plateforme Linux, mais également sur des Raspberry Pi.
II. Prérequis
Pour pouvoir activer ShellInABox, il est donc nécessaire de disposer d’une plateforme GNU/Linux (dans notre cas, nous l’utiliserons sur un serveur CentOS 7). L’objectif étant de pouvoir accéder au shell d’un serveur au travers du protocole sécurisé HTTPS.
Il convient sur un serveur Linux CentOS7 d’installer en premier lieu le référentiel EPEL, car le package shellinabox se trouve dans ce dépôt. Il faut activer ce dépôt de la façon suivante :
# rpm –Uvh http://mirrors.kernel.org/fedora-epel/7Server/x86_64/Packages/e/epel-release-7-11.noarch.rpm
Une fois que c’est fait, on peut s’assurer que le dépôt EPEL est désormais en place et fonctionnel :
# yum repolist
On devrait alors visualiser une ligne comme celle décrite ci-dessous :
!epel/x86_64 Extra Packages for Enterprise Linux 7 - x8 16,024
III. Installation de "Shell In A Box"
L’installation se fait au travers des commandes standards de gestion de packages. Car, celui qui nous intéresse est déjà présent dans le référentiel EPEL que l’on vient d’installer précédemment. Il suffit donc juste d’exécuter la commande ci-dessous :
# yum install openssl shellinabox
ATTENTION : par défaut, shellinabox écoute sur le port TCP/4200 en local. Pour des raisons évidentes de sécurité, il est conseillé de changer ce comportement en positionnant un n° de port différent et rendant ainsi difficile l’accès à la boite SSH. Durant l’installation, un certificat SSL sera automatiquement créé dans /var/lib/shellinabox afin d’utiliser le protocole HTTPS.
IV. Configuration de "Shell In A Box"
Le service shellinboxd peut être configuré depuis le fichier /etc/sysconfig/shellinaboxd. On trouvera alors les directives suivantes (que l’on peut modifier à loisir) :
- Configuration du service shellinaboxd
# Shell in a box daemon configuration # For details see shellinaboxd man page # Basic options USER=shellinabox GROUP=shellinabox CERTDIR=/etc/pki/tls/certs/shellinabox PORT=6688 #OPTS="--disable-ssl-menu -s /:LOGIN" # Custom configuration : #OPTS="--no-beep --linkify=none --user-css Normal:+white-on-black.css,Reverse:-monochrome.css --disable-ssl-menu -s /:LOGIN" #OPTS="--no-beep --linkify=none --user-css Normal:+white-on-black.css,Reverse:-monochrome.css --disable-ssl-menu -s /:SSH -s /who:nobody:nogroup:/:w" OPTS="--linkify=none --user-css Normal:+white-on-black.css,Reverse:-monochrome.css --disable-ssl-menu -s /:SSH"
V. Activation
Maintenant que la configuration est effectuée, on peut alors activer le service de la façon suivante :
# systemctl start shellinaboxd # systemctl enable shellinboxd
Il est évidemment possible de s’assurer que la fonctionnalité est bien active (sur le port dédié, ici 6688), en exécutant l’instruction suivante:
# netstat –an|grep LISTEN|grep 6688 tcp 0 0 0.0.0.0:6688 0.0.0.0:* LISTEN
Dès lors, on peut alors ouvrir un navigateur et exécuter l’url https://<Server>:6688. On devrait- alors visualiser la fenêtre de terminal type SSH suivante :
Il est alors possible de cliquer sur le bouton ‘Avancé’ afin de passer outre cet avertissement et sélectionner ensuite le bouton d’ajout d’exception (et confirmer l’exception):
Ceci permet de faire afficher la mire de connexion type SSH (encapsulée dans un flux HTTPS) du serveur sélectionné :
<Server> login:
Il ne reste plus alors qu’à se connecter avec un compte accrédité du serveur en question pour disposer d’un accès shellinabox. On a alors la possibilité de cliquer droit afin d’accéder à un menu contextuel disposant de plusieurs options d’affichage :
Lorsque l’on se déconnecte de la session en cours, on devrait visualiser un écran avec un bouton ‘Connect’ permettant, le cas échéant de se reconnecter :
Dans son utilisation quotidienne, le service shellinaboxd possède également un manuel en ligne qu’il est possible d’interroger :
# man shellinabox
On peut aussi exécuter sur certaines plateformes, l’instruction suivante :
# shellinaboxd --help
Il existe même une page de type Wiki accessible depuis l’adresse web https://code.google.com/archive/p/shellinabox/wikis/shellinaboxd_man.wiki:
Globalement, cet utilitaire fonctionne sur les navigateurs suivants :
- Google Chrome
- Mozilla Firefox
- Galaxy Tab browser
- …etc.
Nous verrons ci-dessous comment sécuriser un peu plus le service ShellInABox au travers de quelques options de configuration supplémentaires.
VI. Sécurisation
Afin d’aller plus loin dans la démarche et sécuriser un peu plus l’utilisation faite de cet utilitaire, nous pouvons également citer cinq règles de sécurisation supplémentaires (nous avons déjà vu les deux premières lors de l'initialisation de l'outil) :
- Changement de n° de port TCP par défaut (déjà activé)
- Activation du protocole SSL (déjà activé)
- Restriction de shellinabox au serveur local seulement
- Configuration de shellinabox en proxy reverse pour Apache
- Activation de l’authentification Apache
Afin de restreindre l’utilisation du service shellinaboxd au seul serveur local, il suffit d’éditer le fichier /etc/sysconfig/shellinabox et d’intégrer à la ligne OPTS suivante, l’instruction en gras:
OPTS="…--no-beep --localhost-only"
Il ne reste plus alors qu’à arrêter et redémarrer le service shellinaboxd pour prendre en compte cette modification. Cela garantit que les accès distants au travers d’Internet et du réseau seront refusés. Mais, cela pouvant aller à l’encontre de ce que l’on souhaite faire, on peut alors étendre l’accès au travers d’un proxy reverse d’Apache. Pour se faire, il suffit d’activer les modules mod_proxy et mod_proxy_http du serveur web. On devra alors créer un fichier proxy.conf, dans lequel on placera les lignes d’instructions suivantes :
ProxyRequests Off <Proxy *> AddDefaultCharset off Order Allow,Deny Allow from all </Proxy> <Location /shell> ProxyPass http://localhost:6688/ Order allow,deny Allow from all </Location> Redirect permanent /shell https://mydmn.org/shell
Il suffit alors d’arrêter et redémarrer les services httpd et shellinaboxd pour permettre d‘utilser ce proxy reverse via le protocole HTTPS Il est ainsi possible d’accéder à ShellInABox via l’adresse https://localhost.shell (ou https://X.Y.Z.T/shell).
REMARQUE : la dernière ligne de configuration du reverse proxy permet d’accéder à l’url https://mydmn.org/shell. Mais, si l’on ne possède pas de nom de domaine reconnu (ou référençant une adresse IP déclarée), on peut ignorer cette instruction dans le fichier de configuration.
A cet égard, on peut également activer l’authentification Apache en créant un fichier .htpasswd :
# htpasswd –c /etc/httpd/conf/.htpasswd
Il faut ensuite éditer le fichier proxy.conf, précédemment créé et y ajouter les lignes suivantes (en gras):
<Location /shell> ProxyPass http://localhost:6688/ Order allow,deny Allow from all AuthUserFile /etc/httpd/conf/.htpasswd AuthName "Protected area" AuthType Basic Require valid-user </Location> Redirect permanent /shell https://mydmn.org/shell
Il faut alors arrêter et redémarrer les services httpd et shellinaboxd pour prendre en compte cette nouvelle modification. Dès lors, dès la prochaine connexion, il nous sera demandé un compte reconnu et accrédité pour accéder au service shellinboxd et à la session SSH encapsulée:
VI. Aller plus loin
Maintenant, on peut également renforcer la sécurité de l’utilisation de shellinabox en modifiant le shell sous-jacent et en imposant LimitedShell. Pour se faire, on va alors installer le package lshell et créer un compte d’accès spécifique appartenant au groupe du super utilisateur root :
# adduser myusr # useradd –G root myusr # chsh –s /usr/bin/lshell myusr
Il faut ensuite initialiser le mot de passé par défaut de ce nouvel utilisateur en exécutant l’instruction suivante:
# passwd myusr
Il faut ensuite modifier le comportement applicatif en prenant en compte application par application celles qui sont à utiliser au travers de l’encapsulation HTTPS. Pour se faire, on doit commencer par sauvegarder le fichier initial :
# cp /etc/lshell.conf /etc/lshell.conf.REF # vi /etc/lshell.conf
Les services intéressants à activer (ou non, selon les besoins), au sein de ce nouveau shell restreint, sont les suivants:
- scp_upload
- scp_download
- sftp
- scp
REMARQUE : chaque administrateur est libre ou non de les activer en fonction des conditions de sécurité qui lui sont imposées. Par ailleurs, il faut aussi penser à mettre en place des règles visudo telle que celles décrites ci-dessous (car l’utilisateur root est rejeté):
myusr ALL=(ALL) !ALL myusr ALL=NOPASSWD: /usr/bin/ifconfig, /usr/bin/ping
VII. Conclusion
On voit clairement dans ces exemples, que la connexion passe directement en HTTPS, en utilisant un certificat auto-signé. Si ce genre de sécurité pose problème, il est toujours possible d’utiliser un certificat certifié par une autorité reconnue. Le port d’écoute par défaut de shellinabox est 4200, il est fortement conseillé d’utiliser un autre n° de port et on a vu comment via l’édition du fichier /etc/sysconfig/shellinabox.
Ce genre d’utilitaire fonctionne aussi bien sur des plateformes Linux CentOS que Debian et on peut également configurer aussi bien Apache (ou Apache2), que Nginx ou tout autre serveur web reconnu en se servant d’une fonctionnalité de reverse proxy afin de permettre des requêtes plus classiques, interrogeant un port TCP/80, généralement ouvert au sein des pare-feu d’entreprise.
On remarquera également qu’il n’existe aucune limitation dans les commandes accessibles au travers de cette encapsulation HTTPS et on peut s’aider du manuel en ligne pour compléter ces fonctionnalités. Désormais, il n’est plus compliqué d’imaginer un contournement au blocage des flux SSH entrant vers les réseaux d’entreprise, grâce à l’utilitaire shellinabox.
Bonjour,
Merci pour l’article, je me permets d’ajouter une alternative très accessible :
SSLH : Share A Same Port For HTTPS : http://www.rutschle.net/tech/sslh/README.html
Il permet de faire écouter le service SSH et HTTPS sur le même port 443, avec très peu de configuration.
Merci pour votre commentaire.
Je ne connaissais pas cette technique. Cela fait un moyen supplémentaire (et c’est très précieux :-)).
Bonjour, trés bon article, j’ai appris quelque chose, je vous remercie
D.O
Bonsoir, Tant mieux. C’est un peu l’objectif de ces tutoriels de vous apporter des solutions.
Bonne soirée.