Hériter d'un serveur existant

9

Je viens d'hériter de 6 serveurs Web de l'ancien serveur qui a été licencié, je ne suis pas un administrateur système, je suis plus un DevOps.

Quelqu'un pourrait-il m'indiquer une sorte de liste de contrôle standard à suivre lors de l'héritage de serveurs existants? Les choses que je dois savoir sont:

  1. Quel logiciel est sur les serveurs
  2. Quelles sont les mesures standard à prendre pour vérifier leur sécurité?
  3. qu'est-ce qui les relie et qu'est-ce qu'ils sont aussi connectés?
  4. Que dois-je savoir d'autre?

Tout conseil est le bienvenu, j'espérais qu'il existait une sorte de liste de contrôle standard que l'on suivrait au début, mais je n'ai rien trouvé.

Tous les serveurs sont Ubuntu (différentes versions)

user3408844
la source
3
Vous n'êtes pas un DevOps. DevOps n'est pas un titre, c'est une culture.
gWaldo
Quel serait le meilleur terme à utiliser pour un "développeur contraint de devoir effectuer un travail d'administrateur système sans l'expertise d'un administrateur système, mais une bonne compréhension de tous les concepts impliqués et suffisamment d'expérience pratique pour s'en tirer"
user3408844
D'accord après avoir lu DevOps sur Wikipédia, je vois que je l'ai mal utilisé, mais il semble être devenu un argot dans la vie quotidienne des développeurs devant devenir semi-syadmin
user3408844
Le terme pour ce que vous décrivez est "Développeur" ou "Développeur contraint de prendre en charge certaines fonctions Systèmes / Opérations".
gWaldo
Hou la la! - beaucoup d'efforts mis dans celui-ci
user3408844

Réponses:

24
  1. Pour déterminer quel logiciel a été installé, vous pouvez consulter /var/log/dpkg.log Cependant, il ne s'agit peut-être pas d'un enregistrement complet. Il peut y avoir des binaires et du code qui ont été compilés manuellement ou copiés directement sur le système précompilé. Vous pouvez comparer une installation par défaut de la même version et du même type Ubuntu au (x) serveur (s) et rechercher les fichiers différents, mais cela peut être fastidieux. Une solution de surveillance de fichiers serait idéale (tripewire, inotifywatch, etc.) http://linuxcommando.blogspot.com/2008/08/how-to-show-apt-log-history.html

  2. Vous devez TOUT vérifier sur le serveur. Chaque compte d'utilisateur dans / etc / passwd , chaque compte d'utilisateur d'application (tels que les utilisateurs dans Apache / PHP, les comptes de base de données, etc.) doivent être pris en compte, et vous devez modifier tous les mots de passe. Vous devriez vérifier quels services sont lancés au démarrage, quel est le niveau d'exécution par défaut et ce qui commence avec lui et avec d'autres niveaux d'exécution. J'utiliserais un scanner de vulnérabilité et un outil de configuration de base pour auditer l'état actuel. Le Center for Internet Security propose un outil d'évaluation de configuration gratuit, mais il peut être limité. Ils ont des outils plus avancés pour les organisations membres ($). http://benchmarks.cisecurity.org/ OpenVAS est un scanner FOSS, un peu comme Nessus, qui peut avoir des capacités similaires. Il y a beaucoup, beaucoup plus de choses à vérifier, mais cette réponse devient déjà un peu longue ... (La révision de code pour les applications Web et les pages Web est un bon exemple.)

  3. Vous pouvez voir revoir l'état des ports disponibles pour les connexions aux serveurs avec une variété d'indicateurs pour netstat . http://www.thegeekstuff.com/2010/03/netstat-command-examples/ Pour identifier qui s'est connecté au serveur, vous devrez recourir aux activités de sécurité Internet les plus sexy, en examinant les journaux système. Les informations peuvent figurer dans l'un des nombreux journaux en fonction des applications et des serveurs présents sur le système. Vous pouvez également avoir de la chance avec les journaux de réseau externes, s'ils existent.

  4. Vous avez beaucoup de suivi à faire. Vous avez indiqué que l'administrateur précédent avait été licencié ; si vous soupçonnez une intention malveillante de cette personne (c'est-à-dire qu'elle a peut-être laissé des portes dérobées, des pièges à fous, des bombes logiques, etc.), il est presque certain qu'il vaut mieux reconstruire les serveurs à partir de supports propres et réimplémenter les applications Web sur eux. Si cet administrateur précédent avait un accès et un contrôle complets à ces systèmes et n'était pas soumis à un audit et à une surveillance diligents, vous devriez probablement supposer qu'il existe des portes dérobées.

