Ramasser les morceaux après avoir perdu l'administrateur Linux [fermé]


8

Donc, notre administrateur Linux a quitté notre projet et tout à coup, moi (le codeur web avec des connaissances de base linux / serveur), je suis responsable de notre serveur dédié (Ubuntu Server) qui gère principalement un site Web (apache / mysql / php) et du courrier (Postfix). Notre administrateur n'était pas vraiment un administrateur Linux professionnel, mais plutôt un gars avec des connaissances de base de Linux qui a compris des choses au fur et à mesure. J'attends donc des configurations funky, des services non sécurisés, etc.

Mes questions sont:

  1. Comment puis-je effectuer un "audit" du serveur pour déterminer son état actuel, pour s'assurer que les choses sont correctement configurées, qu'il n'y a pas de comptes d'utilisateurs inutiles, que nous n'exécutons pas de services inutiles, etc., etc.

  2. Je ne sais pas comment sauvegarder notre site Web de production. Outre les fichiers CMS réels et la base de données, il existe des configurations Apache, des bases de données de messagerie et plus encore qui doivent être sauvegardées. Une suggestion sur la façon d'automatiser cela?

  3. Quelles sont les tâches quotidiennes les plus importantes d'un administrateur Linux que je dois absolument accomplir? Énorme question, je sais.


Qu'entendez-vous par une configuration "funky"? Lorsque ma génération a utilisé le mot, cela signifiait que quelque chose allait bien.
John Gardeniers

Réponses:


11

Sensationnel. Où commencer.

C'est ce que je ferais, mais j'espère que d'autres y participeront avec des suggestions plus / meilleures.

Tout d'abord, ne paniquez pas. Je suppose que vous êtes maintenant root. Vous êtes actuellement la menace la plus dangereuse pour le serveur en ce moment, car vous avez beaucoup de pouvoir et pas beaucoup d'idée de ce que vous devez en faire.

