Ce billet est le premier d'une série de trois articles à propos d'outils que notre expérience nous pousse à considérer in-dis-pen-sable à tout administrateur *nix : S*, S* et S* (oui, nous gardons le suspens)

Généralement, les gens connaissent le premier. Un peu plus rarement le second. Le troisième, quant à lui, est généralement mal connu.

Loin de révolutionner les habitudes (quoique ... ), voici une rétrospective des services rendus par ces trois outils et leurs cas d'utilisation les plus courants.

Voyons un cas classique d'utilisation des deux premiers outils. Pour ce faire, glissons-nous derrière notre ami Bob.

Bob investigue sur un incident de production qui vient d'arriver sur un serveur dans le centre de production situé sur un autre site. Il va devoir comparer différents fichiers de configuration, suivre des journaux en temps réel, arrêter/redémarrer des démons, peut-être faire une compilation, remonter un miroir RAID, bref la routine de l'admin.

Avant, Bob utilisait telnet. S'étant fait tiré les oreilles par son fils qui lui a démontré par A + WireShark que le mot de passe passait en clair, lui et ses collègues utilisent maintenant ssh.

S01E01 : Ssh

Ssh permet de se connecter à une machine en chiffrant la communication. Il est possible de s'authentifier à cette machine en login/mot de passe, clé publique/privée, ou d'autres méthodes plus ou moins fortes. Il peut faire bien bien plus que vous connecter à une machine mais pour l'instant cantonnons-nous à cette fonction : ssh permet de se connecter avec login/mot de passe.

Ssh est composé d'une partie serveur et d'une partie cliente. La partie cliente le plus connue sous *nix (et MacOS) est OpenSSH, implémentation du protocole ssh par l'équipe d'OpenBSD. Le client le plus connu sur Windows est PuTTY.

Bob se connecte donc en ssh sur le serveur. Avant il se connectait avec le compte root, maintenant aussi. Du moins essai-t-il parce qu'aujourd'hui ça ne fonctionne pas.

Il peste quelques minutes puis se rappel un mail envoyé par un des ses collègues. Il le retrouve et ce mail dit en substance que par mesure de sécurité le login en tant que root est désactivé (sage décision, soit dit en passant, car un éventuel attaquant devra ainsi deviner, pour se connecter, un login en plus d'un mot de passe, et même ainsi l'attaquant n'aura qu'un compte utilisateur standard) et qu'il faut maintenant se connecter avec son compte standard, et de préférence nominatif.

Bob se connecte donc avec son compte standard sur le serveur de destination et ... s'aperçoit qu'il ne peut pas faire les tâches qu'il voulait (redémarrer des services, scruter les logs, ... ) parce qu'il n'est pas root.

Un tantinet énervé par cette perte de temps, il appelle son collègue, lui hurle dessus pour lui demander comment faire pour se connecter en root. Pour toute réponse son collègue lui dit "man sudo" et raccroche.

S01E02 : Sudo

Ne connaissant pas sudo, il tente benoîtement 'su', qui ne fonctionne plus. "§$@&!!! Le mot de passe root a été changé !" Il rappelle son collègue et atterrit directement sur son répondeur (il perçoit un rire sardonique mais peut-être n'est-ce que dans son imagination ... )

Encore plus énervé, il se résigne à taper 'man sudo'. Au fur et à mesure de sa lecture, les sourcils froncés de Bob s'écartent, se lèvent, et un sourire se dessine sur ses lèvres. A la fin de la man page il s'exclame "Ah ouais quand même !", et exécute ses tâches d'administration ... sans jamais devoir devenir root.

Exemple d'utilisation de sudo. Ici, la commande est autorisée et sudo est configuré, soit pour ne pas demander le mot de passe pour cette commande et/ou cet utilisateur, soit l'utilisateur a déjà fourni son propre mot de passe il y a moins de 5 minutes.

Comment ? Sudo permet d'exécuter une commande particulière sous un nom d'utilisateur particulier (sudo -u <utilisateur> <commande> ) (par défaut, cet utilisateur est root, et le mot de passe de l'utilisateur qui lance sudo est demandé avant l'exécution de la commande). Sudo inscrit dans les journaux système quelle commande a été exécutée par qui, et quand. Sudo pousse le raffinement jusqu'à permettre de préciser quelle commande avec quels arguments peut être utilisée par quelle personne en tant que quelle personne sur quelle machine. Il peut aussi ne pas être du tout raffiné et permettre à tout le monde d'exécuter n'importe quelle commande en tant que root et sans avoir à fournir de mot de passe.

Le collègue de Bob n'a fait que modifier le configuration de sudo pour que chacun puisse faire les tâches qui lui incombe, et uniquement celles-ci, et a enlevé le mot de passe de l'utilisateur root pour que personne ne puisse se connecter avec cet utilisateur, en console ou à distance (ce qui est le cas par défaut sur Ubuntu, par exemple). Il s'est également assuré que les ouvertures de session ssh directement sous root soient formellement proscrites en allant déclarer la ligne PermitRootLogin no dans le /etc/ssh/sshd_config et en redémarrant sshd. Le fichier de configuration par défaut de sudo (/etc/sudoers, a éditer impérativement avec visudo) propose en général des exemple de configuration très pratiques pour mettre le pied à l'étrier.

La journée passe, et une pelleteuse maladroite tranche le lien qui relie Bob au serveur distant (l'équipe réseau assure la main sur le cœur que pour cette fois ils n'y sont pour rien). C'est dommage : le problème sur le serveur était sérieux et Bob avait plusieurs connexions avec ce serveur : une dans laquelle tournait une longue compilation, une autre dans laquelle toutes les variables environnement étaient définis pour tester l'appli avec LA session qui la faisait crasher, une dans laquelle il y avait un badblocks qui tournait à la recherche de secteurs défectueux, et une dernière dans laquelle un RAID 1 se refaisait (une beauté dans) ses miroirs.

Conclusion

Ssh, dans son utilisation de base, permet de se connecter à une machine en chiffrant la communication, tandis que sudo permet d'exécuter une commande avec le compte d'un autre utilisateur. L'utilisation de ces deux commandes permet de sécuriser les échanges de données, et a fortiori les échanges de mot de passe, et permet une grande traçabilité des actions exécutées sur une machine.

Cette première étape permet à Bob d'administrer ces serveurs UNIX de façon plus sécurisée et avec une meilleure traçabilité, mais nous verrons dans la prochaine saison comment aider Bob, grâce au troisième S, à ne plus être gêné par les coups de pelleteuse et accessoirement par des problèmes de connexions réseau qui bagottent.

Le Quizzz

D'humeur taquine (qui a dit "vengeresse" ?) Bob, têtu, cherche à lancer un vrai shell en tant que root. Il sait que via sudo il est autorisé, en tant que root, à démarrer Apache (en exécutant la commande apachectl ou apache2ctl) et à éditer des fichiers de configuration (la commande vim est permise). Il a déjà essayé sudo su - ou sudo bash et son administrateur ne lui a pas permis ces commandes. Après quelques recherches, il parvient tout de même à passer root. Sauriez-vous comment a-t-il pu faire, en supposant qu'il n'existe pas de faille de sécurité permettant une escalade de privilèges ?