Ceci est basé sur une hypothèse pessimiste sur l'administrateur précédent. Malheureusement, c'est ainsi que le cookie s'effrite pour la sécurité du réseau opérationnel. Il y a beaucoup plus à considérer, comme je l'ai dit ... bien plus que ce qui peut être couvert ici. Ces points devraient vous donner des éléments pour commencer, afin que vous puissiez signaler à la direction que vous faites des progrès; mais pour être honnête, si vous n'êtes pas un professionnel de la sécurité et que vous avez des raisons de soupçonner que cette personne a agi avec malveillance, vous êtes probablement au-dessus de votre tête.

C'est une réponse impopulaire auprès de la direction, car elle nécessite beaucoup d'efforts (ce qui signifie plus de dollars), mais la réponse générale axée sur la sécurité est en cas de doute, effacez et reconstruisez à partir de sources propres . C'est ainsi que les systèmes gouvernementaux les plus importants fonctionnent avec les logiciels malveillants; si une alerte vient d'AV, le système est séparé, effacé et reconstruit. J'espère que vous avez fait une sauvegarde car ces données ont disparu .

Bonne chance, et j'espère que cela a été utile et pas seulement déprimant.

0xSheepdog
la source
Cette question peut également convenir au site StackExchange www.AskUbuntu.com
0xSheepdog
2
Excellente réponse.
EEAA
3
L'effacement et la reconstruction sont probablement beaucoup plus faciles si vous avez une bonne gestion de la configuration déclarative. Si vous ne le faites pas, vous devriez probablement envisager de travailler vers cet objectif.
zigg
2
/var/log/dpkg.logest bien adapté pour revoir le processus d'installation lui-même (et rechercher les erreurs), mais pour obtenir une liste des packages installés, la sortie de dpkg -lou même plus simple dpkg --get-selectionsserait plus facile à digérer.
Dubu
0

Les pages de manuel sont votre ami:

 man <command> 

Découvrez ces commandes couramment utilisées et leur utilisation. Trouvez plus d'aide dans les pages de manuel de chacun ou dans certains cas en exécutant

  <command> --help 

Logiciel:

  • dpkg -l (liste des logiciels installés)
  • ps -ef | more (obtenir une liste des processus en cours et faire une pause pour la lecture)

Sécurité:

  • iptables (quels ports sont ouverts et sont-ils nécessaires)
  • vérifier les mises à jour avec apt-get (les serveurs sont-ils à jour?)
  • cat / etc / passwd (qui a un compte sur la boite)
  • sshd (vérifiez si sshd est en cours d'exécution et qui peut s'y connecter)

Connexions:

  • netstat (quels services écoutent et sur quels ports)

Bonne chance. Il est difficile d'hériter d'un lot de serveurs sans que la personne qui les exécute ait la possibilité de vous former. Si le gars a été licencié, c'est encore plus inquiétant car je suppose qu'il y avait une raison et si je suppose également que c'était lié au travail, il pourrait y avoir des configurations étranges dans le lot.

Chris Jones
la source
0
  1. quelles applications sont en cours d'exécution: faites un "ps -ef" ou "ps -auxw" pour obtenir la liste des processus. éliminer tout ce qui n'est pas lié au noyau, rechercher des éléments en cours d'exécution, faire des pages de manuel sur chacun pour comprendre ce que c'est. la plupart des processus en cours d'exécution que vous pouvez ignorer en toute sécurité car ils ne sont pas des applications utilisateur

  2. pour la sécurité: faites un "netstat -pan" pour voir quels ports sont ouverts et fermez ceux qui ne sont pas nécessaires. En d'autres termes, les seuls ports qui devraient être ouverts sont ceux qui correspondent aux services réseau fournis par ces serveurs. Si le serveur est un serveur Web, il doit évidemment être à l'écoute sur le port 80/443 / etc. Mais si le serveur écoute sur le port 21 et que personne ne l'utilise, vous devez désactiver le processus qui a ce port ouvert.

  3. pour les connexions, encore une fois "netstat -pan" vous donne la réponse. Il vous indique quels hôtes sont connectés et sur quels ports ils sont connectés.

  4. regardez dans les journaux dans / var / log pour avoir une idée de ce que fait le système et pour voir s'il y a des erreurs évidentes ou des drapeaux rouges provenant de différentes applications.

Michael Martinez
la source