Nginx et SSL

Nous voici sur le troisième et dernier sujet de la mini série consacrée à la gestion d’un serveur : Le reverse proxy avec sa gestion de l’HTTPS pour héberger des applications.

C’est un article qui sera volontairement long car il y a énormément de choses à voir (en théorie et en pratique).

Maintenant que notre serveur est sécurisé et que les sauvegardes sont en place, on peut s’attaquer à la partie opérationnelle : faire tourner des applications.

Il existe plusieurs types de serveurs web, chacun adapté à un type de technologie, on peut citer en exemple :

• Apache : idéal pour les applications PHP classiques.

• Nginx : très performant pour servir des fichiers statiques (HTML, CSS, JS) et souvent utilisé comme reverse proxy.

• Gunicorn : serveur d'application Python (par exemple pour Flask ou Django), utilisé derrière un reverse proxy comme Nginx.

Pour qu’un serveur sache vers quelle application diriger une requête, deux méthodes sont possibles :

• en fonction du port (ex : monsite.fr:5000)

• en fonction du nom de domaine ou sous-domaine (ex : blog.monserveur.fr)

Partie Théorique

Pour illustrer, on va prendre les bases d’une requête HTTP avec Billy.

ça c’est Billy.

Dis bonjour à Billy

Billy à besoin d’aller sur mon-site.com, du coup il tape dans sa barre de recherche … “mon-site.com” (pffiouuuu c’était intense le suspense là !)

Sa requête sort de chez lui (réseau local) par l’intermédiaire de sa box

Sa box consulte l’immense répertoire de sites web grâce aux entrées DNS enregistrées (Domain Name System) puis elle sait que mon-site.com correspond à l’ip 87.209.255.150.

La box achemine alors la requête “mon-site.com” vers l’ip 87.209.255.150 qui est l’adresse de destination de mon-site.com et qui correspond au serveur hébergeur du site.

Le serveur consulte son serveur web (apache dans notre cas) puis il fait le chemin inverse pour distribuer la page à afficher à Billy.

C’est un concept simplifié d’une requête HTTP mais qui parle bien.

Un serveur (comme ici 87.209.255.150) peut héberger plusieurs sites ou applications à la fois, dans la limite de ses ressources (processeur, RAM, stockage). Cependant, gérer différentes technologies via Apache peut vite devenir compliqué, surtout si on sort du cadre PHP. Par exemple, si je veux héberger une application en Node.js, Apache n’est pas conçu pour la gérer directement, alors on utilisera Nginx, et si je veux du python, alors on utilisera encore un autre serveur …

Chaque application écoute généralement sur un port différent en local (par exemple 8000, 8001, 6000), mais ouvrir tous ces ports vers l’extérieur augmente la surface d’attaque. Pour éviter cela, on les laisse accessibles uniquement en interne (localhost), et on n’expose au public que les ports 80 et 443 via un reverse proxy.

Ce reverse proxy centralise l’accès, achemine les requêtes vers la bonne application, et gère le HTTPS.

En bref, c’est la porte d’entrée principale de ton infrastructure.

Tu n’as besoin que d’ouvrir tes ports web “classique” : 80 et 443.

Le port 80 c’est quand tu tape une url avec http:// et le 443 c’est son grand frère sécurisé https://.

Mais si tu tapes 443, comment le serveur sait qu’il doit aller chercher ton application sur le port 6000 ? Et bien c’est le reverse proxy qui va le lui dire ! C’est lui qui dit qu’est ce qu'il faut faire !

C’est là qu’intervient Nginx en tant que reverse proxy.

Pour notre article, il joue le rôle d’un serveur de restaurant :

• Il prend les commandes de Billy (mon-site.com)

• Il les transmet à la bonne "cuisine" (soit Apache pour un site PHP, soit un serveur Node.js pour une application JavaScript…).

• Il ne montre jamais les cuisines (les ports) à Billy.

Nginx présente le 80 et le 443 mais lui se balade librement dans le serveur (localhost), c’est donc top. On réduit la surface d’attaque et on centralise les fonctionnalités vers le reverse proxy.

