Question Conseils pour prendre en charge un serveur de production (UNIX)


Après des mois de négligence, de courrier électronique et de batailles de gestion, notre administrateur système actuel a été renvoyé 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 la suivante: en supposant qu'il ait laissé les boobytraps derrière, comment puis-je prendre les serveurs avec élégance 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; serveur Ubuntu 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 contenant toute la documentation interne, le référentiel de fichiers, les wikis, etc. Encore une fois, le serveur Ubuntu a quelques années.

Supposons que les deux serveurs sont corrigés et à jour, je préférerais donc ne pas me faufiler à moins qu'il n'y ait une bonne raison (c'est-à-dire que cela puisse être expliqué à la haute direction).

Le serveur de production a quelques sites Web hébergés (standard apache-php-mysql), 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à-bas. L'un d'entre eux est probablement le maître LDAP, mais c'est une supposition sauvage.

Le serveur interne possède un wiki / cms interne, un esclave LDAP qui réplique les informations d'identification du serveur de production, un peu plus de stations de travail vmware et des sauvegardes en cours d'exécution.

Je pourrais simplement aller voir l'administrateur de la batterie de serveurs, pointer le serveur, leur diresudo Arrêtez ce serveur s'il vous plaît ', connectez-vous en mode mono-utilisateur et profitez de mon chemin. Même chose pour le serveur interne. Néanmoins, cela signifierait des temps morts, des hauts responsables en colère, le vieil administrateur système me ripostant en disant: vous voyez? vous ne pouvez pas faire mon travail »et d'autres nuisances, et le plus important, je devrais perdre potentiellement quelques semaines de temps non rémunéré.

À l’autre bout du spectre, je ne pouvais que me connecter en tant que root et passer par le serveur pour essayer de comprendre ce qui se passait. Avec tous les risques de déclencher des surprises laissés pour compte.

Je cherche une solution intermédiaire: essayez de tout garder comme avant, tout en comprenant ce qui se passe et comment, et surtout. éviter de déclencher des pièges laissés pour compte.

Quelles sont vos suggestions?

Jusqu'ici, j'ai envisagé de "pratiquer" avec le serveur interne, de déconnecter le réseau, de redémarrer avec un CD live, de vider le système de fichiers racine sur un lecteur USB et de le charger sur une machine virtuelle isolée et déconnectée pour comprendre le mode de fonctionnement antérieur penser (a-la 'connais ton ennemi'). Pourrait faire 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 fichier .profile pour toutes les commandes lancées, vider le dernier journal et tout ce qui vous passe par la tête.

Et c'est pourquoi je suis là. Toute allusion, aussi petite soit-elle, serait grandement appréciée.

Le temps est également un problème: des déclencheurs peuvent se produire dans quelques heures ou quelques semaines. On se croirait dans l'un de ces mauvais films hollywoodiens, n'est-ce pas?


10
2018-06-18 21:01


origine


Pourquoi l'administrateur système at-il été congédié? Cela ressemble à une situation sans issue. Si vous ne savez pas quoi faire et ce qu'il y a exactement sur les serveurs, cela ne finira pas bien. - cstamas
@cstamas l'administrateur système a été congédié, car pour chaque demande que nous avons faite (ajout d'un utilisateur à la liste de diffusion ou création d'un alias de courrier électronique, etc.), le temps qu'il a fallu était une variable aléatoire entre t = 1 jour et t = 2 mois ( compris). Et il n'a jamais admis cela. Plus un tas d'autres mauvais comportements que je n'entrerai pas dans les détails ici. - lorenzog
@lorenzog maintenant cela a du sens. On dirait que ce ne sera pas une tâche facile. Il y a déjà d'excellentes réponses. Bonne chance! - cstamas
@serverhorror: non, ils l'ont simplement embauché avant que je rejoigne cette entreprise, et maintenant il s'est avéré ne pas être assez bon. Comme je le connaissais d’avant, j’avais pour tâche de «traiter avec lui». Faites attention à vos hypothèses. - lorenzog
@lorenzog: Ce n'est pas à propos de vous. Le fait est que c’est en fait la faute des gestionnaires (peu importe la cause) que la situation d’une infrastructure non documentée puisse même se produire - comme je l’ai dit: aucune infraction n’est juste une observation (sous réserve d’une observation subjective) - serverhorror


Réponses:


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

(À partir de la fin)

  • Déploiement entièrement nouveau

Bien sûr, vous ne pouvez pas simplement supprimer les serveurs et laisser l’installateur faire sa magie.

Processus général

  • Obtenir un budget pour un serveur de sauvegarde (sauvegarde en tant que stockage pour les données)
  • créer des instantanés des données et les placer là avant de faire n'importe quoi
  • Faites-le signer par la direction!
  • Recueillir une liste d'exigences (le wiki est-il nécessaire, qui utilise les instances VMWare, ...)
    • De la direction et
    • Des utilisateurs
  • Faites-le signer par la direction!
  • Arrêtez les services non répertoriés pendant une semaine (un un service à la fois - iptables peut être votre ami si vous voulez simplement fermer des services externes mais avez le soupçon que cela pourrait toujours être utilisé depuis une application sur le même hôte)
    • Pas de réaction? -> sauvegarde finale, retirer du serveur
    • Réaction? -> Parlez aux utilisateurs du service
    • Rassembler de nouvelles exigences et Geet qui a signé par la direction!
  • tous les services non répertoriés en panne depuis un mois et aucune réaction? -> rm -rf $service (ça sonne harsch mais ce que je veux dire, c'est déclasser le service)
  • obtenir un budget pour un serveur de rechange
  • migrer un service à la fois vers le serveur de secours
  • faites-le signer par la direction!
  • arrêter le serveur migré (mise hors tension)
  • en savoir plus, les gens viennent vous crier dessus -> oui, vous venez de trouver les restes
  • rassembler de nouvelles exigences
  • redémarrez et migrez les services
  • Répétez les 4 dernières étapes jusqu'à ce que plus personne ne vienne après votre retour pendant un mois.
  • redéployez le serveur (et faites-le signer par la direction!)
  • rincez et répétez tout le processus.
    • le serveur redéployé est votre nouveau serveur de secours

Qu'as-tu gagné?

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

Cela fait, ce n'est pas amusant du tout :(

Pourquoi avez-vous besoin de l'obtenir approuvé par la direction?

  • Rendre les problèmes visibles
  • Assurez-vous de ne pas vous faire virer
  • 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 à prendre après avoir reçu suffisamment d'informations pour pouvoir déterminer si l'investissement en vaut la peine.

Oh, et leur présenter le plan d'ensemble avant de commencer, avec quelques estimations de ce qui se passera dans le pire et le meilleur des cas.

Il volonté coûte beaucoup de temps, peu importe le redéploiement, si vous n’avez pas de documentation. Inutile 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.


12
2018-06-18 22:08



C'est une très bonne perspective. Je vous remercie. Je suivrai certainement vos conseils concernant la gestion de la solution et le redéploiement lent des serveurs. Cela va faire mal, mais cela semble être la meilleure ligne de conduite raisonnable. - lorenzog
Par la documentation appropriée, je suggère ceci: serverfault.com/questions/25404/… (voir aussi le sujet général) fonctionne très bien (du moins pour moi) - serverhorror


Avez-vous des raisons de croire que l'administrateur précédent a laissé quelque chose de grave ou regardez-vous beaucoup de films?

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

Quoi qu’il en soit, vos chefs ne veulent pas que les temps d’indisponibilité soient perturbés - quelle est leur attitude vis-à-vis du temps d’arrêt planifié pour mettre de l'ordre dans les systèmes par rapport aux temps d'immobilisation imprévus en cas de panne du système administrateur malhonnête) 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, considérez ce qui suit:

Prendre une image des systèmes rmaintenant. 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. Ceci est votre compte rendu de l'état du système au moment de la prise en charge.

Restaurez le "deuxième" jeu d'images sur certaines machines virtuelles et utilisez-les pour analyser ce qui se passe. Si des choses se déclenchent après une certaine date vous inquiètent, définissez la date suivante d'environ un an dans la machine virtuelle.


4
2018-06-18 22:05



J'ai des raisons de penser que quelque chose se cache, puisque nous ne nous sommes pas séparés au mieux. L'administrateur système précédent était un bon ami. Nous étions colocataires au collège et je lui "ai appris" nombre des astuces qu'il a utilisées plus tard pour devenir un administrateur système, alors que je prenais la voie du développement logiciel et de la gestion de projet. Parce qu'il y a des sentiments personnels en jeu (il m'a accusé d'avoir réussi à le faire virer), je ne peux pas m'attendre à un comportement raisonnable. Prenez cela comme une relation père / fils, où le fils veut prouver sa bonté au père, dans une certaine mesure. - lorenzog


Tout d’abord, si vous envisagez d’investir plus de temps dans ce domaine, je vous conseillerais de être payé pour ça. Il semble que vous ayez accepté les heures supplémentaires non payées comme un fait, à en juger par vos paroles - cela ne devrait pas être ainsi, à mon avis, et surtout pas lorsque vous êtes dans une situation aussi difficile à 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).

