Après des mois de négligence, de flammes de courrier électronique et de batailles de gestion, notre administrateur système actuel a été licencié et m'a remis "les informations d'identification du serveur". Ces informations d'identification consistent en un mot de passe root et rien d'autre: pas de procédures, pas de documentation, pas de conseils, rien.
Ma question est: en supposant qu'il ait laissé des boobytraps derrière, comment puis-je prendre le contrôle des serveurs avec le moins de temps d'arrêt possible?
Voici les détails:
- un serveur de production situé dans une batterie de serveurs au sous-sol; ubuntu server 9.x probablement, avec des correctifs grsec (rumeurs que j'ai entendues la dernière fois que j'ai demandé à l'administrateur)
- un serveur interne qui contient toute la documentation interne, le référentiel de fichiers, les wikis, etc. Encore une fois, le serveur ubuntu, vieux de quelques années.
Supposons que les deux serveurs soient corrigés et à jour, donc je préfère ne pas essayer de pirater mon chemin à moins qu'il y ait une bonne raison (c'est-à-dire que cela peut être expliqué à la haute direction).
Le serveur de production a hébergé quelques sites Web (apache-php-mysql standard), un serveur LDAP, une suite / serveur de messagerie ZIMBRA, et autant que je sache, quelques postes de travail vmware en cours d'exécution. Aucune idée de ce qui se passe là-dedans. L'un est probablement le maître LDAP, mais c'est une supposition folle.
Le serveur interne a un wiki / cms interne, un esclave LDAP qui réplique les informations d'identification du serveur de production, quelques stations de travail vmware supplémentaires et des sauvegardes en cours d'exécution.
Je pourrais simplement aller à l'administrateur de la batterie de serveurs, pointer vers le serveur, leur dire de « sudo
fermer ce serveur s'il vous plaît», de me connecter en mode mono-utilisateur et de me débrouiller. Idem pour le serveur interne. Pourtant, cela signifierait un temps d'arrêt, un bouleversement de la direction, le vieux sysadmin me ripostant en disant «voyez? vous ne pouvez pas faire mon travail »et d'autres nuisances, et surtout je devrais perdre potentiellement quelques semaines de temps non rémunéré.
À l'autre extrémité du spectre, je pouvais simplement me connecter en tant que root et inch via le serveur pour essayer de comprendre ce qui se passe. Avec tous les risques de déclencher des surprises.
Je cherche une solution au milieu: essayez de tout faire fonctionner tel quel, tout en comprenant ce qui se passe et comment, et surtout en évitant de déclencher des pièges laissés pour compte .
Quelles sont vos suggestions?
Jusqu'à présent, j'ai pensé à «pratiquer» avec le serveur interne, à déconnecter le réseau, à redémarrer avec un CD en direct, à vider le système de fichiers racine sur un lecteur USB et à le charger sur une machine virtuelle isolée et déconnectée pour comprendre l'ancienne manière sysadmin de penser (a-la 'connaître votre ennemi'). Pourrait tirer le même exploit avec le serveur de production, mais un vidage complet ferait remarquer quelqu'un. Peut-être que je peux simplement me connecter en tant que root, vérifier crontab, vérifier le .profile pour toutes les commandes lancées, vider le dernier journal et tout ce qui me vient à l'esprit.
Et c'est pourquoi je suis ici. Tout indice, aussi petit soit-il, serait grandement apprécié.
Le temps est également un problème: il pourrait y avoir des déclencheurs en quelques heures ou quelques semaines. Se sent comme un de ces mauvais films hollywoodiens, non?