Depuis quelques jours, j’avais remarqué que mon serveur sur lequel fonctionne ce blog avait des soucis. Lenteur, alertes, augmentation de l’utilisation de la bande passante… Bref, ça ne sentait pas très bon.
Je commence par regarder les process qui fonctionne sur cette machine et je note des processus « suspects » :
... root 8929 0.0 0.0 800 128 ? S Jun09 0:00 /boot/.IptabLex root 8930 0.0 0.0 8992 332 ? Sl Jun09 0:00 /boot/.IptabLex root 8940 0.0 0.0 1164 180 ? S Jun09 0:00 /boot/.IptabLes ...
Bizarre ce IpTabLes… allons voir ce qu’il y a sur mon système
root@touilleur2:/boot# ls -la total 1812 drwxr-xr-x 2 root root 4096 2014-06-09 19:21 . drwxr-xr-x 21 root admin 4096 2014-06-09 19:21 .. -r----x--t 1 root root 33 2014-06-09 19:21 IptabLes -r----x--t 1 root root 1103207 2014-06-09 19:21 .IptabLes -r----x--t 1 root root 33 2014-06-09 19:21 IptabLex -r----x--t 1 root root 722392 2014-06-09 19:21 .IptabLex
Quand on voit cela : alerte rouge.
Les 2 petits fichiers sont des scripts shells qui exécutent 2 binaires, .IpTabLes et .IptabLex.
J’utilise fail2ban sur le serveur depuis 4 ans, et cela permet de voir aussi qu’il y a clairement un autre souci avec cette machine
root@touilleur2:/boot# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh fail2ban-postfix tcp -- anywhere anywhere multiport dports smtp,ssmtp fail2ban-apache tcp -- anywhere anywhere multiport dports www Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-apache (1 references) target prot opt source destination DROP all -- 222.186.62.73 anywhere DROP all -- static.201.81.63.178.clients.your-server.de anywhere DROP all -- 61.147.70.123 anywhere DROP all -- relatoriospy.com anywhere DROP all -- 61.160.213.190 anywhere DROP all -- server1.promocaoardente.com anywhere DROP all -- 222.186.62.44 anywhere DROP all -- 61.160.221.217 anywhere DROP all -- 61.160.215.3 anywhere DROP all -- 218.2.22.114 anywhere DROP all -- 194.51.174.61.dial.wz.zj.dynamic.163data.com.cn anywhere DROP all -- 108-166-98-9.static.cloud-ips.com anywhere DROP all -- 108-166-98-9.static.cloud-ips.com anywhere DROP all -- 78.93.227.220 anywhere DROP all -- 124.240.184.45 anywhere DROP all -- 117.41.182.93 anywhere DROP all -- static.120.226.76.144.clients.your-server.de anywhere DROP all -- 222.186.62.41 anywhere DROP all -- 218.2.22.118 anywhere DROP all -- 218.2.22.128 anywhere DROP all -- 197.49.174.61.dial.wz.zj.dynamic.163data.com.cn anywhere DROP all -- 197.51.174.61.dial.wz.zj.dynamic.163data.com.cn anywhere DROP all -- static-ip-7-92-56-61.rev.dyxnet.com anywhere DROP all -- 202.103.214.37 anywhere DROP all -- 61.160.215.60 anywhere DROP all -- 207.49.174.61.dial.wz.zj.dynamic.163data.com.cn anywhere ...
Le problème semble venir d’ElasticSearch, que j’avais utilisé pour faire un développement. Il faut savoir que par défaut, ES vient sans options de sécurités. C’est à vous de sécuriser votre installation. Cela a changé depuis la nouvelle version 1.2, et le niveau de sécurité de l’outil a été revu.
La documentation d’ElasticSearch est pourtant bien claire sur ce point, encore faut-il arriver jusqu’à cette page (tirée de la 0.90) :
Disabling dynamic scripts
We recommend running Elasticsearch behind an application or proxy, which protects Elasticsearch from the outside world. If users are allowed to run dynamic scripts (even in a search request), then they have the same access to your box as the user that Elasticsearch is running as.
First, you should not run Elasticsearch as the root user, as this would allow a script to access or do anything on your server, without limitations. Second, you should not expose Elasticsearch directly to users, but instead have a proxy application inbetween. If you do intend to expose Elasticsearch directly to your users, then you have to decide whether you trust them enough to run scripts on your box or not. If not, then even if you have a proxy which only allows GET requests, you should disable dynamic scripting by adding the following setting to the config/elasticsearch.yml file on every node:
script.disable_dynamic: trueThis will still allow execution of named scripts provided in the config, or native Java scripts registered through plugins, however it will prevent users from running arbitrary scripts via the API.
Les conséquences sont assez ennuyeuses pour toute instance d’ElasticSearch mal configurée. Je vous invite à lire avec attention ce blog de Bouke van der Bijl : http://bouk.co/blog/elasticsearch-rce/
Quant à mes installations, je ferai en sorte de placer un nginx correctement configuré désormais…
Articles connexes et ressources
IptabLes and IptabLex hack?
Securing Your Elasticsearch Cluster par Alex Brasetvik
Doc Elasticsearch url-access-control
Téléchargez ElasticSearch 1.2.1
Edit
Cette aventure m’aura cependant coûté presque 40 EUR en 5 jours. En effet, le volume échangé en 5 jours a été tellement important, que Gandi a prélevé automatiquement plusieurs fois 14 EUR sur mon compte prépayé. Le souci c’est que je n’ai pas eu d’emails m’informant du dépassement de ce quota. Au final, cette boulette m’aura coûté un peu cher…
Le .deb elasticsearch démarre pourtant avec un user spécifique …
En cloisonnant elasticsearch dans un container docker il y avait peut-être moyen de limiter la casse ?
Pas cool ! Bon courage !
Pas cool… Par contre effectivement en mettant en place un iptables, en configurant le port SSH sur un truc non standard et en limitant le nombre d’invocations du SSH tu limites un peu ce risque…
Après faut encore maintenir le système à jour, ainsi peut-être que ES. Tout un travail quoi…
Fail2ban est une solution de sécurité à minima. Il existe des possibilité de le contourner dans sa configuration par défaut. Une meilleure solution est de désactiver les accès SSH par mot de passe et de n’utiliser que des clefs SSH. Je n’ai en effet pour l’instant pas vu de tentative de brute force des clefs 2048 bits :-).
Y’a pas de honte à se faire hacker. Sécuriser correctement un serveur, cela prend autant de temps que de l’installer et il faut fournir un effort continu afin de s’en assurer (scans de sécurité réguliers, patchs, veille, …). C’est un métier en fait…
Sur le malware en question, il y a un très bon article ici : http://blog.malwaremustdie.org/2014/06/mmd-0025-2014-itw-infection-of-elf.html
A priori, c’est juste utilisé pour faire du DDoS depuis la Chine. Une fois les binaires et le script de démarrage supprimé, il n’y a pas d’autres cochonneries installées (selon l’analyse citée ci-dessus). Il faudra par contre mettre à jour ton système car le truc a réussi un root privilege escalation donc tu dois avoir une faille dans un des binaires de ton système.
Normalement, ce qui est préconisé c’est de refaire en entier ton serveur. Mais bon là cela ne semble pas nécessaire. Tu peut utiliser un scanner de rootkit (
tiger, chkrootkit, rkhunter) pour chercher d’autres failles.
Je suis surpris quand même de trouver un malware sur un logiciel qui n’est pas mainstream. Ce n’est pas courant.
Merci Sylvain pour tes retours. Depuis, j’ai shooté la machine, une VM chez Gandi avec une version de l’OS trop vieille, et j’ai pris une machine dédiée chez un autre hébergeur, en prenant soin de mieux sécuriser le serveur.