Récemment, j'ai remarqué que mon serveur domestique devenait douloureusement lent. Toutes les ressources ont été consommées par deux processus: crond64et tsm. Même si je les ai tués à plusieurs reprises, ils ont continué à apparaître encore et encore.
Dans le même temps, mon FAI m'informait d'un abus provenant de mon adresse IP:
==================== Excerpt from log for 178.22.105.xxx====================
Note: Local timezone is +0100 (CET)
Jan 28 20:55:44 shared06 sshd[26722]: Invalid user admin from 178.22.105.xxx
Jan 28 20:55:44 shared06 sshd[26722]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.22.105.xxx
Jan 28 20:55:45 shared06 sshd[26722]: Failed password for invalid user admin from 178.22.105.xxx port 33532 ssh2
Jan 28 20:55:46 shared06 sshd[26722]: Received disconnect from 178.22.105.xxx port 33532:11: Bye Bye [preauth]
Jan 28 20:55:46 shared06 sshd[26722]: Disconnected from 178.22.105.xxx port 33532 [preauth]
Jan 28 21:12:05 shared06 sshd[30920]: Invalid user odm from 178.22.105.xxx
Jan 28 21:12:05 shared06 sshd[30920]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.22.105.xxx
Jan 28 21:12:07 shared06 sshd[30920]: Failed password for invalid user odm from 178.22.105.xxx port 45114 ssh2
Jan 28 21:12:07 shared06 sshd[30920]: Received disconnect from 178.22.105.xxx port 45114:11: Bye Bye [preauth]
Jan 28 21:12:07 shared06 sshd[30920]: Disconnected from 178.22.105.xxx port 45114 [preauth]
J'ai été informé par ce site Web que je pourrais avoir un virus. J'exécute Sophos AV en analysant l'intégralité de mon disque dur et en effet, il a détecté un virus /tmp/.mountfs/.rsync. J'ai donc supprimé le dossier entier et j'ai pensé que c'était tout. Mais il a continué à revenir après. Ensuite, j'ai archivé le fichier cron de l'utilisateur /var/spool/cron/crontabs/kodi(le virus s'exécutait en utilisant l'utilisateur de mon serveur multimédia kodi), qui ressemblait à ceci:
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (cron.d installed on Sun Feb 3 21:52:03 2019)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* */12 * * * /home/kodi/.ttp/a/upd>/dev/null 2>&1
@reboot /home/kodi/.ttp/a/upd>/dev/null 2>&1
5 8 * * 0 /home/kodi/.ttp/b/sync>/dev/null 2>&1
@reboot /home/kodi/.ttp/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.mountfs/.rsync/c/aptitude>/dev/null 2>&1
Il semble que le virus se réactive de temps en temps à partir d'un autre répertoire. Le contenu de ce répertoire est:
>>> ls /home/kodi/.ttp/*
/home/kodi/.ttp/cron.d /home/kodi/.ttp/dir2.dir
/home/kodi/.ttp/a:
a bash.pid config.txt crond32 crond64 cronda crondb dir.dir pools.txt run stop upd
/home/kodi/.ttp/b:
a dir.dir rsync run stop sync
/home/kodi/.ttp/c:
aptitude dir.dir go ip lib n p run slow start stop tsm tsm32 tsm64 v watchdog
J'ai supprimé tous ces fichiers et les entrées dans la crontab et j'espère qu'avec cela, le problème est résolu. Cependant, je serais intéressé par ce virus, comment je l'ai pu attraper (il pourrait être connecté à Kodi) et ce que je peux faire pour l'empêcher. Heureusement, il ne fonctionnait que depuis un utilisateur avec des droits limités, mais c'était toujours ennuyeux à gérer.
ÉDITER
Bien que j'ai apparemment supprimé tous les restes de ce virus (j'ai également supprimé l'intégralité du dossier tmp), le virus revenait sans cesse. J'ai réalisé qu'il y avait une entrée dans ~/.ssh/authorized_hostslaquelle je ne me suis définitivement pas mis. Cela explique comment le virus pourrait être replanté à plusieurs reprises. J'ai supprimé l'entrée, désactivé la connexion pour cet utilisateur, désactivé la connexion par mot de passe (mot de passe uniquement) et j'utilise maintenant un port non standard.
J'ai également remarqué des tentatives de connexion répétées sur mon serveur avec des noms d'utilisateurs aléatoires, probablement par une sorte de bot (le journal ressemblait étonnamment à celui lancé depuis mon IP, envoyé par mon FAI). Je suppose que c'est ainsi que mon ordinateur a été infecté en premier lieu.
cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB... ...VKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~. Je viens de faire uncp /etc/skel/.bashrc /home/mycompromiseduser/pour l'enlever.Réponses:
J'avais la même chose. Le service a installé rsync et a obtenu des fichiers. J'ai trouvé un
dota.tar.gzfichier dans le dossier utilisateur.ufw deny out 22)pkill -KILL -u kodi(cela tue tous les processus en cours d'exécution de l'utilisateur kodi)deluser kodi/tmp/.mountfs*Veuillez noter que cela ruinera probablement les choses pour Kodi. Au lieu de supprimer tout le homehome, vous ne pouvez probablement supprimer que
dota.tar.gz(s'il est là) et le.ttpdossier (n'oubliez pas de nettoyer la crontab!)Après un redémarrage, je ne vois plus de connexions sortantes (vérifiez avec:
L'infection s'est produite via un utilisateur avec un mot de passe faible (compte kodi avec le mot de passe par défaut peut-être?)
la source
J'avais le même malware. L'entrée se faisait via un mot de passe utilisateur non enregistré via ssh (port non défini par défaut), a été détectée et supprimée après environ 24 heures.
Dans mon cas, la suppression crontab de l'utilisateur,
rm -rdf /tmp/.*,rm -rdf /home/user/.*,killall -u userétait suffisant.la source
Eu cette chose aujourd'hui. J'ai examiné le système et trouvé que mon système avait ses traces depuis environ un mois et je n'ai pas réalisé que cette chose était là jusqu'à ce que mon FAI m'en ait informé.
Les logiciels malveillants sont venus d'un utilisateur non sécurisé avec un mot de passe faible. Dans mon cas, c'était un utilisateur de timemachine. Le journal de pénétration ressemblait à ceci.
Il s'agit d' un mineur XMRIG et d'un exploit qui analyse les autres IP pour les mêmes faiblesses. Ainsi, une machine peut infecter en cascade des dizaines d'autres. Vous pouvez consulter le rapport de MS sur cette cyberattaque .
La protection la plus efficace contre ce type d'attaques consiste à installer
fail2bansur votre serveur, à limiter l'accès ssh avecufwet à utiliser la liste blanche ACL pour les systèmes qui peuvent accéder à SSH sur votre serveur.la source
Dans mon cas, la source de l'infection était un utilisateur qui ne modifiait pas son mot de passe dangereux depuis la création de son compte (bien sûr, je lui ai dit de le faire). Mon serveur est probablement sur certaines listes: j'obtiens environ 1000 interdictions par semaine de fail2ban (essayez 4 fois avec un mauvais utilisateur ou mot de passe et soyez bloqué pendant un mois)
la source
Voici ma solution (également nommée malware de crypo mining):
la source