Il pourra également jouer le rôle de videur de bar de nuit puisqu’avec Nginx on peut restreindre l’accès à des sites grâce à des règles d’IPs, l’utilisation de mots de passe etc …

Un vrai couteau suisse ce Nginx !

Sur le schéma ci-dessous on voit bien que l’on passe uniquement par le reverse proxy et son port 443 puis c’est lui redirige en fonction du site web sur lequel Billy veut aller (ici localhost:8000).

Dans l’exemple j’ai volontairement séparé les noms de domaine mais on peut imaginer que tous sont regroupés sur mon-site.com et qu’en fonction du chemin, on a accès à telle ou telle application :

• mon-site.com/contact ⇒ localhost:8000

• mon-site.com/faq ⇒ localhost:6000

C’est aussi Nginx qui va gérer les certificats SSL pour le HTTPS.

Pour la partie théorique je pense qu’on est pas mal.

On ne va pas gérer d’application NodeJS ou de serveur Web Apache aujourd’hui (ce n’est pas le sujet) mais on va se servir comme exemple de notre outil de monitoring vu dans la partie 2 qui est cockpit et qui tourne déjà en arrière plan.

Pour l’instant, Cockpit est accessible uniquement sur le port 9090 qui n’est pas ouvert à internet (UFW ne laisse pas passer le port 9090). C’est donc un parfait candidat pour notre exercice du jour.

Voila le schéma que l’on va tenter d’appliquer ensemble :

• Installation d’un nom de domaine (DynDNS car méthode de rat !)

• Installation et paramétrage de Nginx

• Paramétrage du SSL

Avec ça … tu pourras ensuite t’amuser à faire des applications auto-hébergées dans les technos de ton choix (PHP, JS, Python …) et on aura démystifié les noms de domaine et le SSL.

Partie Pratique

Installation d’un nom de domaine

Pour accéder à notre serveur on va avoir besoin d’un nom de domaine.

Pour ça 2 solutions :

• On achète un nom de domaine chez un Registrar (OVH, Gandi, Google etc …)

• On utilise un DynDNS (Dynamic DNS)

Pour l’article je n’avais pas envie d’acheter un nom de domaine (car je suis un gros rat) alors j’utiliserai les services d’un DynDNS. En tant normal on utilise ce service si on a une IP qui n’est pas fixe mais dans mon cas, c’est pour éviter d’acheter un nom de domaine.

Le service nous met à disposition un nom de domaine (avec un domaine imposé, c’est comme si on nous prêtait un sous-domaine d’un domaine finalement).

On installe un client sur notre machine qui contacte le service et ce service sait où se trouve l’IP du client, il met à jour l’IP dans sa base de données et sait ainsi où faire pointer le nom de domaine quand quelqu’un (une box internet) l’appellera.

On va utiliser https://desec.io/ et je te laisse aller te créer un compte dessus.

Ensuite tu enregistreras ton nom de domaine avec le petit “+” :

Ensuite met le nom que tu veux voir apparraitre avec .dedyn.io. Moi pour l’exemple ce sera : debiwan.dedyn.io

Rends toi ensuite dans TokenManagement puis crée toi un token et note précieusement le token, il te sera utile pour après (et tu ne pourras plus le ré-afficher sans le supprimer) !

OK on est bon pour la partie web de DeSEC. Maintenant on passe sur notre serveur.

On va ouvrir les ports 80 et 443 pour permettre de gérer la partie Web de notre serveur.

On fait ufw status pour voir nos ports ouverts (logiquement il n’y a que ton port SSH, réservé à ton IP)

Aucun autre port n’est ouvert, ça nous arrange pas, on va autoriser le web : ufw allow http && ufw allow https

Voila, avec ça on a déjà autorisé le web à communiquer avec nous.

Installons maintenant le client du DynDNS pour faire pointer le nom de domaine avec l’IP de notre serveur.

• apt install ddclient

• dans l’interface graphique, suis les instructions ci-dessous :

  • “other”

  • “other”

  • puis fais ok à toutes les autres questions.

Ensuite rends toi dans le fichier de configuration : nano /etc/ddclient.conf et remplace le contenu par la configuration préconisée de la documentation deSEC :

