Présence de xmrig qui utilise tout le CPU
... / Présence de xmrig qui uti...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

Présence de xmrig qui utilise tout le CPU

by
ChristopheC44
Created on 2019-09-07 05:16:51 (edited on 2024-09-04 13:52:49) in Serveurs dédiés

Bonjour,
je constate que sur une VM, j'ai un processus "xmrig" qui consomme presque tout le CPU. Et un autre, avec un nom pas très orthodoxe "38b3eff8b" qui consomme presque le reste.
Une partie de la littérature, sur internet, parle de virus ... mais je ne trouve rien de vraiment tranché.
Quel est votre avis, s'il vous plaît ?

D'avance, merci pour vos lumières.
Christophe


5 Replies ( Latest reply on 2019-09-09 21:51:14 by
Cassiopee
)

tu mines ou non ? (https://github.com/xmrig/xmrig)
si non, oui je verrais bien serveur craqué
en attendant, tu peux killer ces processus?
réinstaller le système?

Non, je ne mine pas, délibérément.
J'ai killé les processus, mais ils reviennent.
Et la réinstallation du système est la dernière chose que je souhaite faire car la VM vit et a été installée il y a longtemps et pas toujours gérée par moi !!!

ça confirmerait que ton système ou ta VM est compromise
il va falloir réparer tout ça.... :/

bon courage


J'ai killé les processus, mais ils reviennent.


Machine infectée = machine à réinstaller.

Oui, en principe une machine vérolée jusqu'au trognon (mais l'est-elle vraiment ?)
c'est la réinstallation obligatoire. Disons que c'est en général la manière la plus rapide
de se retrouver dans une situation saine.

Si la réinstallation n'est pas du tout envisageable, alors une (éventuellement) longue
enquête t'attend :

1) comprendre par quelle faille le pirate s'est introduit et boucher cette faille
2) dans un second temps seulement, supprimer tous les scripts pirates installés
(en RAM et dans le disque dur)

Faire le 2 sans faire le 1 au préalable, c'est mettre le pirate dehors par la fenêtre
... en laissant la porte principale grande ouverte, c'est certain qu'il va revenir :-)

De nos jours, les points d'entrée les plus courants sont des sites web utilisant
des CMS pas à jour, des plugins/addons présentant des failles, etc.

Voir sous quel utilisateur Unix tournent ces scripts pirates pourrait déjà te donner
une première piste à suivre.


Voir sous quel utilisateur Unix


En effet il est possible que seul un user nonroot ait été infecté, et supprimer l'utilisateur rend la machine plus ou moins propre.
Il est permis de redouter une version préhistorique de tout le reste puisque les virus et trojans s'y installent.

Faire le 2 sans faire le 1 au préalable, c'est mettre le pirate dehors par la fenêtre
... en laissant la porte principale grande ouverte, c'est certain qu'il va revenir :-)


En s'assurant qu'il sera beaucoup plus aggressif dans sa prochaine intrusion !

[quote]En effet il est possible que seul un user nonroot ait été infecté, et supprimer l'utilisateur rend la machine plus ou moins propre.
[/quote]
Oui, c'est une possibilité mais je pensais surtout à l'idée que ça puisse permettre de savoir
quel site web a été piraté (s'il y en a plusieurs) et à partir de là, quel(s) fichier(s) de log Apache
examiner afin de repérer la porte d'entrée du pirate et de la refermer.

[quote]
Il est permis de redouter une version préhistorique de tout le reste puisque les virus et trojans s'y installent.
[/quote]
Oui, c'est souvent le point faible, une non mise à jour des scripts PHP constituant le site web.


En s'assurant qu'il sera beaucoup plus aggressif dans sa prochaine intrusion !

Tout à fait.

Et si jamais le pirate a accès au compte root, ça peut même se terminer par un magnifique :

# rm -rf /

:-]

Dans le cas présent, on peut espérer pour lui que ce ne sont "que" des scripts automatiques,
auquel cas ce ne sera seulement un nouveau piratage identique au premier.


Et si jamais le pirate a accès au compte root, ça peut même se terminer par un magnifique :

# rm -rf /

ça c'est le moins pire, tu remontes les backups que tu as sûrement dans un coin.

Le plus pire c'est quand ton zoli serveur sert de base lance-missiles, DDos, spam, attaques et C&C à ton insu.


ça c'est le moins pire, tu remontes les backups que tu as sûrement dans un coin.

Des backups ? C'est nouveau ? ça sert à quoi :-D ?

On plaisante mais c'est vrai que souvent les backups sont absents ou datent de Mathusalem.

[quote]
Le plus pire c'est quand ton zoli serveur sert de base lance-missiles, DDos, spam, attaques et C&C à ton insu.
[/quote]
Effectivement, ce que je vois le plus passer ce sont des envois massifs de spams
(et après, pour déblacklister l'adresse IP utilisée ... que du bonheur)

ça c'est le moins pire, tu remontes les backups que tu as sûrement dans un coin.

Le plus pire c'est quand ton zoli serveur sert de base lance-missiles, DDos, spam, attaques et C&C à ton insu.


La dernière fois que je n'étais pas parvenu à boucher la faille, l'attaquant à récupéré mon IP et a lancé un DDoS sur mon IP résidentielle... Et vous savez quoi ? De tous les serveurs qui m'agressaient, ce sont ceux d'OVH qui étaient le plus stables ! (et aussi ceux qui ont été coupé le plus rapidement)


La dernière fois que je n'étais pas parvenu à boucher la faille, l'attaquant à récupéré mon IP et a lancé un DDoS sur mon IP résidentielle... Et vous savez quoi ? De tous les serveurs qui m'agressaient, ce sont ceux d'OVH qui étaient le plus stables ! (et aussi ceux qui ont été coupé le plus rapidement)

Comme quoi OVH font de bons serveurs stables ... comment ça, ce n'est pas le problème :-D ?

Là tu es tombé sur un cas quand même 8-]