Mettez les serveurs hors service et démarrez en mode mono-utilisateur (init = / bin / sh ou 1 sur grub) pour vérifier les commandes exécutées lors de la connexion au compte root. Les temps d'arrêt sont nécessaires ici, expliquez clairement à la direction qu'il n'y a pas d'autre choix que des temps d'arrêt s'ils veulent être certains de pouvoir conserver leurs données.

Ensuite, regardez toutes les tâches cron, même si elles ont l'air légitimes. Effectuez également des sauvegardes complètes dès que possible, même si cela entraîne des temps d'arrêt. Vous pouvez transformer vos sauvegardes complètes en ordinateurs virtuels en cours d'exécution si vous le souhaitez.

Ensuite, si vous pouviez mettre la main sur de nouveaux serveurs ou des machines virtuelles compatibles, je migrerais les services vers de nouveaux environnements propres, un par un. Vous pouvez le faire en plusieurs étapes afin de minimiser les temps morts perçus. Vous obtiendrez une connaissance approfondie des services tout en retrouvant votre confiance dans les systèmes de base.

En attendant, vous pouvez rechercher des rootkits en utilisant des outils comme chkrootkit. Courir 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 aussi bien que possible. La première étape (passer en mode mono-utilisateur pour vérifier les interruptions de connexion) peut probablement être ignorée - l'ancien administrateur système vous donnant le mot de passe root et en configurant la connexion rm -rf / Ce serait presque pareil que de supprimer tous les fichiers lui-même, il est donc inutile de le faire. Selon la partie sauvegarde: essayez d’utiliser un rsyncafin que vous puissiez effectuer la majeure partie de la sauvegarde initiale en ligne et minimiser les temps d'arrêt.


