Quelques techniques de sioux pour sécuriser un hôte Proxmox VE

Maintenant que ma nouvelle installation de Proxmox VE tourne à merveille suite aux déboires que j’ai pu avoir chez mon ancien prestataire, je vais vous dévoiler quelques-unes de mes techniques de sioux pour sécuriser un peu plus un hôte Proxmox, car en configuration par défaut ce n’est pas très excitant. Ces quelques billes ne transformeront pas votre hôte en forteresse inviolable, mais il sera déjà un peu plus blindé ! 😁

Sécuriser SSH

Un petit tour dans /etc/ssh/sshd_config rapidement, et on va procéder au changement de quelques paramètres, tout d’abord le port par défaut sur lequel SSH écoute. Le 22 étant le port par défaut, on va le changer. Naturellement, on évitera de mettre un port qui est déjà utilisé pour une autre application ou qui pourrait être bloqué par un éventuel pare-feu. Ensuite, l’option PermitRootLogin ne doit surtout pas être à yes mais à without-password, prohibit-password ou à no. Les deux premières options peuvent être utilisées avec des clefs SSH, tandis que la dernière bloquera complètement le login en root, forçant un su une fois la connexion avec un utilisateur standard établie.

Rejeter les tentatives de connexion avec une autre IP

Dans /etc/hosts.allow, on va pouvoir définir les adresses IP qui sont autorisées à communiquer avec certains services installés sur la machine. Il peut être judicieux de rejeter les connexions SSH sur toutes les IP sauf une. Par exemple, celle d’un VPN et éventuellement d’une de vos machines virtuelles si vous avez une VM dédiée à l’administration.

Dans cet exemple, je n’autorise qu’une IP à se connecter et je bloque toutes les autres.

sshd : 192.168.1.2 : allow
sshd : all : deny

Autoriser l’accès à l’interface web de Proxmox uniquement sur une adresse ou un range d’IP

Par défaut, l’interface web de Proxmox est accessible sur le port 8006 pour tout le réseau internet. Le moteur web étant basé sur Apache, il est possible d’appliquer des règles allow et deny toutes simples pour n’autoriser l’accès à l’interface web que sur les IP que l’on souhaite. Ici aussi, utiliser un VPN peut s’avérer utile car on déplace derrière une authentification supplémentaire le portail web.

On édite avec nano le fichier /etc/default/pveproxy, puis on saisit les IP qu’on souhaite autoriser ou refuser comme ceci :

ALLOW_FROM= »192.168.1.2,192.168.2.12″
DENY_FROM= »all »

POLICY= »allow »

Un redémarrage de l’interface web est nécessaire :

pveproxy restart

Installer fail2ban

fail2ban est une application tournant en tâche de fond qui écoute les divers logs système et applicatifs et repère les tentatives de brute-force et place en cas d’échecs répétés de connexion les IP dans les règles de rejet du pare-feu ; en conséquence, toutes les IP (ou plage) voient leurs connexions rejetées pendant un certain laps de temps durant la configuration. Celle par défaut suffit normalement pour le peu de services qui sont en théorie installés sur l’hôte.

apt install fail2ban

Le fichier de configuration le plus intéressant est /etc/fail2ban/jail.conf car c’est ici que l’on peut éventuellement ajouter des services à monitorer.

En dehors de ces astuces, je ne saurai que conseiller de créer des utilisateurs avec le minimum de privilège par VM, créer un compte pour l’administration du datastore, et de passer par un VPN pour vous connecter en SSH ou en web. Vous pouvez trouver plus de documentation sur ces liens concernant fail2ban, pveproxy et sshd_config.

Migration des VM d’un hôte Proxmox VE vers un autre hôte sans cluster

Suite à des déboires par rapport à l’hébergeur de mon serveur, j’ai fini par revenir chez OVH chez qui j’ai toujours été satisfait. Sur ce nouveau serveur, j’ai donc rempilé pour la même distribution que l’ancien, un Proxmox VE 5 sur base de Debian 9, pour des raisons de compatibilité principalement, et aussi car j’étais satisfait de cet hyperviseur après quelques années sous ESXi.

Le principal intérêt étant la possibilité de conserver les machines virtuelles et ne rien avoir à réinstaller à part l’hyperviseur lui-même et refaire la configuration (ou plutôt, la redéployer étant donné que j’avais tout sauvegardé), je vais expliquer dans cet article comment procéder à l’export et à l’importation des VM de l’ancien hôte vers le nouveau.

Sur l’interface de Proxmox, sélectionner la machine virtuelle que l’on souhaite sauvegarder, puis aller dans Backup, et enfin, cliquer sur Backup Now. Si le datastore est invisible, il faut activer le stockage de fichiers de sauvegarde dessus (Datacenter > Storage > Edit > Content, cocher VZDump backup file).

