Introduction

Dans cet article, nous allons voir comment mettre en place une architecture avec différents services et applications Web à l’aide de Proxmox sur un serveur dédié kimsufi. Le but de cet architecture est multiple, il peut vous servir de « lab » afin de tester des développements et des solutions, ou alors d’héberger simplement plusieurs services Web.

Partons déjà du commencement, qu’est-ce que Proxmox? Il s’agit d’un outil  qui permet la gestion de la virtualisation et de la conteneurisation, il sera donc parfait pour déployer une architecture cohérente et complète à l’aide de toutes les fonctionnalités embarquées dans la solution (gestion de backup, firewall, réseau, etc…).

Pour plus de détails sur les concepts de virtualisation et de conteneurisation, je vous renvoie sur un article précédent qui présentait ces notions avec l’outil Docker : Introduction à Docker

Idem, pour un approfondissement de l’outil Proxmox, je vous renvoie sur le site officiel : https://www.proxmox.com/en/

Update : Ce tutoriel a été réalisé avec la version 5.2 de Proxmox, si vous utilisez une version différente, il est possible qu’il y ait des adaptations à faire sur votre environnement (le principe de l’architecture devrait rester valide).

La cible de l’architecture

L’architecture cible simplifié ressemble au graphique ci-dessous.

Comme les serveurs kimsufi d’OVH ne propose qu’une seule adresse IP publique, il est nécessaire de passer par une étape de routage en interne à Proxmox à l’aide d’une modification de l’iptable.

Le principe global sera le suivant, une requête HTTP sera envoyée depuis un client Web vers l’adresse publique qui transfère cette dernière au serveur nginx, ce dernier va servir de reverse proxy afin d’aiguiller la requête vers le bon service en fonction du nom de domaine soumis par la requête du client. Ensuite la réponse du service passera par la passerelle (serveur proxmox).

Nous allons détailler dans cet article les étapes pour arriver à ce résultat avec une architecture sécurisée et robuste.

Etape 1 : Création du serveur dédié

Depuis votre interface de gestion du serveur dédié de la plateforme kimsufi, il faut lancer la création du serveur en utilisant le gabarit de Proxmox PVE (64 bits), vous pouvez laisser les options par défaut.

Après le lancement de l’installation, il faut attendre le message de confirmation de la livraison du serveur par OVH.

Etape 2 : Sécuriser son serveur Proxmox

Le serveur Proxmox est directement accessible depuis l’Internet, il faut donc effectuer quelques opérations pour mettre en place un minimum de sécurité.

Pour commencer, avant de sécuriser le serveur, pensez à le mettre à jour :

Principe 1 : changer le mot de passe de l’utilisateur « root »

En effet, le mot de passe de l’utilisateur vous a été envoyé par mail, une bonne pratique serait de le changer immédiatement.

Pour changer votre mot de passe sur le serveur, connectez vous en SSH avec l’utilisateur « root », puis lancer la commande :

Principe 2 : ne pas se connecter avec l’utilisateur « root »

En effet, la première faille de sécurité serait de se connecter avec l’utilisateur root qui dispose de tous les droits sur le serveur. La première chose à faire est donc de créer un utilisateur personnalisé, cela possède 2 avantages en terme de sécurité :

  • il faut d’abord deviner le nom de l’utilisateur qui est différent de root
  • les droits par défaut sont limités et il est nécessaire ensuite de disposer du mot de passe root pour effectuer des actions sensibles

La génération d’une paire de clés SSH ne fait pas partie du cadre de cet article, cette notion sera éventuellement traitée ultérieurement.

Il faut ensuite, modifier le comportement de sudo :

Principe 3 : sécuriser SSH

