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

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.

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.

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.

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.

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.

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é.