Récit d’une « petite » erreur

Cette journée fut particulièrement mouvementée. Bien évidemment, ce n’était pas prévu et tout s’annonçait paisible tel un Vendredi classique. J’avais prévu deux transferts planifiés de sites dont le transfert avait été minutieusement préparé et répété. Une migration parfaitement classique.

Je me rends compte qu’il est nécessaire de modifier le fichiers de VirtualHost de tous les sites web du serveur Apache. Les Virtualhost sont les fichiers de configuration de site d’Apache. Au lieu de mettre « <Virtualhost IP> », il est nécessaire de mettre « <Virtualhost IP:port> ». Il n’était pas question de tout modifier à la main, il y a plus de 200 fichiers. Par sécurité, j’ai effectué une sauvegarde du répertoire sites-enabled. Dans ce cas, un script était nécessaire. Je code cela rapidement :

for i in `ls -1 .`; do cat $i | sed ‘s/<Virtualhost IP>/<Virtualhost IP:port>/g’ > $i; done

Et là, c’est le drame.

Ce petit script est, hélas, syntaxiquement correct. Il remplace bien les deux chaines de caractère comme je souhaitais qu’il le fasse. Il a été exécuté en root car je travaille toujours en root par simplicité. Si vous regardez de plus près, vous remarquerez qu’il écrit dans le même fichier qu’il lit. Erreur fatale. Ceci signifie la suppression de tous les fichiers du répertoire courant. Tous. Tous les Virtualhost disparus. Quant à la sauvegarde du répertoire sites-enabled ? Inutile car ce sont des liens symboliques.

Houston, we have a problem.

Quelques minutes suffisent pour se rendre compte de l’erreur commise par ce script en apparence anodin. Les sauvegardes, me diriez-vous. J’apprends qu’elles sont en erreur depuis longtemps. Par chance, une copie de la machine virtuelle était présente sur l’ancien serveur VMWare duquelle elle avait été migré avant-hier. La récupération d’une bonne partie des Virtualhost a été possible jusqu’à ce point. Sauf que nous avions transféré 120 sites hier. Cette erreur n’a pas créé d’indisponibilité car Apache mémorise la configuration. Un restart serait par contre fatal.

Il ne reste plus qu’une solution : créer un script à partir de la configuration de l’ancien serveur pour recréer tous les Virtualhost créés hier. Deux heures de développement d’un script pas si simple dans un des langages les plus moches sur Terre : Bash. Une heure de debug du script. Après trois heures de stress intense et d’activité cérébrale, les Virtualhost avaient été recréés. Quelques Virtualhost ont du être récréés à la main car le script n’avait pas fonctionné avec.

Finalement, Apache accepte les Virtualhost créés par mon script. Je suis sauvé.

Je pense qu’il est important de tirer les enseignements de ses erreurs. Dans ce cas, il va falloir que j’apprenne à utiliser sed et à ne plus jamais scripter sur un serveur de production. Nous faisons tous des erreurs et nous devons donc nous assurer que ces erreurs seront inoffensives. Dans ce cas, la protection face à l’erreur a été inutile à cause d’un élément technique dont j’avais parfaitement conscience. Un petit moment d’inattention a suffit pour tout faire basculer.

Au final, il y a deux types d’administrateurs système : ceux qui ont déjà tout cassé à cause d’une erreur de script et ceux qui vont le faire.

Sécuriser SSH, c’est pas bien compliqué

doc_openssh_logo_2Vous le savez peut être déjà, une faille semble avoir été trouvé dans SSH. Pour ceux qui n’ont jamais fait d’administration système, le protocole SSH est le protocole utilisé pour administrer les serveurs Linux/BSD ainsi que de très nombreux équipements réseau. Qui dit faille SSH dit accès total aux machines disposant de ce service. Pour vous rassurer, la faille semble ne toucher que les versions les plus vieilles d’OpenSSH. Vous qui disposez d’une Debian, vous êtes à l’aise car vous savez que Debian a un cycle de release assez rapide. Vous qui croyiez être à l’aise sur votre RHEL (Red Hat Entreprise Linux) ou CentOS et la stabilité qu’un cycle de release lent, vous devez être plus stressé et vous avez bien raison ! Cependant, elle semble peu crédible et basée sur de très nombreuses hallucinations suppositions.

Constat

Tout le monde le sait, le SSH est probablement le protocole le plus sensible sur une machine ou un équipement voire sur Internet. Il semble cependant régner un climat de confiance excessive autour de ce protocole. Dans le même temps, d’autres protocoles sont ultra surveillés comme c’est le cas pour HTTP ou DNS alors qu’ils sont moins sensibles. Je pense que dire que SSH est le protocole le plus sensible n’est pas une exagération trop importante. Certes le protocole DNS est ultra critique, mais une faille sur le protocole SSH permettra la modification des zones DNS présentes sur la machine. Une faille SSH permettra de prendre la main sur les routeurs et de modifier les informations BGP et ainsi de suite.

Bloquer les accès

La plus simple des parades à toutes les failles éventuelles sur SSH est de bloquer l’accès à ce dernier. Bien sur, si vous bloquez l’accès complètement, vous ne pourrez plus administrer vos machines mais il y a tout de même des solutions. Il est indispensable de ne pas autoriser la terre entière à accéder à votre serveur SSH. On ne peut pas considérer le service SSH sécurisé si il est accessible par la terre entière. Vous pouvez mettre une règle de filtrage permettant de n’autoriser que l’IP de votre connexion Internet. Si vous avez une connexion avec IP dynamique, vous pouvez utiliser OpenVPN pour accéder à votre zone de serveurs et n’autorisez la connexion qu’à partir du serveur VPN. Si vous êtes une société avec un minimum de moyens, mettez en place un tunnel MPLS jusqu’à votre datacentre.

L’accès en root, c’est mal…

Il est également peu raisonnable d’autoriser les accès SSH directement en root. Si vous donnez le mot de passe root à tous les utilisateurs de la machine, il sera plus difficile de leur en interdire l’accès par la suite. Ceci est d’autant plus grave si votre serveur SSH est accessible par tout le monde. De plus, un accès avec un compte utilisateur permet d’éviter que tout le monde puisse faire rm -Rf / par erreur. Une exception existe à cette règle, si votre filtrage au niveau du réseau est suffisament efficace et que vous avez la possibilité de supprimer l’accès en supprimant l’accès au VPN, il est possible d’accéder directement en root aux serveurs.