Comment pouvez-vous dire ce que fait réellement un serveur? [fermé]

42

On m'a remis trois machines Linux, une face avant avec Apache dessus et deux autres qui, autant que je sache, ne font pas beaucoup. Tous courent sur Redhat.

La question est simple: comment savoir ce que le serveur fait réellement? Zéro documentation est disponible auprès du créateur.

— Bizmark
source

7

La liste des processus, les écouteurs du réseau (peut-être que la comparaison aurait dû être faite sur la base de scripts init) ...

— HBruijn

5

Zut! sûrement quelqu'un sait à quoi ils servent? alors ils veulent que vous les souteniez mais vous ne savez pas ce qu'ils font?!

— Digital Lightcraft

11

Éteignez-les. Quelqu'un vous fera savoir, presque immédiatement , ce qui ne fonctionne pas.

— Jscott

58

NE PAS ÉTEINDRE. Débranchez le câble Ethernet si vous voulez tester scream. Si vous n'avez jamais eu une boîte avec un temps de disponibilité de deux ans ne parvient pas à redémarrer, vous aurez à un moment donné. Ce n'est pas le moment d'ajouter cette frustration au mélange.

— Aaron Copley

7

Ce que tout le monde a dit, mais aussi: lancez nmap contre eux.

— Katherine Villyard

42

Débranchez le câble Ethernet et voyez qui se fâche.

Sérieusement, de telles machines mystérieuses génèrent une surcharge mentale considérable pour une équipe et ne fournissent souvent aucune valeur commerciale. Parlez à votre patron, si personne ne sait ce qu'il fait, peut-être que personne ne se soucie de ce qu'il fait.

— Josh Rumbut
source

43

NE PAS ÉTEINDRE. Débranchez le câble Ethernet si vous voulez tester scream. Si vous n'avez jamais eu une boîte avec un temps de disponibilité de deux ans ne parvient pas à redémarrer, vous aurez à un moment donné. Ce n'est pas le moment d'ajouter cette frustration au mélange. (Copiez ceci ici car il faut le lire.)

— Aaron Copley

3

Vous avez 100% raison, j'ai modifié le message pour en tenir compte. J'étais un peu facétieux, mais je peux toujours être facétieux sans provoquer de catastrophe.

— Josh Rumbut

8

Avant de débrancher le réseau, il est judicieux de sauvegarder une liste des processus en cours et des sockets ouverts sur chaque serveur - au cas où quelque chose reposerait sur une connexion TCP entre les serveurs, ce qui s'avère être resté pendant plusieurs mois sans que personne ne songe à y penser. automatiser toutes les étapes nécessaires pour l'ouvrir dans le premier cas. (Par exemple, si quelqu'un a besoin d'une redirection de port ssh temporairement et qu'il l'oublie.)

— kasperd

4

Ne fais pas ça. Quel conseil ridicule. De stupides informaticiens, cela me coûte tellement de temps et de travail. DEMANDEZ D'ABORD. Si vous ne savez pas à qui demander, DEMANDEZ À TOUT LE MONDE .

— Courses de légèreté avec Monica

4

Assurez-vous de laisser suffisamment de temps à quelqu'un pour crier - la première fois que j'ai agi de la sorte avec un ordinateur poussiéreux ou un ordinateur de bureau assis sur un rack de salle de serveur - personne ne savait ce qu'il faisait, il a fallu un mois complet à quelqu'un pour le remarquer lorsque nous l'avons débranché . Il s'avère que cela faisait partie du système de paie, sans ce serveur, la comptabilité ne pourrait pas générer de paie mensuelle. Il fonctionnait sans surveillance depuis au moins 3 ans, sans que personne ne s'y attarde. Le «test scream» a donc été un succès. Si nous ne l'avions pas fait, le serveur serait mort par lui-même. Nous avons fini par l'envoyer dans notre cluster vmware.

— Johnny

30

C'est une question assez large pour le format Serverfault, mais voici un bon début:

Recherchez les processus en cours et ceux devant être exécutés au démarrage du système.
- Vérifiez la configuration en cours de chacun.
- Regardez dans tous les répertoires de données définis. (Peut-être que quelqu'un a installé MySQL et l'a activé, mais il n'y a pas de base de données.)
Vérifiez les tâches planifiées.
Vérifiez les journaux pour voir;
- qui s'est connecté récemment (et leur demander)
- et pour avoir une idée de ce qui a fonctionné.

Vous n'avez pas mentionné la version, alors j'ai omis les détails.

— Aaron Copley
source

8

Il y a quelque chose de plus important que les services configurés pour démarrer au démarrage du système. Quels services fonctionnent actuellement? Démarrer un service et oublier de le configurer pour qu'il démarre au démarrage n'est pas une erreur difficile à commettre. Sur une note connexe, il est judicieux d'examiner d'autres états du système, tels que: points de montage, table de routage, règles iptables. Toutes ces choses pourraient facilement être changées pendant le fonctionnement du système sans oublier de mettre à jour les fichiers de configuration utilisés lors du démarrage.

— Kasperd

De plus, je voudrais utiliser un scanner de ports pour voir quels ports sont ouverts, puis essayer de vous y connecter en utilisant les outils habituels. Par exemple, si le port 443 est ouvert, vous pouvez utiliser un navigateur Web pour vous y connecter. J'ai eu à explorer fréquemment des serveurs apparemment abandonnés et l'un de mes outils favoris pour parcourir rapidement les fichiers de configuration de / etc et d'autres endroits est d'utiliser "lynx" ou "liens" si vous préférez. Ce sont des navigateurs Web basés sur des caractères qui fonctionnent assez bien comme navigateur de fichiers, avec une navigation par touche de curseur pratique.

— aseq

1

@kasperd Fair play entre services en cours et services persistants. Mais j’ai pensé aux règles de pare-feu, aux points de montage, etc. Celles-ci me semblaient être des composants auxiliaires qui seront déjà liés à l’un des points existants. YMMV.

— Aaron Copley

S'il vous plaît ajouter - Vérifiez les connexions réseau actives et notez les noms des services et les numéros de port. La meilleure méthode pour ce faire varie selon le système d'exploitation. EG net stat. En outre, mettez une sorte de trace sur l'ordinateur pour que vous puissiez voir ce qu'il fait tout au long de la journée. Vous pouvez également vouloir prendre en compte les scénarios dans lesquels des éléments s'exécutant sur les serveurs POURRAIENT être malveillants.

— IceMage

19

Vous pouvez procéder de différentes manières pour vérifier le fonctionnement de votre système.

Vous pouvez vérifier quels ports votre serveur écoute pour avoir une idée de ce qu'il contient. Une bonne commande à utiliser serait:

 [root@server ~]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             Stat    e       PID/Program name
tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LIST    EN      1880/smbd
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LIST    EN      1911/nrpe
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LIST    EN      1759/sshd

Comme vous pouvez le voir dans l'exemple ci-dessus, il vous présente la version du protocole (TCP ou UDP), l'adresse sur laquelle vous écoutez, le port ouvert et le programme en cours d'écoute.

Dans l'exemple tronqué ci-dessus (une machine serveur), vous pouvez voir que les ports TCP 139, 5666 et 22 sont à l'écoute. Celles-ci sont résolues en samba, nrpe (agent Nagios) et ssh, et sont confirmées lorsque vous vérifiez le programme en cours d'écoute sur ce port.

De plus, vous pouvez consulter la liste des démons configurés pour démarrer au démarrage. Pour ce faire, exécutez: chkconfig --list | grep "3:on"

Exemple:

[root@server ~]# chkconfig --list | grep "3:on"
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sysstat         0:off   1:on    2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off
vncserver       0:off   1:off   2:on    3:on    4:on    5:on    6:off
webmin          0:off   1:off   2:on    3:on    4:off   5:on    6:off
x2gocleansessions       0:off   1:off   2:on    3:on    4:on    5:on    6:off
.
.
.

ou :

service --status-all

— Itai Ganot
source

5

Je trouve netstat -pluntplus facile de se souvenir.

— Abligh

2

En outre, il tcpdumppeut être utile de déterminer qui utilise réellement chaque service.

— Abligh

18

Une autre méthode consiste à vérifier le /etcrépertoire et à regarder les dates de modification. Après une nouvelle installation, tous les fichiers de ce répertoire doivent avoir à peu près la même date / heure. Et puisqu’une installation installe généralement de nombreuses choses que les gens n’utilisent pas, seuls les fichiers dont la date de modification est ultérieure reflètent l’objet réel du serveur . Si c'est ext4, vous devriez aussi pouvoir extraire la date de naissance des annuaires, la tâche peut donc être assez facile.

Une autre méthode encore consisterait à vérifier les .bash_historyfichiers pour voir ce que les administrateurs faisaient. Ce fichier peut fournir une mine de connaissances.

— Konrad Gajewski
source

7

Vérifiez les règles du pare-feu. Avec un peu de chance, il est configuré pour default-deny. Cela signifie qu'il existe une règle explicite pour chaque service autorisé.

C’est mieux alors, netstatcar cela peut également indiquer les ports ouverts, par exemple, pour les sauvegardes nocturnes.

— MSalters
source

6

Une réponse que je n'ai pas encore vue: Consultez les derniers fichiers modifiés. Les journaux, les fichiers de base de données, d'autres fichiers de sortie, etc. peuvent être écrits, ce qui peut fournir des indices:

find . -mtime -3

Cela trouverait les fichiers modifiés dans le répertoire actuel et plus profondément, modifiés au cours des 3 derniers jours. Augmentez le nombre 3 à une supposition éclairée jusqu'à ce que vous obteniez une sortie sur laquelle vous pouvez enquêter.

Pas infaillible, car les boîtes peuvent simplement traiter certains appels de service Web et renvoyer des données sans rien écrire. Mais, ajouté au formidable mélange mentionné ci-dessus, il peut ne donner que quelques indices.

— JayMcTee
source