Notez les services que le serveur doit exécuter. Vous savez qu'apache, mysql et postfix sont requis. Je suppose que vous pouvez avoir un serveur ftp là-bas et que vous êtes en mesure de ssh, vous avez donc besoin de sshd en cours d'exécution. Notez les services installés. Le moyen le plus rapide de le savoir est probablement de répertorier /etc/init.d/*. Vous devez ensuite savoir ce qui fonctionne. Je ne sais pas quel est l'équivalent du chkconfig de Red Hat, mais à défaut d'un ps -ef alternatif listera les processus en cours d'exécution. Découvrez également si un pare-feu est installé (comme iptables) et comment il est configuré.

Obtenez ensuite une liste de tous les cronjobs exécutés. Vous n'avez probablement pas à vous soucier trop de ce qu'ils font tout de suite, mais vous devriez avoir une idée générale de ce que fait le serveur à différents moments.

Encore une fois, j'écrirais tout cela.

Notez maintenant qui doit avoir accès au serveur et qui est autorisé à avoir un accès root. Obtenez une liste d'utilisateurs qui ont des comptes dans / etc / passwd.

Faites la même chose pour l'accès FTP et d'autres services si pertinents, comme Subversion ou les connexions MySQL distantes.

Maintenant que vous en savez un peu plus sur ce que fait votre serveur et qui peut y accéder, vous devez passer à la façon dont il fonctionne. Vérifiez les fichiers journaux dans / var / log, en particulier / var / log / messages et passez du temps à rechercher les erreurs.

Vérifiez s'il y a des mises à jour en attente à faire en utilisant apt-get update && apt-get upgrade

Lorsque vous êtes invité à mettre à jour, choisissez non pour l'instant.

Jusqu'à présent, vous n'auriez dû apporter aucun changement.

Vous devez maintenant examiner les informations que vous avez collectées et décider ce qui (le cas échéant) doit être corrigé. Les priorités sont les tentatives de piratage dans /var/log/auth.log, la fermeture des services inutiles et le renforcement du pare-feu.

Faites des copies de tous les fichiers avant de les modifier et testez souvent les modifications afin de pouvoir facilement revenir en arrière en cas de rupture.

Sauvegardes

Vous devrez décider ce qui doit être sauvegardé. Les candidats évidents sont les bases de données, / home / / etc / / var / log / / var / spool / cron / / var / www / et tout script personnalisé appelé par crontabs. Ensuite, la plupart des gens écrivent un script shell pour sauvegarder cela localement, puis utilisent quelque chose comme rsync pour copier les fichiers sur une autre clé USB de la machine.

Les tâches quotidiennes comprendront la vérification des fichiers journaux pour tout problème (consultez la montre de surveillance pour vous aider), la mise à jour de la sécurité, la vérification des sauvegardes et la configuration avancée de la surveillance comme MRTG et Nagios pour finalement éliminer le poids de la fonction d'administrateur .

Je ne m'inquiéterais pas trop cependant. Cela peut sembler intimidant, mais c'est parce que vous demandez tout cela en une seule fois. Le serveur est probablement bien comme il est, gardez un œil sur les journaux et appliquez les mises à jour au fur et à mesure qu'ils sont publiés, planifiez ce que vous voulez faire et travaillez dans ce sens, faites de petites étapes et essayez d'en profiter.


3
Avant de faire quoi que ce soit d'autre, j'imagine et / ou P2V ce meunier.
Orangutech

+1 pour obtenir un instantané actuel. Tarball le serveur sur SSH ou rsync au moins.
Gerald Combs

1
Lors de la saisie des services installés, exécutez également "dpkg -l> ~ / installed_software". Cela va écrire une liste des packages qui ont été installés via apt-get dans un fichier nommé "installed_software" dans votre répertoire personnel. Recherchez les services en cours d'exécution qui n'ont pas été installés via apt-get. L'ancien administrateur n'a peut-être pas installé les serveurs via apt-get, et ces services devront être mis à jour par des moyens autres que la "mise à niveau apt-get". On pourrait penser que ce serait rare, mais ce n'est pas le cas.
Dru

Une autre suggestion appropriée serait de placer les fichiers de configuration sous une certaine forme de contrôle de version. Ensuite, lorsque vous effectuez des ajustements ou changez des choses en fonction de votre façon de penser, vous pouvez suivre ces changements et voir exactement où vous avez foiré. Ou peut-être que vous avez de la chance, mais c'est toujours un bon conseil.
OldTroll

Tout cela est un excellent conseil. En plus de ce qui précède, j'exécuterais netstat -tanp et / ou -anp pour afficher des détails sur les connexions actives et d'écoute et leurs processus associés.
nedm

5

Quelques éléments pour vous aider à démarrer:

  1. obtenir quelqu'un qui a déjà effectué un tel audit - ou au moins avoir des connaissances sur les pièges courants liés à la maintenance d'un serveur. Sérieusement - cela rapporte.

  2. Sauvegardez aussi bien que possible et essayez de reconstruire un serveur de secours - peut être une instance virtuelle quelque part - jusqu'à ce que vous soyez sûr que a) vous avez sauvegardé toutes les choses importantes et b) vous êtes en mesure de reconstruire le serveur de secours à partir de votre sauvegarde en aussi peu de temps que vous le souhaitez. Pour ajouter du karma: échangez le serveur de production actuel avec votre serveur de rechange. Tant que vous n'avez pas démontré que vous pouvez reconstruire à partir de votre sauvegarde, faites comme si vous n'en aviez pas.

  3. Mettez à jour, lisez les avis de sécurité, gardez un œil sur les fichiers journaux et automatisez tout cela une fois que vous savez quoi rechercher.


3
+1 pour avoir trouvé quelqu'un qui sait ce qu'il fait. Ce sera moins cher à long terme.
David Mackintosh

1
+ 1 pour la même chose, mais j'irais encore plus loin et suggérerais de demander à quelqu'un qui est manifestement plus expert de s'assurer que l'ensemble du système est dans un état approprié. Un système en direct n'est pas un endroit pour apprendre à peu près à partir de zéro.
John Gardeniers

entièrement d'accord, mais comme le système est déjà en ligne, je suppose qu'il n'y a aucun moyen d'apprendre sur un système en direct.
Olaf

1

Pour obtenir plus facilement une poignée sur les fichiers journaux, vous pouvez envisager d'installer (ou d'activer..Je sais pas si ubuntu a cela dans l'installation par défaut) LOGWATCH. C'est très agréable de vous donner un résumé envoyé par e-mail tous les jours. Il ramasse généralement des trucs géniaux qu'un coup d'œil @ configs peut ne pas découvrir.


1

Si vous appréciez votre serveur et ses données, obtenez de l'aide. Demandez à quelqu'un de le vérifier.

Si vous ne savez pas à quoi ressemble "bien", il peut être difficile de repérer où quelque chose ne va pas (ou comme vous le dites "funky"). Une fois que quelqu'un le serveur est dans un bon état connu.

Utiliser quelque chose comme VMWare Converter pour créer une VM intermédiaire du serveur est une excellente idée, vous devriez y réfléchir.

Vous pouvez ensuite fouiller sur la machine virtuelle intermédiaire (copie du serveur) et essayer de faire tout ce que vous êtes invité à faire sur le serveur intermédiaire de machine virtuelle avant le serveur de production.


0

Après avoir fait ce que Richard Holloway a dit; puis effectuez une analyse du réseau du système pour vérifier quels services sont fournis par le serveur et vérifiez cela par rapport aux données dont vous disposez jusqu'à présent. Il est possible de faire des choses vraiment intéressantes avec Linux qui sont difficiles à trouver en regardant simplement les journaux.

Je suggère d'utiliser Zenmap d'un autre système sur le même réseau et d'obtenir d'abord les autorisations dont vous avez besoin de vos patrons. Zenmap est simple à installer, possède / possède une interface graphique et n'essaie pas d'exploiter tout ce qui est trouvé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.