Processus Linux inconnu avec commande aléatoire

J'ai un processus inconnu quand je lance top:

• Lorsque je tue le processus, il revient avec un autre nom aléatoire.
• quand je vérifie les niveaux rc.d et init.d, il y a beaucoup de noms aléatoires similaires à celui-ci et celui-ci est également présent.
• quand j'essaye d'apt-get remove ou anselme ça recommence.
• Lorsque je branche un câble réseau, tout notre réseau est verrouillé.

Avez-vous une idée de comment je peux l'enlever?

Quel est ce service / processus?

Ceci est le fichier exe, quand je le supprime, il revient aussi.

/proc/**pid**/exe => symbolic link to /usr/bin/hgmjzjkpxa

Lorsque je vérifie "netstat -natp", il y a une adresse étrangère d'établissement 98.126.251.114:2828. Lorsque j'essaie d'ajouter des règles à iptables, cela ne fonctionne pas. Mais après avoir essayé puis redémarré cette adresse, changez-la en 66.102.253.30:2828.

OS est Debian Wheeze

Ceci est connu comme le cheval de Troie XORDDos Linux L'astuce est de courir killavec -STOPle processus d'être mis en pause pour qu'il ne crée pas une nouvelle.

`kill -STOP PROCESS_ID`

J'ai quelques expériences sur ce cheval de Troie de chaîne aléatoire de 10 bits, il enverra beaucoup de paquets pour SYN flood.

1. Réduisez votre réseau

Le cheval de Troie a un fichier brut venant de /lib/libudev.so, il va copier et copier à nouveau. Il ajoutera également le cron.hourlytravail nommé gcc.sh, puis ajoutera le script initial dans votre /etc/rc*.d(Debian, CentOS peut-être /etc/rc.d/{init,rc{1,2,3,4,5}}.d)

2. Utilisez rootpour exécuter le script ci-dessous pour modifier les privilèges du dossier:chmod 0000 /lib/libudev.so && rm -rf /lib/libudev.so && chattr +i /lib/

3. Supprimez tous les /etc/rc{0,1,2,3,4,5,6,S}.dfichiers créés aujourd'hui. Le nom ressemble à S01????????.

4. Modifiez votre crontab, supprimez le gcc.shscript dans votre /etc/cron.hourly, supprimez le gcc.shfichier ( /etc/cron.hourly/gcc.sh) puis ajoutez des privilèges pour votre crontab:sed '/gcc.sh/d' /etc/crontab && chmod 0000 /etc/crontab && chattr +i /etc/crontab

5. Utilisez cette commande pour vérifier les dernières modifications apportées au fichier: ls -lrt

Si vous trouvez des fichiers suspects nommés S01xxxxxxxx(ou K8xxxxxxxx), supprimez-les.

6. Ensuite, vous devez redémarrer sans réseau.

Ensuite, le cheval de Troie doit être nettoyé et vous pouvez modifier les privilèges du dossier sur les valeurs d'origine ( chattr -i /lib /etc/crontab).

Je vous parie un dollar c'est https://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/ . Tous vos symptômes sont exactement tels que décrits.

Pour moi, il y avait deux options:

1. Pour le cheval de Troie qui manipule des fichiers dans / usr / bin, j’ai seulement fait ceci: echo> /lib/libudev.so Tuez le PID du cheval de Troie

2. Pour ceux qui jouent avec / bin (ici, il y avait toujours 5 à 10 processus en cours d'exécution pour une fraction de chattr + i / bin et suivez les étapes mentionnées par rainysia

Nous sommes également confrontés au même problème. Nos serveurs sont également piratés et j’ai découvert qu’ils avaient forcé la connexion ssh, qu’ils avaient réussi et qu’ils avaient réussi à injecter des chevaux de Troie dans notre système.

Voici les détails:

less / var / log / secure | grep 'Echec du mot de passe' | grep '222.186.15.26' | wc -l 37772 commencé

et obtenu l’accès en dessous du temps imparti: mot de passe accepté pour root à partir du port 65418 ssh2 du 222.186.15.26

Et selon l’emplacement d’emplacement IP, cette adresse IP appartient à quelque part en Chine.

Mesures correctives: veuillez suivre les étapes indiquées par: @rainysia

Mesures préventives :

1. Selon moi, un gestionnaire de notifications devrait être présent quand quelqu'un a essayé de ssh ou d'accéder à votre serveur et a échoué plusieurs fois.
2. Les contrôleurs de débit réseau devraient être présents si vous utilisez une plate-forme cloud telle que aws, gcp, azure, etc.