Bonjour, au boulot je suis tombé sur un cas un peu "exotique"... Une machine qui fait des reboots en faisant des ls... En cherchant un peu on a fini par voir qu'il y avait un /usr/kerberos/bin/ls qui faisait en gros :
/bin/ls "$@"
reboot
est-ce que vous savez ce qui peut avoir créé un fichier pareil à part un idiot bête de plaisantin ?
Je précise que chkrootkit n'a rien trouvé...
Merci d'avance
Forum Linux.redhat Problème reboot intempestif lors d'un ls ??
9
août
2006
# Derniers épisodes
Posté par spiral . Évalué à 1.
je vois que notre histoire n'a pas l'air de beaucoup vous inspirer...
Je vous raconte les dernières évolutions, dans l'espoir que ça vous inspire davantage :
aléatoirement, :
le kicker s'agrandit de manière à occuper tout l'écran, les résolutions changent à la volée... sans m^ que X ne restarte... les bureaux virtuels tournent tous seuls, les konsoles se créent à l'infini, des xkill apparaissent tout seuls... c'est un vrai plaisir pour bosser quoi :-S
De plus, les "ls" arrivent à rebooter même sans créer le /usr/kerberos/bin/ls maintenant :-S
Ah, et en plus, ça a l'air de se répandre par le réseau...
Je précise, les postes sont sous RHEL 3.
Si vous avez des pistes, n'hésitez-pas à vous signaler...
Merci d'avance
[^] # Re: Derniers épisodes
Posté par yves tennevin (site web personnel) . Évalué à 1.
(2 - Faire des backups de ce qui doit etre sauvegardé (et uniquement ca).)
3 - Reinstaller le systeme, vu que la machine a manifestement été rootée ou altérée de maniere impossible à connaitre.
(chrootkit ca doit etre comme les antivirus, il ne peut pas tout detecter, il peut aussi avoir été corrompu.)
(4 - Reinstaller les données.)
esby
[^] # Re: Derniers épisodes
Posté par spiral . Évalué à 1.
En gros, y a plusieurs machines qui font pareil.. On avait déjà eu des merdes comme ça y a 2-3 semaines et on avait tout formaté... On veut bien "rejouer", mais bon, ça serait bien qu'on arrive à trouver d'où ça vient pour pas que ça "revienne", tout particulièrement chez les clients...
Au passage, à part des fichiers source, on n'avait rien conservé... et les machines ne sont pas reliées à internet ('fin le proxy n'a jamais été configuré sur ces machines).
Merci pour le coup de main en tout cas...
[^] # Re: Derniers épisodes
Posté par yves tennevin (site web personnel) . Évalué à 1.
* un soft qui creerait ca involontairement? (mais tres improbable.)
* un gars s'amusant en local (comprendre sur le site) ou un truc dans le genre.
(Qui sait des gars blasés voulant faire chier les autres, y a pas besoin de chercher loin ...)
* une de vos machines reliées à l'exterieur a été compromise, peut etre l'est toujours, et un gars s'est amusé/s'amuse à distance à saboter des postes de travail (au hasard?)...
Dans tous les cas, je vois pas trop ce que tu peux faire, à part journaliser les changements avec des envois de mail sur des sites externes (et donc non effacable facilement (je prends un exemple)).
Encore faut il supposer que le ver n'est pas dans la pomme depuis le début.
(Tout jeu de mots avec un fabricant d'ordinateur serait purement fortuit.)
esby
# Intéressant comme pb
Posté par Dabowl_92 . Évalué à 0.
Si chkrootkit n'a rien trouvé, c'est peut-être que le problème est ailleurs, dans l'ordre je ferais comme ça :
1/ Vérifier les empreintes MD5 des commandes potentiellement "piratées"
2/ Paramétrer iptables pour filtrer et/ou logguer les accès réseaux
3/ Vérifier les ports ouverts, et vérifier au passage si les commandes lsof, netstat etc ...ont bien la bonne empreinte MD5....
4/ Vérifier si la variable $PATH des utilisateurs n'est pas modifiée pour que le "ls" qui est trouvé en premier est bien /bin/ls, voir si ce n'est pas un lien etc...
5/ Activer les logs avec syslog pour voir ce qu'il se passe
6/ Faire des recherches avec find sur des fichiers dont les permissions sont douteuses (777 par exemple)
Voilà ce que je ferais dans un premier temps
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.