MODIFICATION 2 :
il y a une bonne raison pour laquelle ce message attire autant l'attention :vous avez réussi à enregistrer l'intégralité de la session en direct d'un intrus sur votre PC. C'est très différent de notre expérience quotidienne, où nous sommes confrontés à la découverte des conséquences de ses actes et essayons de les réparer. Ici, nous le voyons au travail, le voyons avoir des problèmes pour établir la porte dérobée, revenir sur ses pas, travailler fébrilement (peut-être parce qu'il était assis à votre bureau, comme suggéré ci-dessus, ou peut-être, et à mon avis plus probablement, parce qu'il était incapable de faire fonctionner son logiciel malveillant sur le système, lisez ci-dessous), et essayez de déployer des instruments de contrôle entièrement autonomes. C'est ce à quoi les chercheurs en sécurité sont quotidiennement témoins avec leurs pièges à miel . Pour moi, c'est une chance très rare, et la source d'un certain amusement.
Vous avez certainement été piraté. La preuve de cela pas proviennent de l'extrait du auth.log fichier que vous avez affiché, car cela signale une tentative de connexion infructueuse, qui s'est produite sur une courte période (deux secondes). Vous remarquerez que la deuxième ligne indique Failed password , tandis que le troisième rapporte un pre-auth déconnecter :le gars a essayé et a échoué.
La preuve vient plutôt du contenu des deux fichiers http://222.186.30.209:65534/yjz et http://222.186.30.209:65534/yjz1 que l'attaquant a téléchargé sur votre système.
Le site est actuellement ouvert à tous pour les télécharger, ce que j'ai fait. J'ai d'abord exécuté file sur eux, qui indiquait :
$ file y*
yjz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
yjz1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
Ensuite, je les ai amenés sur une machine virtuelle Debian 64 bits que j'ai; un examen de leur contenu à travers le strings La commande a révélé beaucoup de choses suspectes (référence à diverses attaques bien connues, à des commandes à remplacer, un script qui a clairement été utilisé pour mettre en place un nouveau service, etc.).
J'ai ensuite produit les hachages MD5 des deux fichiers et les ai transmis à la base de données de hachage de Cymru pour voir s'il s'agissait d'agents malveillants connus. Alors que yjz n'est pas, yjz1 est, et Cymru rapporte une probabilité de détection par un logiciel antivirus de 58 %. Il indique également que ce fichier a été vu pour la dernière fois il y a environ trois jours, il est donc relativement récent.
Exécution de clamscan (partie du clamav package) sur les deux fichiers que j'ai obtenus :
$ clamscan y*
yjz: Linux.Backdoor.Gates FOUND
yjz1: Linux.Trojan.Xorddos FOUND
nous sommes donc maintenant certains que le logiciel Linux standard peut l'identifier.
Que devez-vous faire ?
Bien que plutôt nouveau, aucun des deux systèmes n'est très nouveau, voir cet article de janvier 2015 sur XorDdos, par exemple. Ainsi, la plupart des packages gratuits devraient pouvoir le supprimer. Vous devriez essayer :clamav , rkhunter , chkrootkit . J'ai cherché sur Google et j'ai vu qu'ils prétendaient pouvoir le repérer. Utilisez-les pour vérifier le travail du prédécesseur, mais après avoir exécuté ces trois programmes, vous devriez être prêt à partir.
Quant à la question plus large, what should you do to prevent future infections , la réponse de Journeyman est un bon premier pas. Gardez simplement à l'esprit qu'il s'agit d'un combat permanent, un combat que nous tous (y compris moi !) pouvons très bien avoir perdu sans même le savoir.
MODIFIER :
À l'invite (indirecte) de Viktor Toth, je voudrais ajouter quelques commentaires. Il est certainement vrai que l'intrus a rencontré quelques difficultés :il télécharge deux outils de piratage distincts, change plusieurs fois leurs permissions, les redémarre plusieurs fois, et essaie plusieurs fois de désactiver le pare-feu. Il est facile de deviner ce qui se passe :il s'attend à ce que ses outils de piratage ouvrent un canal de communication vers l'un de ses PC infectés (voir plus loin), et, lorsqu'il ne voit pas ce nouveau canal surgir sur son interface graphique de contrôle, il craint son piratage outil est bloqué par le pare-feu, il répète donc la procédure d'installation. Je suis d'accord avec Viktor Toth que cette étape particulière de son opération ne semble pas apporter les fruits escomptés, mais je voudrais vous encourager très fortement ne pas sous-estimer l'étendue des dommages infligés à votre pc.
Je fournis ici une sortie partielle de strings yjz1 :
etc/init.d/%s
/etc/rc%d.d/S90%s
--del
chkconfig
remove
update-rc.d
/etc/cron.hourly/gcc4.sh
/etc/rc.d/rc%d.d/S90%s
--add
defaults
/proc/%d/exe
/proc/self/exe
HOME=/
MYSQL_HISTFILE=/dev/null
#!/bin/sh
# chkconfig: 12345 90 90
# description: %s
### BEGIN INIT INFO
# Provides: %s
# Required-Start:
# Required-Stop:
# Default-Start: 1 2 3 4 5
# Default-Stop:
# Short-Description: %s
### END INIT INFO
case $1 in
start)
stop)
esac
sed -i '/\/etc\/cron.hourly\/gcc4.sh/d' /etc/crontab && echo '*/3 * * * * root /etc/cron.hourly/gcc4.sh' >> /etc/crontab
etc/init.d/%s
GET %s HTTP/1.1
%sHost: %s
POST %s HTTP/1.1
%sHost: %s
Content-Type: application/x-www-form-urlencoded
Content-Length: %d
%s%s
Accept: */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; TencentTraveler ; .NET CLR 1.1.4322)
Connection: Keep-Alive
Cela fournit la preuve d'une altération des services (en /etc/init.d et en /etc/rc.d ), avec crontab , avec le fichier historique de mysql , et quelques fichiers en proc qui sont des liens vers bash (ce qui suggère qu'une version frauduleuse faite sur mesure de votre coque a été plantée). Ensuite le programme génère une requête HTTP (vers un site parlant chinois,
Accept-Language: zh-cn
ce qui donne corps au commentaire de David Schwartz ci-dessus), ce qui peut créer encore plus de ravages. Dans la requête, les binaires (Content-Type: application/x-www-form-urlencoded ) doivent être téléchargés sur le pc attaqué (GET) et chargés sur la machine de contrôle (POST). Je n'ai pas pu établir ce qui serait téléchargé sur le pc attaqué, mais, étant donné la petite taille des deux yjz et yjz1 (1,1 Mo et 600 Ko, respectivement), je peux me risquer à supposer que la plupart des fichiers nécessaires pour dissimuler le rootkit, c'est-à-dire les versions modifiées de ls , netstat , ps , ifconfig ,..., seraient téléchargés de cette façon. Et cela expliquerait les tentatives fébriles de l'attaquant pour lancer ce téléchargement.
Il n'est pas certain que ce qui précède épuise toutes les possibilités :il nous manque certainement une partie de la transcription (entre les lignes 457 et 481) et nous ne voyons pas de déconnexion; de plus, les lignes 495-497, particulièrement inquiétantes,
cd /tmp; ./yd_cd/make
qui font référence à un fichier que nous n'avons pas vu téléchargé, et qui pourrait être une compilation :si c'est le cas, cela signifie que l'attaquant a (enfin ?) compris quel était le problème avec ses exécutables, et essaie de le réparer, auquel cas le pc attaqué est parti pour de bon. [En fait, les deux versions du malware que l'attaquant a téléchargées sur la machine piratée (et moi sur ma VM Debian 64 bits) sont pour une architecture inadaptée, x86, alors que le seul nom du pc piraté révèle le fait que il avait affaire à une architecture de bras].
La raison pour laquelle j'ai écrit cette édition est de vous inciter le plus fortement possible soit à peigner votre système avec un instrument professionnel, soit à le réinstaller à partir de zéro.
Et, au fait, si cela s'avère utile à quelqu'un, voici la liste des 331 Adresses IP auxquelles yjz tente de se connecter. Cette liste est si grande (et probablement destinée à devenir encore plus grande) que je pense que c'est la raison de la falsification de mysql . La liste fournie par l'autre porte dérobée est identique, ce qui, je suppose, est la raison pour laquelle une information aussi importante est laissée ouverte (je pense l'attaquant n'a pas souhaité faire l'effort de les stocker au format noyau, il a donc mis toute la liste dans un fichier en clair, qui est probablement lu par toutes ses backdoors, quel que soit l'OS) :
61.132.163.68
202.102.192.68
202.102.213.68
202.102.200.101
58.242.2.2
202.38.64.1
211.91.88.129
211.138.180.2
218.104.78.2
202.102.199.68
202.175.3.3
202.175.3.8
202.112.144.30
61.233.9.9
61.233.9.61
124.207.160.110
202.97.7.6
202.97.7.17
202.106.0.20
202.106.46.151
202.106.195.68
202.106.196.115
202.106.196.212
202.106.196.228
202.106.196.230
202.106.196.232
202.106.196.237
202.112.112.10
211.136.17.107
211.136.28.231
211.136.28.234
211.136.28.237
211.147.6.3
219.141.136.10
219.141.140.10
219.141.148.37
219.141.148.39
219.239.26.42
221.130.32.100
221.130.32.103
221.130.32.106
221.130.32.109
221.130.33.52
221.130.33.60
221.176.3.70
221.176.3.73
221.176.3.76
221.176.3.79
221.176.3.83
221.176.3.85
221.176.4.6
221.176.4.9
221.176.4.12
221.176.4.15
221.176.4.18
221.176.4.21
58.22.96.66
218.104.128.106
202.101.98.55
211.138.145.194
211.138.151.161
211.138.156.66
218.85.152.99
218.85.157.99
222.47.29.93
202.101.107.85
119.233.255.228
222.47.62.142
122.72.33.240
211.98.121.27
218.203.160.194
221.7.34.10
61.235.70.98
113.111.211.22
202.96.128.68
202.96.128.86
202.96.128.166
210.21.3.140
210.21.4.130
211.95.193.97
211.98.2.4
211.98.4.1
211.162.61.225
211.162.61.235
211.162.61.255
211.162.62.1
211.162.62.60
221.4.66.66
202.103.176.22
202.96.144.47
210.38.192.33
202.96.134.33
202.96.134.133
202.96.154.15
210.21.196.6
221.5.88.88
202.103.243.112
202.193.64.33
61.235.164.13
61.235.164.18
202.103.225.68
221.7.136.68
202.103.224.68
211.97.64.129
211.138.240.100
211.138.242.18
211.138.245.180
221.7.128.68
222.52.118.162
202.98.192.67
202.98.198.167
211.92.136.81
211.139.1.3
211.139.2.18
202.100.192.68
211.97.96.65
211.138.164.6
221.11.132.2
202.100.199.8
202.99.160.68
202.99.166.4
202.99.168.8
222.222.222.222
202.102.224.68
202.102.227.68
222.85.85.85
222.88.88.88
210.42.241.1
202.196.64.1
112.100.100.100
202.97.224.68
219.235.127.1
61.236.93.33
211.93.24.129
211.137.241.34
219.147.198.230
202.103.0.68
202.103.0.117
202.103.24.68
202.103.44.150
202.114.0.242
202.114.240.6
211.161.158.11
211.161.159.3
218.104.111.114
218.104.111.122
218.106.127.114
218.106.127.122
221.232.129.30
59.51.78.210
61.234.254.5
202.103.96.112
219.72.225.253
222.243.129.81
222.246.129.80
211.142.210.98
211.142.210.100
220.168.208.3
220.168.208.6
220.170.64.68
218.76.192.100
61.187.98.3
61.187.98.6
202.98.0.68
211.93.64.129
211.141.16.99
202.98.5.68
219.149.194.55
211.138.200.69
202.102.3.141
202.102.3.144
58.240.57.33
112.4.0.55
114.114.114.114
114.114.115.115
202.102.24.34
218.2.135.1
221.6.4.66
221.131.143.69
202.102.8.141
222.45.0.110
61.177.7.1
218.104.32.106
211.103.13.101
221.228.255.1
61.147.37.1
222.45.1.40
58.241.208.46
202.102.9.141
202.102.7.90
202.101.224.68
202.101.226.68
211.141.90.68
211.137.32.178
202.96.69.38
211.140.197.58
219.149.6.99
202.96.86.18
101.47.189.10
101.47.189.18
118.29.249.50
118.29.249.54
202.96.64.68
202.96.75.68
202.118.1.29
202.118.1.53
219.148.204.66
202.99.224.8
202.99.224.67
211.90.72.65
211.138.91.1
218.203.101.3
202.100.96.68
211.93.0.81
222.75.152.129
211.138.75.123
202.102.154.3
202.102.152.3
219.146.1.66
219.147.1.66
202.102.128.68
202.102.134.68
211.138.106.19
211.90.80.65
202.99.192.66
202.99.192.68
61.134.1.4
202.117.96.5
202.117.96.10
218.30.19.40
218.30.19.50
116.228.111.118
180.168.255.18
202.96.209.5
202.96.209.133
202.101.6.2
211.95.1.97
211.95.72.1
211.136.112.50
211.136.150.66
119.6.6.6
124.161.97.234
124.161.97.238
124.161.97.242
61.139.2.69
202.98.96.68
202.115.32.36
202.115.32.39
218.6.200.139
218.89.0.124
61.139.54.66
61.139.39.73
139.175.10.20
139.175.55.244
139.175.150.20
139.175.252.16
168.95.1.1
210.200.211.193
210.200.211.225
211.78.130.1
61.31.1.1
61.31.233.1
168.95.192.1
168.95.192.174
61.60.224.3
61.60.224.5
202.113.16.10
202.113.16.11
202.99.96.68
202.99.104.68
211.137.160.5
211.137.160.185
219.150.32.132
202.98.224.68
211.139.73.34
61.10.0.130
61.10.1.130
202.14.67.4
202.14.67.14
202.45.84.58
202.45.84.67
202.60.252.8
202.85.128.32
203.80.96.9
203.142.100.18
203.142.100.21
203.186.94.20
203.186.94.241
221.7.1.20
61.128.114.133
61.128.114.166
218.202.152.130
61.166.150.123
202.203.128.33
211.98.72.7
211.139.29.68
211.139.29.150
211.139.29.170
221.3.131.11
222.172.200.68
61.166.150.101
61.166.150.139
202.203.144.33
202.203.160.33
202.203.192.33
202.203.208.33
202.203.224.33
211.92.144.161
222.221.5.240
61.166.25.129
202.96.103.36
221.12.1.227
221.130.252.200
222.46.120.5
202.96.96.68
218.108.248.219
218.108.248.245
61.130.254.34
60.191.244.5
202.96.104.15
202.96.104.26
221.12.33.227
202.96.107.27
61.128.128.68
61.128.192.68
218.201.17.2
221.5.203.86
221.5.203.90
221.5.203.98
221.7.92.86
221.7.92.98
Le code suivant
#!/bin/bash
echo 0 > out
while read i; do
whois $i | grep -m 1 -i country >> out
done < filename
cat out | grep -i cn | wc -l
sur la liste ci-dessus montre que 302 sur un total de 331 les adresses sont en Chine continentale, les autres sont à Hong Kong, Mongolie, Taïwan. Cela ajoute un soutien supplémentaire à l'affirmation de David Schwartz selon laquelle il s'agit principalement d'un anneau de robots chinois.
MODIFICATION 3
À la demande de @vaid (l'auteur de l'OP, lisez son commentaire ci-dessous), j'ajouterai un commentaire sur la façon de renforcer la sécurité d'un système Linux de base (pour un système fournissant de nombreux services, c'est un sujet beaucoup plus complexe). vaid déclare qu'il a fait ce qui suit :
Réinstaller le système
a changé le mot de passe root en un mot de passe de 16 caractères avec un mélange de lettres minuscules et majuscules, de caractères et de chiffres.
Changement du nom d'utilisateur en un nom d'utilisateur de 6 caractères mixtes et application du même mot de passe que celui utilisé pour root
changé le port SSH en quelque chose au-dessus de 5000
désactivé la connexion racine SSH.
C'est bien (sauf que j'utilise un port supérieur à 10 000 car de nombreux programmes utiles utilisent les ports inférieurs à 10 000). Mais je ne saurais trop insister sur la nécessité d'utiliser des clés cryptographiques pour la connexion ssh , au lieu de mots de passe. Je vais vous donner un exemple personnel. Sur l'un de mes VPS, je ne savais pas s'il fallait changer le port ssh; Je l'ai laissé à 22, mais j'ai utilisé des clés de chiffrement pour l'authentification. J'en ai eu des centaines de tentatives d'effraction par jour , aucun n'a réussi. Lorsque, fatigué de vérifier quotidiennement que personne n'avait réussi, j'ai finalement basculé le port à quelque chose au-dessus de 10 000, les tentatives d'effraction sont tombées à zéro. Attention, ce n'est pas que les hackers soient stupides (ils ne le sont pas !), ils chassent simplement des proies plus faciles.
Il est facile d'activer une clé de chiffrement avec RSA comme algorithme de signature, voir le commentaire ci-dessous de Jan Hudec (merci !) :
cd; mkdir .ssh; chmod 700 .ssh; cd .ssh; ssh-keygen -t rsa (then hit <kbd>ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *
Il ne vous reste plus qu'à copier le fichier id_rsa à la machine à partir de laquelle vous souhaitez vous connecter (dans un répertoire .ssh , aussi chmod 'ed à 700), puis émettez la commande
ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa [email protected]
Lorsque vous êtes sûr que cela fonctionne, éditez sur le serveur (=la machine à laquelle vous souhaitez vous connecter) le fichier /etc/ssh/sshd_config , et changez la ligne
#PasswordAuthentication yes
à
PasswordAuthentication no
et redémarrez le ssh (service ssh restart ou systemctl restart ssh , ou quelque chose comme ça, selon la distribution).
Cela résistera beaucoup. En fait, il n'y a actuellement aucun exploit connu contre les versions actuelles de openssh v2 , et de RSA tel qu'employé par openssh v2 .
Enfin, pour vraiment verrouiller votre machine, vous devrez configurer le pare-feu (netfilter/iptables) comme suit :
iptables -A INPUT -p tcp --dport YourChosenNonStandardPort -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
Ceci, 1) autorise les connexions ssh à la fois du LAN et du WAN, 2) autorise toutes les entrées provenant de vos requêtes (par exemple, lorsque vous chargez une page Web), 3) supprime tout le reste sur l'entrée, 4) autorise tout sur la sortie, et 5-6) permet tout sur l'interface de bouclage.
Au fur et à mesure que vos besoins augmentent et que d'autres ports doivent être ouverts, vous pouvez le faire en ajoutant, en haut de la liste, des règles telles que :
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
pour permettre par exemple aux personnes d'accéder à votre navigateur Web.
Bienvenue sur Internet - où tout serveur SSH ouvert sera probablement sondé, brutalisé et subira diverses indignités.
Pour commencer, vous devez effacer complètement le stockage sur le produit. Imaginez-le si vous voulez le transmettre à la criminalistique, mais l'installation de Linux dessus est maintenant suspecte.
Un peu de conjecture mais
-
Vous avez été brutalement forcé ou utiliser un mot de passe commun. C'est la sécurité par l'obscurité mais vous ne voulez pas de mot de passe de dictionnaire ou utiliser un compte root ouvert en SSH. Désactivez l'accès root SSH si c'est une option ou changez au moins le nom pour qu'ils aient besoin de deviner les deux. SSHing en tant que root est de toute façon une pratique de sécurité terrible. Si vous devez utiliser root, connectez-vous en tant qu'autre utilisateur et utilisez su ou sudo pour changer.
-
Selon le produit, vous souhaiterez peut-être verrouiller l'accès SSH d'une manière ou d'une autre. Un verrouillage total semble être une bonne idée et permet aux utilisateurs de l'ouvrir au besoin . En fonction des ressources que vous pouvez épargner, envisagez d'autoriser uniquement les adresses IP dans votre propre sous-réseau ou une sorte de système de limitation de connexion. Si vous n'en avez pas besoin sur le produit final, assurez-vous qu'il est désactivé.
-
Utilisez un port non standard. Sécurité par obscurité encore une fois, mais cela signifie qu'un attaquant doit cibler votre port.
-
N'utilisez jamais un mot de passe par défaut. La meilleure approche que j'ai vue consiste à générer au hasard un mot de passe pour un appareil spécifique et à l'expédier avec votre produit. La meilleure pratique est l'authentification basée sur une clé, mais je n'ai aucune idée de la façon dont vous aborderiez cela sur un produit grand public.
Oh, vous avez été définitivement piraté. Quelqu'un semble avoir été en mesure d'obtenir des informations d'identification root et a tenté de télécharger un cheval de Troie sur votre système. MariusMatutiae a fourni une analyse de la charge utile.
Deux questions se posent :a) L'attaquant a-t-il réussi ? Et b) que pouvez-vous faire à ce sujet ?
La réponse à la première question peut être un non. Remarquez comment l'attaquant essaie à plusieurs reprises de télécharger et d'exécuter la charge utile, apparemment sans succès. Je soupçonne que quelque chose (SELinux, peut-être ?) se dressait sur son chemin.
CEPENDANT :L'attaquant a également modifié votre /etc/rc.d/rc.local fichier, dans l'espoir que lorsque vous redémarrez votre système, la charge utile sera activée. Si vous n'avez pas encore redémarré le système, ne redémarrez pas avant d'avoir supprimé ces modifications de /etc/rc.d/rc.local . Si vous l'avez déjà redémarré... eh bien, pas de chance.
Quant à ce que vous pouvez faire à ce sujet :la chose la plus sûre à faire est d'effacer le système et de le réinstaller à partir de zéro. Mais ce n'est pas toujours une option. Une chose beaucoup moins sûre à faire est d'analyser exactement ce qui s'est passé et d'en effacer toute trace, si vous le pouvez. Encore une fois, si vous n'avez pas encore redémarré le système, il suffit peut-être de nettoyer /etc/rc.d/rc.local , supprimez tout ce qui a été téléchargé par l'attaquant, et enfin et surtout, changez le sacré mot de passe !
Cependant, si l'attaquant était déjà en mesure d'exécuter la charge utile, d'autres modifications de votre système peuvent être difficiles à détecter. C'est pourquoi un nettoyage complet est vraiment la seule option sûre (et recommandée). Comme vous l'avez indiqué, l'équipement en question peut être une cible de test/développement, donc l'essuyer n'est peut-être pas aussi douloureux que dans d'autres cas.
Mettre à jour :Nonobstant ce que j'ai écrit sur une éventuelle reprise, je souhaite me faire l'écho du très fort de MariusMatutiae recommandation de ne pas sous-estimer les dommages potentiels causés par cette charge utile et la mesure dans laquelle elle peut avoir compromis le système cible.