protocol=dyndns2
#daemon=600
use=cmd, cmd='curl https://checkipv4.dedyn.io/'
ssl=yes
server=update.dedyn.io
login=[ton domaine]
password='[token secret]'
[ton domaine]

De mon côté ça ressemble à ça :

Ensuite on va installer une librairie pour gérer le SSL. Sur Debian c’est : apt install libio-socket-ssl-perl

Une fois ok, on lance juste ddclient

Si la configuration est bonne, on a bien l’IP du serveur qui est envoyée à deSEC :

Partie nom de domaine : check !

On va installer Nginx et connecter Cockpit du port 9090 (qui dans notre partie 2 n’était pas accessible depuis le Web mais uniquement accessible avec du Port Forwarding). De cette façon, quand on tapera notre url https, on accède à notre interface cockpit.

Installation du Reverse Proxy

Pour le reverse proxy, on va prendre Nginx (il en existe d’autres, n’hésites pas à en tester d’autres) : apt install nginx.

Une fois installé, on a l’habitude, on doit l’activer : systemctl status nginx et on veut qu’il démarre tout seul à chaque redémarrage du serveur alors on fait la commande habituelle : `` systemctl enable nginx .

Si on fait un netstat -tulpn pour vérifier si il écoute bien sur le port 80 (pas 443 pour l’instant), on doit le voir dans la liste :

On est ok pour son activation et on voit qu’il écoute bien en 80.

Maintenant on tente d’accéder à une page : http://tonip ou maintenant http://tonnomdedomaine !

C’est bon ! Nginx est un reverse proxy mais aussi un serveur web (comme apache) donc il sert automatiquement un index.html et ça confirme son fonctionnement.

A présent étudions un petit peu l’arborescence de Nginx.

ça se passe dans /etc/nginx

• nginx.conf : c’est le fichier de configuration principal de Nginx. Il contient les directives globales (comme le nombre de connexions, les workers, les logs, etc.) et peut inclure d'autres fichiers de configuration via la directive include.