Afin de renforcer la sécurité de SSH, nous pouvons effectuer 2 actions :

  • interdire tout simplement la connexion avec l’utilisateur root (le seul moyen serait de le faire à travers la console de Proxmox
  • changer le port d’écoute de SSH, par défaut SSH écoute sur le port 22, modifier ce port rendra la tâche un peu plus compliqué aux attaquants, il faudrait en effet scanner les ports du serveur (ce qui n’est pas effectué par tous les assaillants). Vous pouvez donc modifier le port de SSH (mettez un port supérieur à 1024)

Voici les actions à faire pour réaliser cette partie :

nano /etc/ssh/sshd_config

Principe 4 : Bannir les IPs attaquantes

Avec l’aide du paquet fail2ban, vous pouvez bannir les attaquants en cas de multiples mauvaises connexions. Ceci permettra le serveur de se protéger des attaques de type « Brute force ».

Avec cette configuration, au bout de 6 échecs, l’IP sera bannie pendant une durée (par défaut) de 3600 secondes soit 1h. N’hésitez pas à aller voir la configuration de fail2ban pour le personnaliser plus en détails : https://www.fail2ban.org/wiki/index.php/Main_Page.

Principe 5 : Restreindre l’accès à l’interface Web de Proxmox

Il est possible de restreindre l’accès à l’interface Web de Proxmox via un proxy.

Attention, l’activation de cette configuration bloque l’accès à l’interface Web depuis l’Internet, il faudra donc prévoir un moyen de se connecter à travers l’hôte ou de son sous-réseau (voir plus bas)

Voici enfin, la configuration à réaliser :

Afin de pouvoir se connecter à l’interface d’administration de Proxmox, il faudra donc au choix :

  • Utiliser un tunnel SSH depuis l’hôte (utilisable tout de suite). Pour cela, effectuer une connexion depuis Putty, par exemple et mapper un port local de votre ordinateur à celui de Proxmox.
  • Utiliser un service VPN dans le sous-réseau de Proxmox (à faire éventuellement plus tard)

Etape 3 : Création du réseau

La création du réseau s’effectue à travers l’interface d’administration de Proxmox. Pour accéder à la configuration, sélectionner le noeud (sous Datacenter) –> dans le panneau sélectionner « Réseau ».

Ensuite, créer un réseau « Linux Bridge » de la manière suivante :

Cela nous permet de définir le nouveau sous-réseau avec l’IP que nous allons attribuer à notre hôte, dans cet exemple 192.168.0.1

Une fois cette configuration effectuée, il faut redémarrer la machine pour que les modifications soient effectives.

Etape 4 : Création du serveur nginx

Nous allons basé notre serveur nginx sur un conteneur Ubuntu 18.04 LTS. Nous allons voir ensemble les différentes actions à mener pour y arriver.

Télécharger le template de conteneur

Un template de conteneur, va permettre d’initialiser un conteneur qui va pouvoir être utilisé au sein de notre outil Proxmox.

La gestion de ces templates ce conteneur se trouve via cette succession de liens : allez dans Datacenter –> votre noeud –> local –> puis dans le panel, sélectionnez « Contenu » –> bouton Templates.

Sélectionner le template ubuntu-18.04 et télécharger ce conteneur, comme le montre la capture ci-dessous :

Créer le conteneur pour nginx

Utiliser le bouton « Créer CT » en haut à droite de l’écran de Proxmox, renseigner ensuite les différentes informations demandées dans la partie « Général ».

Dans la section « Modèle » utiliser le template que nous avons téléchargé (ubuntu 18.04), pour les caractéristiques techniques du conteneur (taille disque, CPU, etc…) mettez les valeurs que vous jugez adéquats selon votre infrastructure et enfin configurer la partie réseau comme suit :

Avec cette configuration, nous avons terminé le paramétrage du conteneur, vous pouvez confirmer vos valeurs et démarrer ce conteneur.

Etape 5 : Configuration du routage de l’hôte

Dans cette partie, nous allons configurer le routage au sein de notre hôte pour que toutes les requêtes qui arrivent sur les ports 80 et 443 soient redirigés sur le conteneur nginx. Pour rappel, ceci est nécessaire car un serveur dédié kimsufi ne peut disposer que d’une seule adresse IP publique.

Afin d’arriver à nos fins, nous devons configurer cela au sein de l’iptable de notre serveur Proxmox, voici les éléments à réaliser en ligne de commandes :

Etape 6 : Configurer le conteneur nginx  en tant que reverse proxy

A l’aide d’une console sur votre conteneur, installer nginx :

La configuration de nginx s’effectue à l’aide des fichiers suivants :

  • le fichier /etc/nginx/nginx.conf 
  • les fichiers situés dans le dossier /etc/nginx/sites-enabled/

Dans le fichier /etc/nginx/nginx.conf, nous allons garder globalement le paramétrage par défaut, vous pouvez tout de même effectuer les ajustements suivants :

Il est également possible de séparer la configuration dans des fichiers qui peuvent être ensuite inclus dans des configurations ultérieures.

Vous pouvez créer le fichier /etc/nginx/proxy.conf et y ajouter le contenu suivant : 

Ce contenu, va permettre de définir la configuration du reverse proxy et de l’utiliser lors de la définition d’un nouveau service/site.

Etape 7 : le test

Pour tester le fonctionnement de l’ensemble de l’architecture, nous allons monter deux sites exemples :

  • 192.168.0.3 –> nom DNS : site1.devx
  • 192.168.0.4 –> nom DNS : site2.devx

Configuration dans nginx

Afin de séparer la configuration des différents sites et de garder une configuration « propre », chaque site aura sa configuration dans un fichier dédié situé dans le dossier /etc/nginx/sites-available/

Nous allons maintenant créer le fichier /etc/nginx/sites-available/site1.devx, avec le contenu suivant :

Répéter cela avec un deuxième fichier /etc/nginx/sites-available/site2.devx, en modifiant le nom de domaine du site et l’adresse IP.

Nous verrons plus loin, comment sécuriser cela en mettant en place un certificat SSL, pour l’instant, restons simple.

Pour activer cette configuration, il faut encore réaliser les actions suivantes :

Création des 2 conteneurs

Pour réaliser cette action rapidement, nous allons créer 2 conteneurs en réutilisant le template que nous avions utilisé pour nginx. Reproduisez donc simplement cette étape 2 fois en adaptant les adresses IP.

Pour chaque conteneur, nous allons installer Apache qui va servir nos fichiers avec la commande suivante :

Nous allons modifier le contenu du fichier par défaut qui est servi par Apache afin de différencier facilement où l’on se trouve.

Dans le fichier /var/www/html/index.html :

Modifier vos vhosts

Si vous avez configurer les noms de domaines avec des informations réelles, vous n’avez pas besoin d’effectuer cette étape, par contre si vous avez utiliser des noms de domaines de tests comme dans cet exemple, il va falloir adapter votre fichier vhost de votre ordinateur afin que nous puissions contacter le serveur dédié avec le nom fictif.

Dans le cadre de cet article, nous allons rajouter 2 entrées dans le fichiers vhosts :

  • <VERS_IP_PUBLIQUE> site1.devx
  • <VERS_IP_PUBLIQUE> site2.devx

Enfin le test!

Pour tester, il suffit depuis votre navigateur Web d’accéder aux adresses suivantes http://site1.devx et http://site2.devx.

Si vous avez des résultats différents sur les 2 pages et sans erreur, alors notre architecture est fonctionnelle!!

Bien évidemment, nous avons simulé un exemple très simple, dans la vraie vie, vous pouvez définir une suite plus complexe à cette architecture, par exemple :

  • mettre en place une base de données avec un conteneur qui va servir les données des différentes applications,
  • mettre en place un serveur VPN pour accéder à votre sous-réseau qui fait office de lab
  • augmenter la sécurité avec un firewall plus poussé
  • gérer de la répartition de charge (loadbalancing)
  • etc…

Une petit dose de Https avec let’s encrypt pour finir!

A ce stade, notre architecture est fonctionnelle, mais pas encore très sécurisée. En effet, notre reverse proxy nginx utilise le protocole http qui n’est pas sécurisé, nous allons voir maintenant comment sécuriser cet aspect à l’aide de let’s encrypt.

Cette partie était un peu rapide, retenez simplement pour l’instant le principe de let’s encrypt. Il s’agit d’une autorité de certification qui permet de mettre en place facilement le protocole https. Afin d’y arriver, let’s encrypt vérifie simplement que vous avez les droits de gestion sur le serveur où le certificat a été demandé.

Catégories : Informatique

8 commentaires

ilou · avril 27, 2019 à 5:31

Bonjour,

Avez vous testé cette solution avec proxmox 5.2 ou supérieur ?

    Vincent · juin 3, 2019 à 7:44

    Bonjour,

    Oui pour ma part, j’ai utilisé la version Proxmox 5.2 (je vais rajouter cette information dans l’article).

    Merci de m’avoir signalé cet oubli.

    Vincent.

Robby · juin 2, 2019 à 2:06

Joli tuto mais impossible à réaliser en réalité. Ne pas se sentir nul car c’est truffé d’erreurs. La partie réseau (la plus importante) n’est pas bonne, à commencer par la configuration du brigde.

Dommage, tuto sympa pourtant…

    Robby · juin 2, 2019 à 2:10

    Autant pour moi, configuration différente dans ma version de Proxmox (5.4-6).
    Merci pour ce tuto !

      Vincent · juin 3, 2019 à 7:52

      Bonjour,

      Pas de soucis pour le tuto c’est avec plaisir si cela peut aider du monde :-). Le tuto devrait être fonctionnel car je l’ai rédigé en parallèle de mes tests.

      Effectivement avec une version plus récente de Proxmox, la configuration peut changer mais le principe lui devrait être toujours valide.

      Je vais préciser la version utilisée dans ce tuto pour éviter que cette erreur survienne à nouveau.

      Merci pour le retour!