La fenêtre de sauvegarde d’une VM. Il faut choisir le datastore sur lequel écrire la sauvegarde, le mode (snapshot, mise en veille de la VM ou arrêt complet) et enfin, spécifier si l’on souhaite une compression de celle-ci et/ou un mail.

Un snapshot n’étant pas suffisant pour restaurer une VM sur un autre hôte sans cluster, il faut donc soit mettre en sommeil la VM le temps de la sauvegarde (option Suspend) ou l’arrêter complètement (option Stop). Dans mon cas, le mode Suspend suffit ; j’ai choisi une compression LZO pour réduire le temps de transfert vers l’autre hyperviseur.

Il se peut que la sauvegarde échoue : le message d’erreur est généralement assez clair, mais s’assurer qu’il ne reste pas un ISO de monté et inaccessible ou que la VM n’est pas en cours d’extinction déjà est un début.

Un écran apparaît alors permettant de suivre le déroulement de la sauvegarde, en fonction de la taille de la machine, de vos performances CPU et disque, il n’y a pas de vrai moyen de déterminer le temps que cela peut prendre. A titre d’exemple, une sauvegarde d’une VM avec un seul disque virtuel contenant environ 65 Go de données s’est terminée en environ 15 minutes (CPU Core i7-4770, 32 Go de RAM, disques SATA 10K).

Une fois la sauvegarde terminée, il va s’agir de la transférer. Le moyen présentant le meilleur ratio simplicité/sécurité est d’utiliser SCP. Dans un shell, nous allons donc nous placer dans le répertoire des dumps, identifier le fichier de sauvegarde, puis lancer le transfert SCP.

cd /var/lib/vz/dump/
ls

La sauvegarde est donc au format .vma.lzo puisque l’on a décidé de compresser en LZO. En cas de doute un ls -l affiche la taille, permettant de différencier le log de la sauvegarde elle-même.

Reste plus qu’à lancer le SCP :

scp vzdump-qemu-machineidtime_stamp.vma.lzo user@destination:/var/lib/vz/dump/vzdump-qemu-machineidtime_stamp.vma.lzo

A noter que machineid et time_stamp sont des variables qui changent naturellement en fonction de l’ID de la VM et de l’heure à laquelle la sauvegarde a commencé ; on utilisera bien sûr le nom récupéré plus haut. scp utilisant SSH, il peut être nécessaire de préciser le port sur lequel écoute SSH sur le serveur de destination (scp -P 2222 par exemple, si le port SSH est 2222). Il faut également que l’utilisateur spécifié soit en mesure d’écrire dans le répertoire de destination. Vous pouvez faire le transfert vers un homedirectory avec un utilisateur tout simple puis ensuite déplacer la sauvegarde vers le répertoire des dumps.

Le temps de transfert dépendant quasi-uniquement de la bande passante entre les deux hôtes, impossible de prédire celui-ci. Une fois le transfert terminé, sur le nouveau Proxmox, il suffit de se rendre sur les propriétés du datastore pour permettre de gérer les sauvegardes si cela n’est pas déjà fait  (éventuellement déjà opéré sur l’hôte d’origine pour faire les sauvegardes) :

En cochant VZDump backup file, on permet au datastore de gérer les fichiers dumps.

Puis, en se rendant dans le datastore lui-même, on aperçoit bien notre backup :

Il ne reste plus qu’à le sélectionner, cliquer sur Restore, indiquer un ID de machine virtuelle libre sur le nouvel hôte et le datastore de stockage. Puis au redémarrage, tout sera comme à l’extinction sur l’ancien hôte 😎

Si l’envie vous prend de réaliser tout en ligne de commande ou que vous ne pouvez pas utiliser l’interface web, je vous renvoie vers la documentation de vzdump et qmrestore.

Montage d’un NAS sur une machine virtuelle Debian distante

J’ai franchi le pas récemment en achetant un NAS pour sauvegarder à la maison mes documents personnels et du contenu multimédia en tout genre. En plus d’utiliser Google Drive avec Plex (voir cet article), j’ai décidé de monter un troisième serveur Plex sous Debian Stretch pour y décoder le multimédia qui provient de mon NAS directement. Afin que le NAS à la maison soit accessible sur mon Plex qui est une machine virtuelle située en dehors de mon réseau local, je vais utiliser Samba – intégré à mon NAS – et faire un peu de routage sur ma Livebox.

Tout d’abord, satisfaire les prérequis en termes de paquets sur la machine :

adduser <sambaplex>
apt-get install cifs-utils