• conf.d/ : ce dossier contient les fichiers de configuration des serveurs virtuels (aussi appelés "virtual hosts"). On y place en général les fichiers .conf pour chaque site ou application. Ils sont automatiquement inclus si nginx.conf contient un include conf.d/*.conf.

• snippets/ : ce dossier contient des fragments réutilisables de configuration, comme des blocs SSL, des headers communs, etc. Ces snippets peuvent être inclus dans d'autres fichiers de configuration avec include snippets/mon-fichier.conf.

• sites-enabled/ et sites-available/ (présents surtout sur les distributions Debian/Ubuntu) :

  • sites-available/ contient les fichiers de configuration des sites web.

  • sites-enabled/ contient des liens symboliques vers les fichiers activés dans sites-available/.

    Ce mécanisme permet d'activer ou désactiver facilement des sites sans supprimer leurs configurations.

    Dans certaines installations, ce système n’est pas utilisé, et seul conf.d/ est exploité.

  Explorons un peu nginx.conf :

user www-data;
worker_processes auto;
pid /run/nginx.pid;
error_log /var/log/nginx/error.log;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

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

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

L’avantage des fichiers de configuration de Nginx c’est qu’ils sont bien commentés donc faciles à lire.

• error_log /var/log/nginx/error.log; permet de créer un fichier de log où on pourra voir toutes les erreurs liées à Nginx (super utile pour débug !!!).

• include /etc/nginx/modules-enabled/*.conf; c’est pour installer des extensions (appelées modules) qui peuvent être utiles dans certains cas (blocage GeoIP par exemple)

• Le bloc events {} permet de gérer le nombre de connexions que peut recevoir Nginx en simultané. C’est utile si ton site recevra beaucoup de trafic, mais dans notre cas on le laisse par défaut.

• Le bloc http {} c’est le bloc qui gère vraiment toute la partie importante : le reverse proxy.

Dans ce bloc on fait un peu pareil que le error.log mais pour le access.log (utile pour vérifier qui à accédé à quoi et quand).

Et on inclut également l’ensemble des confs de nos sites avec include /etc/nginx/conf.d/*.conf . De cette manière, on sépare nos configurations de sites par fichier (un site ⇒ un fichier), c’est plus lisible.

Ça tombe bien, on va en créer un. Si tu as plusieurs sites alors il faut t’imposer une rigueur dans la nomenclature de tes fichiers de conf. Je te conseille de mettre le nom de ton site en snakecase (nom_de_ton_site.conf). C’est parti !

nano /etc/nginx/conf.d/cockpit.conf

Pour la base de la base, on a besoin d’un bloc server {} qui sera le point d’entrée de notre configuration :

server {
    listen      80;
    server_name debiwan.dedyn.io;

    location / {
        proxy_pass http://localhost:9090;
    }
}

Dans ce bloc server, on indique à Nginx sur quel port il doit écouter et à quel site correspondra ce bloc (ici on indique notre site web cockpit).

Le location / c’est si je tape “debiwan.dedyn.io” alors on exécute le bloc (si je mets location /admin) alors j'aurais dû taper "debiwan.dedyn.io/admin" pour exécuter ce bloc.

Et ensuite le proxy_pass c’est le rôle du serveur de restaurant. Billy fait sa commande, le serveur l’envoi (proxy_pass) à localhost:9090.

On sauvegarde puis on teste la configuration avec nginx -t avant de redémarrer Nginx.

J’avais fais une erreur de frappe et nginx -t m’a permis de m’en rendre compte. J’ai corrigé avant de redémarrer sinon mon serveur aurait planté. D’où l’intérêt du nginx -t.

Afin que Nginx prenne en considération nos changements dans les fichiers de configuration, on le redémarre : service nginx restart.

On va sur notre navigateur et on recherche notre nom de domaine :

Tadaaaam !

Notre serveur autorise uniquement les connexions 80 (et non 9090) et pourtant on accède à Cockpit, c’est pas trop bien ?! c’est Nginx qui a distribué, une sorte de Port Forwarding pour le Web.

Etant donné que Cockpit est très sensible, on va éviter de le laisser en libre accès car tout le monde peut accéder maintenant à Cockpit puisque ufw autorise l’accès au 80.

On va filtrer notre IP via Nginx, on retourne alors dans notre fichier /etc/nginx/conf.d/cockpit.conf

server {
    listen      80;
    server_name cockpit.sith;
    allow tonipdecheztoi;
    deny all;

    location / {
        proxy_pass http://localhost:9090;
    }
}

On ajoute la ligne allow tonip pour autoriser ton accès et on refoule les autres à l’entrée avec deny all

Tu peux empiler des IPs comme ça à ta guise. Ou faire l’inverse, deny une ip précise et allow all (politique inversée).

Ensuite teste ta conf (nginx -t) et si c’est ok redémarre ton Nginx.

A présent pour tester, mets toi en partage de connexion (pour changer ton IP) et actualise ton navigateur. Tu auras une belle erreur 503 ! (Tu peux personnaliser la page si tu veux aussi).

C’est sympa, on a maintenant accès à Cockpit sans Port Forwarding.

Cependant on est encore en HTTP et c’est quand même plus secure d’être en HTTPS et d’avoir le petit cadenas vert !

On va s’en charger ensemble !

N’hésites pas non plus à aller voir les logs : /var/log/nginx/*.log tu pourras voir tes connexions, tes échecs etc …On pourra même se servir de ça pour gérer Reaction (outil de prévention de la partie 2).

Passons à la dernière étape, le SSL

Paramétrage du SSL

Le SSL c’est la connexion sécurisée, le grand frère protecteur du HTTP, le petit cadenas vert. C’est la garantie d’une autorité de certification qui donne cette valeur ajoutée à ton site et surtout qui améliore la sécurité pour les données que tu envoies et reçoit.

Petit rappel : ce n’est pas parce qu’un site possède un cadenas vert qu’il est digne de confiance, c’est juste qu’entre toi et lui, c’est sécurisé, mais ça ne veut pas dire qu’il n’essayera pas de te la mettre à l’envers (#phishing).

Pour nous, on va utiliser l’autorité de certification Let’s Encrypt qui est gratuite.

On va simplement suivre la documentation de Let’s Encrypt qui nous conseille d’utiliser “CertBot” qui est leur robot de certification et qui s’occupe de tout (attribution, renouvellement)!

Comment ça fonctionne (Documentation ici) ?

On va indiquer pour quel site nous souhaitons le certificat SSL.

• Certbot va créer un fichier à récupérer par Let’s Encrypt (.well-known/acme-challenge/<token>)

• Let’s Encrypt va tenter de récupérer ce fichier depuis le nom de domaine : http://tondomaine.dedyn.io/.well-known/acme-challenge/<token>

• Si le fichier est dispo, alors le nom de domaine est bien relié à l’IP et est donc légitime ⇒ challenge réussie

• Si le fichier n’est pas dispo, cela peut être un problème de firewall ou de nginx.

Aparté sécurité : Le vol de certificat.

Même si quelqu’un essaie de voler un certificat pour ton domaine, Let’s Encrypt n’émettra rien

tant que le challenge ne répond pas depuis l’IP réellement liée au domaine via DNS.

C’est la base de confiance de Let’s Encrypt.

Cependant … ne partage pas les certificats à d’autres une fois qu’ils sont émis (un peu comme les clés SSH) sinon ils peuvent être utilisés à de mauvaises fins.

Commençons avec Certbot :

apt install certbot

On installe ensuite le plugin certbot pour nginx : apt install python3-certbot-nginx

Puis on lance le certbot : certbot --nginx

Suis les instructions et sélectionne le bon site (Certbot lit tes fichiers de configuration nginx et arrive à détecter tous tes sites ayant besoin d’un certificat).

Si tout s’est bien passé tu obtiendras ça :

L’adresse email que tu as renseignée te permettra de savoir quand le certificat sera renouvelé ou si jamais il y a eu un soucis de renouvellement.

Si tu check ton fichier de conf, tu vas te rendre compte que Certbot a ajouté de nouvelles directives : cat /etc/nginx/conf.d/cockpit.conf

C’est vraiment l’avantage de Certbot, l’automatisation du processus d’obtention et du renouvellement du ssl.

A présent si tu passes sur Cockpit avec ton nom de domaine, tadaaaaam ! Le cadenas vert (bon ok sur mon écran il est pas vert ...) ! Et le certificat dispo dans les infos complémentaires.

Dernière petite étape, à présent on a un nom de domaine mais rien n’empêche quelqu’un d’accéder directement avec l’IP et donc de bypass le reverse proxy. Pour ça on va ajouter un fichier de configuration pour le cas où Nginx ne trouve pas de correspondance entre la requête du user et les entrées dans les fichiers de configurations.

On crée un nouveau fichier nano /etc/nginx/conf.d/default_server.conf :

  server {
      listen 80 default_server;
      listen [::]:80 default_server;
      server_name _;
    
      return 403;
  }
  server {
      listen 443 ssl default_server;
      listen [::]:443 ssl default_server;
      server_name _;

      ssl_certificate /etc/letsencrypt/live/tonndd.dedyn.io/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/tonndd.dedyn.io/privkey.pem;

      return 403;
  } 

De cette façon, on bloque avec un 403 Forbidden les autres requêtes qui ne correspondent à aucunes de nos entrées *.conf.

Oublie pas de tester ta conf (nginx -t) puis de redémarrer ton service.

De cette façon, Nginx prend en charge aussi la partie “sécurité” du trafic vers des entrées non configurées.

En bonus, on va paramétrer Reaction pour gérer les 403 répétitifs sur Nginx (Installation dans la partie 1)

nano /etc/reaction.yml

 nginx:
   cmd: ['tail', '-f', '/var/log/nginx/access.log']
   filters:
     fail:
       regex:
         -  '<ip> - - \[.*?\] "GET / HTTP/.*?" 403',
       retry: 5
       retryperiod: '24h'
       actions:
         ban:
           cmd: ['ufw', 'insert', '1', 'deny', 'from', '<ip>', 'to', 'any', 'app', 'Nginx Full', 'comment', 'ban-reaction'] 

Nginx Full est un alias pour le port 80 et 443 (ça permet en une seule ligne de ban 2 ports).

On pourrait être plus “méchant” et bloquer tout le traffic de cette IP mais on va s’en tenir aux flux web (Parce que ça pourrait être notre IP et on pourrait se retrouver jeté de notre serveur très vite #trueStory 😅).

On restart le service : service reaction restart et il n’y a plus qu’à patienter. Fun fact pendant ma config, pour la démo, 2 IPs en moins de 20s se sont faites ban avec ce système :

C’était surtout l’occasion de reparler de l’outil de Ppom.

On peut aussi aller un peu plus loin dans la sécurité avec Nginx puisqu’il est possible de protéger ses sites avec de la GeoIP protection. Il s’agit de limiter l’accès à ses sites en fonction de la localisation de l’IP d’où provient la requête. Si utilisateur malveillant il y a, alors il devra utiliser la bonne localisation pour tenter une approche.

Pour ça on doit récupérer la base de données à jour des IPs et des localisations. Etant donné qu’elle doit être régulièrement mise à jour, on va placer le process dans un script bash pour l’inclure dans une cron job exécutable tous les mois.

nano /root/geoIPUpdate.sh

#!/bin/bash 
mkdir -p /usr/share/geoip
wget -O /usr/share/geoip/maxmind.dat.gz https://dl.miyuru.lk/geoip/maxmind/country/maxmind.dat.gz
gzip -d -c /usr/share/geoip/maxmind.dat.gz > /usr/share/geoip/maxmindcountry.dat
rm -f /usr/share/geoip/geoip.dat.gz

chmod +x /root/geoIPUpdate.sh

Puis on va dans la cron tab : crontab -e et on ajoute :

0 0 1 * * /root/geoIPUpdate.sh

Tout les mois, on aura une base mise à jour. Ensuite on retourne sur le reverse proxy :

nano /etc/nginx/nginx.conf dans le bloc http on ajoute la directive de la GeoIP :

// On hydate Nginx avec la DB des Ips
geoip_country /usr/share/Geoip/geoip.dat; 

// On indique à Nginx quelles localisations on souhaite laisser passer.
map $geoip_country_code $allowed_country {
    default no;
    FR yes;
}

Avec un nginx -t si le système indique le module n'est pas installé alors installe le avec sudo apt install libnginx-mod-http-geoip

A présent on a accès à la variable $allowed_country que l’on peut utiliser dans nos *.conf de nginx :

nano /etc/nginx/conf.d/tonsite.conf :

    allow tonipdecheztoi;
    if ($allowed_country = no) {
       return 403;
    }
    // deny all; 

Avec ça tu peux bloquer en fonction de la localisation indiquée dans ton nginx.conf et tous les mois tu auras une base de données à jour sans y penser !

Tu as énormément d'autres options pour un reverse proxy, tu peux passer aussi l'IP source qui demande ton application (le client) dans les paramètres à ton application. Pour ça il te suffit de rajouter une variable dans les headers de ta requête depuis ton bloc server {}, comme ceci :

  location / {
      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;
  } 

Quand Nginx communique avec ton application, l'application reçoit l'IP du Nginx mais pas celui du client. De cette façon, on ajoute des headers à la requête pour lui donner plein d'infos sur le client et ainsi garantir la traçabilité de la requête (En PHP par exemple quand tu fais $_SERVER["REMOTE_ADDR"], ça provient d'un header et avec Nginx tu peux l'ajouter comme ça).

A présent tu sais maintenant gérer un reverse proxy, le ssl et attribuer un nom de domaine à ton application !

On arrive au bout de cette mini série de trois épisodes pour t’apprendre les bases de la gestion de serveur et de l’hébergement d’application.

Bien sûr il y aurait encore tellement de choses à voir comme paramétrer un serveur Apache, gérer une base de données, mais on sortirait du cadre de la gestion de serveur et la série ferait 20 articles 😅

Cependant tu peux tenter d’héberger un PHPMyAdmin, sécuriser son accès avec Nginx (autoriser uniquement ton IP), gérer le SSL. C’est un bon exercice pratique !

On arrive au bout de cette mini série de 3 articles pour dégrossir la gestion d’un serveur de dev.

J’espère que grâce à ça tu auras moins peur de te lancer dans la config d'un VPS !