Sylvain · juillet 17, 2019 à 2:48

Bonjour,

Je cherchais depuis de longues heures où mettre les certificats.

1 – Installation de Proxmox 5.4-11
2 – Création CT Nginx pour le proxy (pour renvoie des sites sur chaque CT différent
3 – Création des CT des sites (avec Nginx, PHP, etc…)
4 – Ben c’est là que je bloquais 😛
==> Dans le CT du point 2, création des certificats par URL
6 – Si je comprends bien, Dans le Proxy, renvoie sur https://site1.devx par exemple, Avec revois du proxy vers IP_du_CT:80
Et dans la config Nginx, on gère le certificat, mais pas dans le CT de site1.devx ?

Voilou

Merci beaucoup
Bien cordialement
Sylvain

    Vincent · juillet 17, 2019 à 4:23

    Bonjour,

    Vous avez tout à fait compris, dans l’exemple, effectivement le proxy écoute sur https://site1.devx et renvoie en interne vers IP_du_CT:80.

    Au niveau du certificat, il est présent sur le reverse proxy car c’est lui qui est en frontal.

    Ce n’est pas dans ce tutoriel, mais il est également possible de mettre un certificat auto-signé sur vos CT internes.

    Merci pour votre lecture,
    Vincent.

Proxmox V5 – Ilouvatar.net · avril 27, 2019 à 4:54

[…] cru comprendre le contraire en lisant cet article mais je n’ai pas encore eu l’occasion de la […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.