4
2018-06-18 21:32





J'investirai du temps dans l'apprentissage des applications exécutées sur ces serveurs. Une fois que vous savez quel est ce que vous pouvez installer un nouveau serveur à tout moment. Si vous pensez que cela peut être une porte dérobée, ce sera une bonne idée de Il suffit de démarrer en mode simple ou d’avoir un pare-feu entre les serveurs et Le réseau externe.


0
2018-06-18 21:51





Vous devenez paranoïaque à propos de la sécurité. Il n'est pas nécessaire de devenir paranoïaque. (b'cos tu parles de pièges). Parcourez la liste des logiciels installés. Voir quels sont les services en cours d'exécution (netstat, ps, etc.), voir les tâches cron. Désactivez le compte utilisateur précédent de l'administrateur système sans le supprimer (facilement en pointant le shell vers nologin). Voir à travers les fichiers journaux. Je pense qu'avec ces étapes et de votre connaissance des besoins de la société à partir desquels vous pouvez deviner l'utilisation des serveurs, je pense que vous devriez être capable de les maintenir sans aucune gaffe majeure.


0
2018-06-18 21:56



Je conviens que ce n'est pas une question de sécurité en premier lieu (sinon, ils n'auraient pas dû embaucher l'ancien administrateur). Mais il s’agit de la valeur ajoutée que l’on peut ajouter. Je suis complètement en désaccord sur tout le reste. Il n'y a tout simplement pas de moyen sain d'esprit sans une sorte d'inventaire pour gérer les choses. L'utilisateur viendra vous frapper après un certain temps parce que quelque chose que vous n'avez jamais entendu auparavant a cessé de fonctionner. Après tout, il existe une certaine infrastructure derrière chaque service visible par l'utilisateur. Et il n'y a même pas de documentation sur ces services ... - serverhorror