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 :

apt update && sudo apt-upgrade -y

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 :

passwd

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

# création de l'utilisateur
useradd -m USERNAME
# création du mot de passe
passwd USERNAME
# rajouter l'utilisateur dans le groupe sudo (nécessaire pour lancer les commandes sensibles)
<span>gpasswd -a USERNAME sudo</span>
# si vous souhaitez utiliser des clés SSHS, il faut créer le dossier 
# et le fichier adéquat pour y placer vos clés publiques avec des droits adaptés
mkdir /home/USERNAME/.ssh && touch /home/USERNAME/.ssh/authorized_keys && chmod 600 /home/USERNAME/.ssh/authorized_keys

# Si cela a été fait avec le compte, ne pas oublier de modifier le propriétaire du fichier
chown USERNAME:USERNAME /home/USERNAME/.ssh/authorized_keys

# Placer ensuite le contenu de vos clés publiques SSH dans ce fichier

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 :

# si sudo n'est pas installé
apt install sudo

# Modifier le comportement de sudo
visudo

# Insérer ensuite la ligne suivante dans le fichier
# Cette ligne force de taper le mot de passe utilisateur à chaque élévation de pouvoir
Defaults rootpw,timestamp_timeout=0

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

# Editer le fichier de configuration de SSH
nano /etc/ssh/sshd_config

# Modifier ensuite les lignes suivantes du fichier 
Port NOUVEAU_PORT
PermitRootLogin no

# Relancer ensuite le service SSH
service ssh restart

# Si vous étiez toujours connecté avec l'utilisateur root, déconnectez-vous

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

# Installation du paquet
sudo apt install fail2ban -y

# Copier le fichier de config de la distributiuon pour y mettre nos règles personnalisées
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Mofidier ensuite le fichier de configuration local de fail2ban
sudo nano /etc/fail2ban/jail.local

# Placer le contenu suivant en fin de fichier pour configurer le bannissement sur SSH
# attention ne pas oublier de mettre votre nouveau port SSH

#### Configuration personnalisée du serveur
[ssh]

enabled = true
port    = ssh,sftp,NOUVEAU_PORT_SSH
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

# Relancer le client fail2ban avec la nouvelle configuration
sudo fail2ban-client reload

# Vérifier le fonctionnement
sudo fail2ban-client status

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 :

# Création du fichier de configuration pour restreindre l'accès à l'interface Web de Proxmox
sudo touch /etc/default/pveproxy
# Modifier le fichier
sudo nano /etc/default/pveproxy

# Insérer le contenu suivant
ALLOW_FROM="127.0.0.1,192.168.0.0/22"
DENY_FROM="all"
POLICY="allow"

# Relancer le service
sudo service pveproxy restart

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 :

# 1ere étape, nous allons donner l'accès à Internet au sous-réseau, afin que les conteneurs et VM puissent accéder à Internet
iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o vmbr0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

# 2eme étape, nous allons redirigé le traffic entrant port 80/443 sur notre conteneur nginx
iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 192.168.0.2:80
iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 192.168.0.2:443

# Vous pouvez ajouter des redirections sur d'autres ports personnalisés si vous en avez le besoin

# Vous pouvez également afficher l'ensemble des règles de routage avec la commande suivante
iptables -t nat --line-numbers -L

# Pour supprimer une ligne de la table de routage
iptables -t nat -D PREROUTING <LINE_NUMBER>

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

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

apt install 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 :

# Utilisation en priorité de la version 1.2 du protocole (la plus sécurisée pour le moment)
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

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 : 

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 900s;

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 :

server {
    listen 80;
    listen [::]:80;
    server_name site1.devx www.site1.devx;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    location / {
       include proxy.conf;
       proxy_pass http://192.168.0.3:80/;
    }
}

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 d'un lien symbolique dans le dossier où nginx va chercher sa configuration de sites
ln -s /etc/nginx/sites-available/site1.devx /etc/nginx/sites-enabled/site1.devx
ln -s /etc/nginx/sites-available/site2.devx /etc/nginx/sites-enabled/site2.devx

# Redémarrage du service nginx pour la prise en compte de la nouvelle configuration
service nginx restart

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 :

apt install apache2 -y

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 :

<!-- Mettez le contenu suivant pour le site 1 -->
<html><body>Le site 1</body></html>

<!-- Mettez le contenu suivant pour le site 2 -->
<html><body>Le site 2</body></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.

# Installation de certbot
sudo apt install certbot -y
# Installation du paquet pour la prise en charge avec nginx
sudo apt install python-certbot-nginx -y

# Demander un certificat à let's encrypt pour les noms de domaines
sudo certbot --nginx -d site1.devx -d www.site1.devx -d site2.devx -d www.site2.devx
# Poursuivez l'installation du certificat, le certbot va modifier automatiquement la
# configuration de nginx

# Activez la prise en charge du certificat
sudo service nginx reload

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