kdevtmpfsi en utilisant tout le CPU

La solution mentionnée ici a fonctionné pour nous. Vous créez essentiellement les fichiers que le mineur utilise, sans aucun droit, de sorte que le mineur ne peut pas les créer et les utiliser. https://github.com/docker-library/redis/issues/217

touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing

echo "everything is good here" > /tmp/kdevtmpfsi

echo "everything is good here" > /var/tmp/kinsing`

touch /tmp/zzz

echo "everything is good here" > /tmp/zzz

chmod go-rwx /var/tmp

chmod 1777 /tmp`

L'autre réponse ici est bonne et vous devriez faire tout ce qui y est mentionné. Mais, si la chose revient sans cesse et / ou que vous n'utilisez pas réellement Docker, vous avez probablement une vulnérabilité RCE non corrigée dans phpUnit. Les détails sont ici:

https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487

Notre situation était:

• Docker n'est pas du tout utilisé.
• Nous avions supprimé tous les fichiers liés au mineur.
• Nous avions verrouillé les choses en utilisant les commandes touch et chmod ci-dessus.
• La fichue chose essayait de fonctionner à des moments apparemment aléatoires.

Une fois que vous avez verrouillé les choses avec les modifications touch / chmod, il ne peut rien faire, mais c'est toujours ennuyeux, et cette vulnérabilité phpUnit est un énorme trou qui doit de toute façon être branché.

J'espère que cela t'aides.

J'ai trouvé toutes les solutions ci-dessus utiles, mais elles semblent toutes être la solution temporaire car nous devons surveiller l'instance et si nous remarquons une activité malveillante, refaites le même processus.

Je suis tombé sur ce virus il y a environ 1 mois et j'ai appliqué toutes les solutions ci-dessus, ce qui fonctionne bien pendant la période limitée après cela, il reviendra.

Même moi, je n'ai pas installé docker dans le système, donc le port API ouvert de docker n'était pas un problème.

Mais il existe des logiciels open source qui sont la porte ouverte pour la parenté.

PhpMailer et Solr ont une vulnérabilité de Remote Code Exec qui cause tout le problème.

La solution simple consiste à mettre à niveau votre version de Solr vers 8.5.1 et il y a encore une chose que vous pouvez définir comme sécurité qui supprimera à 100% le virus et ce sera permanent.

Voici l'explication complète: https://github.com/amulcse/solr-kinsing-malware

Je suis face à face avec lui après avoir installé et exécuté le Flink Cluster. On dirait que nous avons été attaqués par un logiciel malveillant, qui essaie d'utiliser le processeur de notre serveur pour exécuter le programme pour extraire la pièce.

Ma solution est la suivante:

1. Tuez le programme en cours d'exécution en premier:

   • Exécutez htop , puis appuyez sur F9 pour tuer le programme. Nous devons également tuer kdevtmpfsi et kinsing .

2. Supprimer le fichier malveillant qui sera exécuté et utilisant tout le processeur (avec mes centos 7)

   find / -iname kdevtmpfsi -exec rm -fv {} \;

   find / -iname kinsing -exec rm -fv {} \;

Le résultat devrait être:

/tmp/kdevtmpfsi is removed
/var/tmp/kinsing is removed

3. Créez un fichier avec le même nom:

   • touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing
   • echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi
   • echo "kinsing is fine now" > /var/tmp/kinsing
   • Maintenant, make two files est en lecture seule avec la commande suivante:

   chattr +i /tmp/kdevtmpfsi chattr +i /var/tmp/kinsing

** Vous devriez redémarrer votre serveur. Si son problème est dans un serveur distant et que vous vous y connectez avec un port spécifié, vous pouvez passer au port ssh pour augmenter la sécurité!

J'espère que cela vous aidera!

Peut-être que ce serait utile pour quelqu'un. J'ai trouvé d'autres entrées de kinsing / kdevtmpfsi:

ExecStart=/etc/kinsing

Dans bot.service:

/etc/kinsing

/usr/lib/systemd/system/bot.service

J'ai juste suivi les instructions de cette bande de roulement, supprimé les deux fichiers, redémarré le serveur.

J'espère que cela aidera quelqu'un. J'ai passé toute la journée à essayer de le résoudre.

J'ai trouvé cette solution pour arrêter temporairement le processus de s'exécuter (sans utiliser Docker / Redis, donc le trou est très probablement dans phpunit):

/bin/setfacl -m u:www-data:--- /tmp/kinsing
/bin/setfacl -m u:www-data:--- /tmp/kdevtmpfsi

Cela empêchera l'utilisateur www-data (qui, dans mon cas, exécutait le processus) d'exécuter le script.

De plus, vous aurez probablement un cronjob ajouté sous l'utilisateur www-data - supprimez-le et exécutez le service cron restart !

Rappelez-vous, c'est un correctif / hack temporaire. Vous devez mettre à jour le logiciel vulnérable pour supprimer définitivement ce fil!

J'ai eu des difficultés avec ce mineur pendant quelques jours et dans mon cas, c'était le port php-fpm:9000 exposé.
Je suppose qu'il est possible d'injecter du code à distance de cette façon.

Donc, si vous utilisez docker & php-fpm, n'exécutez PAS votre conteneur de cette façon:

docker run -v /www:/var/www -p 9000:9000 php:7.4

Supprimez le mappage de port: -p 9000: 9000

N'oubliez pas de reconstruire et redémarrer vos conteneurs.

Plus de détails ici: https://github.com/laradock/laradock/issues/2451#issuecomment-577722571