Je me servirai du dossier home de l’utilisateur sambaplex pour y monter mon NAS afin de le séparer du répertoire de l’utilisateur courant. Etant donné que sur le serveur nous n’allons pas héberger un partage mais seulement en monter un, il n’y a pas besoin d’installer tous les paquets de samba.

Ensuite, il faut paramétrer la box qui fait office de routeur à la maison. Dans mon cas, ayant une IP dynamique, j’ai dû faire appel à un service externe nommé No-IP qui permet de souscrire gratuitement (avec une offre payante) à un nom de domaine que je prolongerai tous les mois ; ce service est géré par ma box grâce à l’API, ce qui signifie que dès que mon IP change, l’adresse que renvoie mon nom de domaine change aussi. Cela évite d’avoir à remonter le partage sur le serveur dès que l’IP change et de pouvoir communiquer avec un nom, ce qui est plus pratique.

Je configure ici mon service de DNS dynamique ; sur la Livebox plusieurs prestataires sont disponibles

Ensuite, il est nécessaire de procéder à l’ouverture des ports dans le pare-feu, et également de NATer ceux-ci afin que le trafic puisse rentrer et sortir proprement. 5 ports sont nécessaires pour que toutes les fonctionnalités soient accessibles :

Je route les ports 135, 137 et 445 en TCP/UDP, 138 en UDP et 139 en TCP vers le NAS

Par précaution, j’ai également procédé à la création d’un bail DHCP permanent pour le NAS afin qu’il ne change pas d’adresse IP locale en cas de redémarrage ou de perte de connexion. Une fois que tout est prêt côté « maison », il ne reste plus qu’à monter le partage samba du NAS sur le serveur distant grâce à cette commande exécutée en root :

mount -t cifs //<nas.domain>/<share> /home/sambaplex -o username=<nasuser>

Il sera alors demandé le mot de passe du compte nasuser qui devra avoir les droits en lecture sur le share que l’on souhaite monter.

Si l’on souhaite démonter le share, rien de plus simple :

umount /home/sambaplex

Désormais je peux ajouter mon contenu sur ce serveur Plex comme si il était localement sur la machine virtuelle, chaque appel aux fichiers passant par Samba – et nécessitant de ce fait, une bonne bande passante étant donné que tout transite du NAS à la maison vers la machine virtuelle.

Mise à jour de Debian Jessie (8.x) vers Stretch (9.0)

Il y a un peu plus d’un mois, Debian Stretch pointait le bout de son nez pour succéder à Jessie sortie en 2015. Bien que Jessie soit supportée jusqu’en 2020, j’ai décidé de mettre à jour par curiosité ma machine Debian virtuelle qui me sert de bureau internet.

Je vais donc mettre à jour ma Debian 8.8 avec un environnement graphique MATE vers 9.0. Cela n’est pas très difficile, mais je vais détailler les étapes nécessaires à la mise à jour, que cela concerne un système avec environnement graphique ou non. Je vous renvoie vers ce lien si vous souhaitez avoir plus de détails sur ce qui change avec Stretch.

Bien entendu, avant une telle mise à jour, il est de bon ton de sauvegarder ses données, ses fichiers de configuration et bien vérifier la compatibilité de certaines applications ou librairies. Dans mon cas, cette machine n’étant qu’un petit bureau avec un navigateur et quelques applis, comme un PC domestique.

Tout d’abord, mettre à jour les paquets pour être sûr de partir sur les derniers paquets disponibles pour Debian 8.

apt-get update && apt-get upgrade

Si tous les paquets sont à jour, on doit se trouver sur une version 8.8 : une vérification ne fait pas de mal :

cat /etc/debian_version

Ensuite, avec un éditeur de texte, il va falloir éditer le fichier sources.list après en avoir fait une copie.

cp /etc/apt/sources.list /etc/apt/sources.list.old
nano /etc/apt/sources.list  

Cela devrait donner quelque chose ayant cette forme, avec plus ou moins de lignes évidemment en fonction des dépôts qui ont été ajoutés dans ce fichier (ils peuvent également être dans d’autres répertoires). Chaque ligne correspondant à un dépôt qui est interrogé par le système en cas de requête de mise à jour de paquet. On va donc procéder à la modification de Jessie en Stretch afin que le système aille chercher les paquets pour Stretch et plus pour Jessie.

De Jessie…
… vers Stretch

Ensuite, on relance une mise à jour pour redescendre les paquets Stretch et mettre à niveau vers 9.0 !

apt-get update && apt-get dist-upgrade
reboot
 

Et enfin, après un redémarrage, on peut de nouveau profiter du système avec quelques changements cosmétiques visibles dès l’écran de connexion.