Conseils pour prendre en charge avec élégance un serveur de production (UNIX)

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 « sudofermer 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?

Comme d'autres l'ont dit, cela ressemble à une situation lâche.

(À partir de la fin)

• Déploiement complètement nouveau

Bien sûr, vous ne pouvez pas simplement arrêter les serveurs et laisser l'installateur faire sa magie.

Processus général

• Obtenez un budget pour un serveur de sauvegarde (sauvegarde comme dans le stockage des données)
• créer des instantanés des données et les placer là avant de faire quoi que ce soit
• Faites approuver cela par la direction!
• Rassemblez une liste d'exigences (le wiki est-il nécessaire, qui utilise les instances VMWare, ...)
  • De la direction et
  • Des utilisateurs
• Faites approuver cela par la direction!
• Arrêtez les services non répertoriés pendant une semaine (un service à la fois - iptables peut être votre ami si vous souhaitez simplement arrêter les services externes mais que vous pensez qu'il pourrait toujours être utilisé à partir d'une application sur le même hôte)
  • Pas de réaction? -> sauvegarde finale, supprimer du serveur
  • Réaction? -> Parlez aux utilisateurs du service
  • Rassemblez de nouvelles exigences et Geet qui a approuvé par la direction!
• tous les services non répertoriés en panne pendant un mois et aucune réaction? -> rm -rf $service(ça sonne dur mais ce que je veux dire c'est mettre le service hors service)
• obtenir un budget pour un serveur de rechange
• migrer un service à la fois sur le disque de rechange
• faites approuver cela par la direction!
• arrêtez le serveur migré (hors tension)
• en savoir plus de gens viennent vous crier dessus -> ouais, vous venez de trouver les restes
• recueillir de nouvelles exigences
• redémarrer et migrer les services
• répétez les 4 dernières étapes jusqu'à ce qu'il n'y ait plus de personnes qui viennent après vous pendant un mois
• redéployer le serveur (et le faire approuver par la direction!)
• rincer et répéter tout le processus.
  • le serveur redéployé est votre nouveau rechange

Qu'avez-vous gagné?

• Inventaire de tous les services (pour vous et la direction)
• Documentation (après tout, vous devez écrire quelque chose pour la gestion, pourquoi ne pas le faire correctement et faire quelque chose pour vous et la direction)

J'y ai fait ça, ce n'est pas amusant du tout :(

Pourquoi avez-vous besoin de le faire approuver par la direction ?

• Rendre les problèmes visibles
• Soyez sûr que vous ne serez pas viré
• Possibilité d'expliquer les risques
  • C'est bien s'ils ne veulent pas que vous le fassiez, mais après tout, c'est leur décision de prendre après avoir obtenu suffisamment de données pour juger si l'investissement en vaut la peine.

Oh, et présentez-leur le plan global avant de commencer , avec quelques estimations sur ce qui se passera dans le pire et le meilleur des cas.

Il va coûter beaucoup de temps quel que soit le redéploiement si vous ne possédez pas les documents. Il n'est pas nécessaire de penser aux portes dérobées, à mon humble avis, si vous n'avez pas de documentation, une migration continue est le seul moyen d'atteindre un état sain qui apportera de la valeur à l'entreprise.

Avez-vous des raisons de croire que l'administrateur précédent a laissé quelque chose de mal derrière, ou regardez-vous simplement beaucoup de films?

Je ne demande pas à être facétieux, j'essaie de me faire une idée du type de menace qui existe selon vous et de sa probabilité. Si vous pensez que les chances sont vraiment très élevées qu'une sorte de problème sérieusement perturbateur puisse réellement exister, je suggère de le traiter comme s'il s'agissait d'une intrusion réussie sur le réseau .

Dans tous les cas, vos patrons ne veulent pas l'interruption des temps d'arrêt pendant que vous gérez cela - quelle est leur attitude vis-à-vis des temps d'arrêt planifiés pour ranger les systèmes par rapport aux temps d'arrêt non planifiés s'il y a un défaut dans le système (qu'il s'agisse d'un véritable défaut ou d'un administrateur escroc) et si leur attitude est réaliste par rapport à votre évaluation de la probabilité que vous ayez vraiment un problème ici.

Quoi que vous fassiez d'autre, tenez compte des points suivants:

Prenez maintenant une image des systèmes . Avant de faire autre chose. En fait, prenez-en deux et mettez-en un de côté et ne le touchez plus jusqu'à ce que vous sachiez ce qui se passe, le cas échéant, avec votre système, c'est votre dossier sur l'état du système lorsque vous l'avez repris.

Restaurez le "2ème" jeu d'images sur certaines machines virtuelles et utilisez-les pour sonder ce qui se passe. Si vous vous inquiétez de ce qui se déclenche après une certaine date, définissez la date sur un an environ dans la machine virtuelle.

Tout d'abord, si vous allez investir du temps supplémentaire dans ce domaine, je vous conseille de réellement être payé pour cela. Il semble que vous ayez accepté les heures supplémentaires non rémunérées comme un fait, à en juger par vos mots - cela ne devrait pas être ainsi, à mon avis, et surtout pas lorsque vous êtes dans une telle pincée à cause de la faute de quelqu'un d'autre (que ce soit la gestion, l'ancien administrateur système ou probablement une combinaison des deux).

Arrêtez les serveurs et démarrez en mode mono-utilisateur (init = / bin / sh ou 1 à grub) pour vérifier les commandes qui s'exécutent à la connexion de root. Les temps d'arrêt sont nécessaires ici, indiquez clairement à la direction qu'il n'y a pas d'autre choix que des temps d'arrêt s'ils veulent être sûrs de pouvoir conserver leurs données.

Ensuite, regardez tous les cronjobs, même s'ils ont l'air légitimes. Effectuez également des sauvegardes complètes dès que possible, même si cela signifie un temps d'arrêt. Vous pouvez transformer vos sauvegardes complètes en machines virtuelles en cours d'exécution si vous le souhaitez.

Ensuite, si vous pouvez mettre la main sur de nouveaux serveurs ou des machines virtuelles capables, je migrerais les services un par un vers de nouveaux environnements propres. Vous pouvez le faire en plusieurs étapes afin de minimiser les temps d'arrêt perçus. Vous gagnerez une connaissance approfondie des services dont vous avez besoin tout en rétablissant votre confiance dans les systèmes de base.

En attendant, vous pouvez vérifier les rootkits en utilisant des outils comme chkrootkit . Exécutez nessus sur les serveurs pour rechercher les failles de sécurité que l'ancien administrateur peut utiliser.

Edit: Je suppose que je n'ai pas abordé la partie "gracieusement" de votre question du mieux que j'ai pu. La première étape (passer en mode mono-utilisateur pour vérifier les pièges de connexion) peut probablement être ignorée - l'ancien administrateur système vous donnant le mot de passe root et configurant la connexion pour faire un rm -rf /serait à peu près la même que la suppression de tous les fichiers lui-même, donc il y a probablement pas la peine de le faire. Selon la partie sauvegarde: essayez d'utiliser une rsyncsolution basée sur vous pour pouvoir effectuer la plupart de la sauvegarde initiale en ligne et minimiser les temps d'arrêt.

J'investirai du temps pour apprendre quelles applications fonctionnent sur ces serveurs. Une fois que vous savez ce qu'est quoi, vous pouvez à tout moment installer un nouveau serveur. Dans le cas où vous pensez que cela peut être une porte dérobée, ce sera une bonne idée de simplement démarrer en mode simple ou d'avoir un pare-feu entre les serveurs et le réseau externe.

Vous devenez paranoïaque à propos de la sécurité. Il n'est pas nécessaire de devenir paranoïaque. (b'cos vous parlez de pièges). Parcourez la liste des logiciels installés. Voir les services exécutés (netstat, ps, etc.), voir les tâches cron. Désactivez le compte utilisateur administrateur sys précédent sans supprimer le compte (cela se fait facilement en pointant le shell vers nologin). Voir à travers les fichiers journaux. Je pense qu'avec ces étapes et à partir de votre connaissance des besoins de l'entreprise à partir desquels vous pouvez deviner l'utilisation des serveurs, je pense que vous devriez être en mesure de les maintenir sans aucun problème majeur.