Charge CPU 100%

Bonjour,

Je suis sur un serveur linux debian. Depuis quelques jours, j'ai le message d'erreur suivant : CPU 100% utilisés / Processus 156.09 / Processus en veille 153.66.
J'ai réalisé un TOP et obtenu le résultat suivant :
- PID 14287 / USER root / PR 20 / NI 0 / VIRT 33224 / RES 4124 / SHR 1256 / S R / %CPU 99,6 / %MEN 0,1 / TIME+ 21454:11 / COMMAND packet

Pouvez vous me dire ce que cela signifie et comment je peux remédier à ce problème sans pertuber le serveur ?

6 réponses

  • Votes
  • Date
  • Date décroissante
Résumé de la discussion

Un serveur Debian affiche une utilisation CPU à 100% due au processus PID 14287 identifié comme 'packet' selon top, avec une consommation élevée et une activité continue. Plusieurs recommandent des vérifications comme ps -p 14287 -f et pstree -u -a -p pour confirmer le processus et examiner les connexions afin d’évaluer s’il s’agit d’une surcharge légitime ou d’activité suspecte. En cas de persistance, les conseils couvrent la mise à jour du système, l’arrêt ou le redémarrage des services, puis un audit des logs et du trafic pour identifier des activités anormales. D'autres éléments évoquent la vérification des commandes associées et la possibilité d'un spoofing du nom 'packet', ou d'une interprétation erronée du résultat.

Bobot (l’IA à votre service)
  1. Modérateur
    Salut,

    Peut-être un Bitcoin...
    Faudrait une capture d'écran et un pstree -u -a

    Veuillez appuyer sur une touche pour continuer la désinfection...
    1. Merci de votre attention.

      UnGnU : voici ce que me retourne la commande
      ps -p 14287 -f

      UID root / PID 14287 / PPID 1 / C 96 / STIME May02 / TTY ? / TIME 16-04:18:36 / CMD packet


      Malekal_morte- : voici les captures d'écran de ce que me retourne la commande
      pstree -u -a






      1. Contributeur
        Salut,

        J'ai beau chercher sur le net, je ne trouve rien concernant le processus "packet" ;-\

        Aucune trace non plus sur une
        debian jessie
        d'un quelconque paquetage nommé "packet".

        J'ai bien un
        man packet
        mais ça concerne les sockets :
         packet - Interface par paquet au niveau du périphérique


        Reste plus qu'à tuer le processus en priant que ça ne casse rien ;-))

        Attends quand même d'autres avis...
      2. @UnGnUMerci UnGnu.
        J'avais également fait une recherche sans succès sur le net et c'est ce qui m'a fait poster.
        Quand vous dites tuer le processus, cela consiste à faire quoi exactement ?
      3. @MyMMSalut,
        tuer le processus, cela consiste en quoi exactement ?
        https://www.google.fr/search?q=tuer+le+processus&ie=utf-8&oe=utf-8&gws_rd=cr&ei=3AU-V4SoG9Oja6fXoLAO

        Une petite recherche et hop, on a la réponse à ses questions kons.
    2. Pouvez vous me dire ce que cela signifie et comment je peux remédier à ce problème sans pertuber le serveur ?


      Même un reboot dans les heures de faible affluence n'est pas possible ?(4h par exemple)

      J'aurai dit :

      1 - Mettre à jour le système, ça vient peut-être d'un bug dans un des programmes qui a été corrigé depuis. Ça peut également servir à combler une potentielle faille qui aurait été utilisée pour lancer le processus génant

      2 - Tuer les processus génants et redémarrer les services (ou reboot, plus radical)

      Si le problème persiste repérer ce que fait le programme :

      -analyse du réseau (wireshark/tcpdump), durcir les règles du pare-feu si possible.
      -analyse du processus (recherche via la command lsof les fichiers ouverts par ce processus)
      -faire un audit de sécu services, fouiner dans les logs pour chercher des activités suspectes
      1. Modérateur
        Clair vu le nom, faire un état des lieux de ce qui se passe.
        Comme dit plus haut, ça doit être un service réseau.
        Ce serait bien aussi avec pstree de voir s'il y a un processus parent, ça peut donner des indications.
      2. Contributeur
        @Malekal_morte-
        Ce serait bien aussi avec pstree de voir s'il y a un processus parent
        Ben il semblerait que non ;-((

      3. Modérateur
        @zipe31Ha..
        Perso j'ai pas ce processus.

        et cat /proc/PID/cmdline
        ou ls -lh /proc/PID/exe
        ça donne pas des infos ?
      4. Hello,
        tu peux aussi faire
        sudo lsof | grep packet
        pour savoir à quelles ressources ça accède.
        Et tenter de localiser l’exécutable avec
        whereis packet
      5. @Flachy JoeBonjour,

        Voici ce que me retourne le whereis packet :
        packet: /usr/share/man/man7/packet.7.gz
    3. Voici ce que me retourne la commande :
      ls -lh /proc/14287/exe


      1. Je n'utilise pas du tout PERL. Est-ce que cela signifie que le problème a démarré le 2 mai à 1h39 ? Je vais essayer de me rappeler ce que j'ai fait à ce moment là.
        Pour une fois, le fait que j'écris tout va me servir !!
      2. Contributeur
        @MyMMQue tu n'utilises pas Perl personnellement c'est un fait, par contre tout un tas de programmes peuvent faire appel à Perl dans leur routines.

        D'ailleurs on voit dans ton arborescence une instance de Plesk (monitoring) et un gam_server. Rien ne nous dit que ces programmes n'utilisent pas Perl pour leur fonctionnement.
      3. Modérateur
        hum.... :)

        Comme j'ai dit dans mon premier message, ça fait vraiment Bitcoin...
        et comme c'est Perl, ça peut être une backdoor Perl qui a été mis dans /tmp
        et comme t'as rebooté, y a pu...

        Dommage que tu es rebooté.

        Mais bon, si c'est un hack, ça reviendra =)
      4. Ah mercredi !
        J'avoues que je voulais pas redémarrer une semaine avec cela ;)
        En effet, le problème à totalement disparu.
        Je note les consignes et vais étudier RKhunter.

        Merci à tous de votre aide et bonne continuation.
    4. ok zipe31.

      Bon au final j'ai rebooté le serveur. J'ai refait un top et à priori tout va bien maintenant :



      Cependant, j'aurai bien aimé comprendre ce qui s'est passé :/