edel
Temps de lecture : 21 minutes


Bonjour ! C’est parti pour un long, très long article sur ce sujet qui, en tant qu’informaticien, administrateur système de profession, me passionne, j’ai donc beaucoup de choses à dire et je les ai écrites dans ce billet.
J’espère qu’au moins une petite partie des lecteurs auront le courage de le lire jusqu’au bout 🙂

En raison de sa longueur, j’ai organisé cet article en chapitres, dont voici la table des matières :

Allez, c’est parti pour cette immersion dans le monde des serveurs informatiques…

Qu’est-ce qu’un VPS ?

Le terme VPS pour « Virtual Private Server », ou en français « Serveur Privé Virtuel », désigne un serveur informatique prenant la forme d’une machine virtuelle qu’un fournisseur de services Cloud va mettre à disposition d’un utilisateur, sous la forme d’une location. Celle-ci étant elle-même hébergée sur un serveur physique, qui fait tourner plusieurs VPS, et qui lui est exploité sous la responsabilité du fournisseur de services Cloud.

Un VPS est donc une machine virtuelle avec des ressources allouées et dédiées pour l’usage du client qui la loue, sur laquelle le but est d’installer le système d’exploitation et les applications que l’on souhaite. Autrement dit, le client en a le contrôle (et la responsabilité du bon fonctionnement) complet, il est hébergé dans un environnement isolé des autres VPS qui sont hébergés par le serveur physique. Enfin, un VPS tourne le plus souvent sous une distribution Linux, mais en théorie, rien n’empêche d’installer un système d’exploitation de type Windows Server.

Que peut-on faire avec ? Avantages vis à vis d’un hébergement partagé

Le VPS permet donc de faire tourner à peu près tout ce qu’on souhaite y faire tourner, à condition, comme sur n’importe quel matériel informatique, de respecter les ressources matérielles du serveur. En pratique, il va permettre de faire tourner un site web, avec des pages statiques ou dynamiques, associées ou non à des bases de données pour le traitement et le stockage des informations, mais il peut aller bien au-delà, notamment grâce à une autre technique de virtualisation : les containers Docker.

Alors, je ne vais pas rentrer dans les détails, ce n’est pas le sujet de cet article, mais en 2 mots, un container Docker est un environnement logiciel virtuel (lui aussi !) qui peut tourner sur n’importe quel système d’exploitation moderne. Et j’y reviendrai plus tard, car c’est un environnement que j’ai appris à utiliser dans le cadre de l’installation de mon VPS.

Enfin, un VPS peut également être utilisé pour installer un environnement de développement évolué (avec un ou plusieurs frameworks). Je ne vais pas non plus détailler cet usage, car ce n’est pas le mien.

Mais, pourquoi donc passer à un serveur complet, qu’il faut gérer entièrement soi-même, alors qu’il existe de nombreuses offres d’hébergement de sites web de type partagés, où le client ne gère que son propre contenu, et le fournisseur de service tout le reste, y compris tous les aspects de sécurité et de sauvegarde des données ?

La première est directement liée à mon métier, en effet, dans mon environnement professionnel, je gère des serveurs virtuels sous Windows au quotidien, c’est donc un environnement technique que je maitrise bien, et que je pense pouvoir également maitriser dans le cadre d’un serveur personnel.

Mais ce n’est bien sûr pas la seule : je possédais de longue date un (modeste) site web hébergé en mode partagé, où je n’avais donc que mon contenu à gérer, pas la gestion du serveur. Et il se trouve qu’avec le temps, je me suis trouvé un peu à l’étroit sur cet hébergement, non pas en terme de place sur le disque, mais de possibilités techniques, pour faire tourner mes propres services (j’y reviendrai dans la suite de cet article). Certes mon hébergeur proposait une offre avec pas mal de possibilités pour de l’hébergement partagé, mais il y avait une lacune qui a fini par devenir un obstacle : l’impossibilité de faire tourner des containers Docker, déjà évoqués précédemment.

Alors j’ai commencé à regarder les offres de location de VPS, et je suis tombé assez rapidement sur celle qui m’a finalement poussé à me lancer dans ce projet.

Mon choix de VPS

Et bien sûr, si vous avez lu mes précédents articles de blog, vous ne serez pas surpris d’apprendre que mon choix ce soit porté sur un acteur européen, en l’occurence la société IONOS, basée en Allemagne, avec une offre d’entrée de gamme qui suffit largement à mes modestes besoins, la fiche technique du serveur se composant ainsi :

  • 4 vCores (CPU)
  • 4 Go de RAM
  • 120 Go de NVMe SSD

Sans rentrer une fois encore dans les détails techniques, c’est bien assez pour mon objectif de faire tourner un serveur sous Linux (Ubuntu Server), en effet point d’interface graphique ici, donc pas besoin de beaucoup de mémoire RAM ni d’espace de stockage disque (SSD).
Oui, un serveur sous Linux, c’est de la ligne de commande, mais aussi, je l’avais en tête dès le départ, la possibilité de disposer d’une interface de gestion par une interface web, qui s’avèrera pour moi d’une aide et d’une efficacité des plus précieuses. Aussi, Linux est un système d’exploitation gratuit, non soumis à une licence payante, contrairement à Windows. Et il consomme bien moins de ressources matérielles que Windows.

Le prix de cette configuration ? 3,60€/mois pendant 2 ans, ensuite 5,40€/mois. Vraiment pas une ruine, moins cher même que mon hébergeur précédent !

Je dispose en plus, lors de la souscription, d’une période d’essai de 30 jours, durant lesquels je peux mettre fin à cette location si je n’en suis pas satisfait. Et au final, je l’ai conservée 🙂

Installation initiale (console puis panel de gestion web)

Donc, le point de départ, c’est un serveur vierge. Mais vraiment. Rien n’est installé dessus, tout est à faire. C’est un peu vertigineux sur le coup, surtout quand on n’a pas trop l’habitude de ce type d’environnement dépouillé. « Bon alors, par où je commence ? »

Et bien je commence par aller sur l’interface de gestion du serveur chez le fournisseur IONOS, qui va me permettre d’installer un système d’exploitation en mode console, sans interface graphique (donc là, Linux Ubuntu Server). Puis, à la fin de l’installation, heureusement entièrement automatisée, y compris pour la mise en réseau, l’interface me permet de me connecter au serveur via une console minimaliste, mais qui va me permettre d’avancer.


Et voilà donc le point de départ, juste après l’installation initiale, ça pique un peu…

Bon à ce stade, il me parait prioritaire de passer directement à l’étape de l’installation de la console de gestion du serveur via une interface web. J’ai fait un peu de repérage en amont, j’en ai repéré 2 qui correspondent à mes besoins, en plus d’être gratuites pour un usage de base, qui me suffira.

Je passe rapidement sur la première, dont l’installation se soldera pas un échec cuisant, me donnant le droit de réinstaller le serveur de 0. A ce stade, je pouvais encore facilement me le permettre, je n’avais encore aucune donnée à moi dessus.

La seconde sera heureusement nettement plus concluante, puisque c’est celle que j’utilise aujourd’hui, et que je vais donc conserver : aaPanel.


L’interface de aaPanel, on peut gérer une belle quantité de paramètres, installer des composants logiciels, avoir accès à un gestionnaire de fichiers complet,
bref c’est un mini système d’exploitation dans le serveur et c’est très, très pratique !

Et fort heureusement, l’installation de ce panneau d’administration se fait fort simplement, et surtout sans erreur d’installation, au moyen de cette ligne de commande, depuis la console illustrée précédemment :

URL=https://www.aapanel.com/script/install_panel_en.sh && if [ -f /usr/bin/curl ];then curl -ksSO $URL ;else wget --no-check-certificate -O install_panel_en.sh $URL;fi;bash install_panel_en.sh ipssl

Inutile de chercher précisément à quoi sert chaque commande de ce bloc, il suffit de le coller dans la console, de valider, et 2 minutes après on se retrouve avec une interface web de gestion toute belle toute neuve, qu’il va certes falloir prendre en main, mais qui est tout de même moins rebutante, à mon goût, que la console brute de décoffrage…

La suite de l’installation va consister à paramétrer, installer, puis paramétrer à nouveau de nombreux composants logiciels qui viendront enrichir les fonctionnalités de mon serveur : entre autres, l’installation – et le paramétrage, donc – d’un site web, d’un moteur de base de données, et d’un moteur d’interprétation de pages web dynamiques, et donc, dans un second temps, de toute la partie concernant la gestion de Docker (les fameuses applications virtualisées).

Parenthèse technique (vous pouvez passer au paragraphe suivant si vous n’êtes pas venu ici pour la technique) : à noter également que j’ai passé un certain temps à gérer la migration de mon site internet existant, du moteur Apache 2 au moteur NGINX. La logique de fonctionnement est la même, mais la syntaxe des éléments de configuration est bien évidemment différente, ce serait trop facile sinon… Et j’ai fait cette transition pour pouvoir utiliser une fonction très pratique, pour pouvoir accéder à des ressources en ligne dans des environnements contraints, en particulier par des filtrage de navigation dans les réseaux d’entreprise. C’est fonction, c’est le reverse proxy, ce terme un peu barbare désignant une technique qui permet de transformer un lien d’accès à un site, par exemple : site1.fr:3000 va devenir site1.fr sans le nombre à la fin désignant un port spécifique d’accès. Et là où un réseau d’entreprise va interdire l’accès au site sur le port 3000, il va permettre l’accès sur l’adresse standard, sans le nombre. Et çà, c’est bien plus facile à mettre en place avec NGINX qu’avec Apache.

Donc me voilà, au bout de plusieurs heures d’installation et de paramétrage, avec un serveur fonctionnel, du moins en apparence, parce qu’à ce stade, il y a encore des trucs qui ne vont pas très bien…

Les joies de l’apprentissage : quand rien ne va… il vaut mieux tout recommencer

Et en particulier, l’interface de gestion elle-même présente des signes inquiétants d’instabilité, avec des messages d’erreurs d’abord discrets, puis de plus en plus présents, au point qu’il devient difficile de l’utiliser au quotidien.

De plus, après un arrêt/relance de serveur, j’étais toujours obligé de faire 2-3 opérations à la main, pour que tout refonctionne comme attendu, ce qui n’est pas normal.

Cette première installation était un ballon d’essai, une première incursion dans le monde de la gestion complète d’un serveur Linux. Avec mon inexpérience d’alors, j’imagine que j’ai du faire des opérations que je qualifierai volontiers d’hasardeuses… avec probablement des conséquences que j’ai sous-estimé. Alors, même si j’avais plus que commencé à mettre mes données sur ce serveur, j’en conservais précieusement une copie de sauvegarde, si bien qu’au final, j’ai fini par décider de procéder à une réinstallation complète du serveur, de 0. Retour à la case départ donc, avec la fameuse console quasi vierge du début…

Mais j’ai quand même pu capitaliser sur l’expérience acquise lors de la première installation, je suis reparti sur cette nouvelle installation avec le but de ne pas reproduire les erreurs initiales, bien aidé aussi par une meilleure connaissance du panneau d’administration, et une meilleure compréhension de son fonctionnement.

Au final, même si cette réinstallation m’a fait perdre pas mal de temps et d’énergie, elle a été très bénéfique. Le comportement du serveur et du panneau d’administration sont ainsi redevenus normaux.

Seconde installation de 0 : c’est la bonne ?

Et donc, oui, c’est la bonne ! Tout a été plus rapide et fluide à paramétrer (forcément, c’est plus facile quand on maitrise les paramètres), j’ai notamment modifié l’emplacement du stockage des données de mes conteneurs Docker, auparavant intégrées au panneau d’administration du serveur, à présent isolées dans un dossier distinct, ce qui fut très bénéfique.

Il me semble en effet qu’au redémarrage du serveur, aaPanel effectue un certain nombre d’opérations de maintenance dans son dossier, perturbant plus qu’autre chose le fonctionnement des containers Docker installés.

J’ai donc pu reprendre l’installation jusqu’au point de blocage précédemment rencontré, et j’ai pu. enchainer jusqu’à finaliser toutes les briques logicielles que j’utilise encore aujourd’hui. Sans rencontrer de nouveau point de blocage 🙂

Un dernier paramétrage, provoquant une dernière anomalie à comprendre et à corriger

Mais il me restait une dernière chose à faire pour parfaire le fonctionnement de mon serveur. Une opération qui, je ne le savais pas encore, allait mettre à terre la moitié des ressources hébergées sur mon serveur, dans les minutes qui ont suivi la mise en oeuvre, et jusqu’à la correction le lendemain midi.

Le pire, c’est qu’il s’agissait d’un paramétrage tout à fait optionnel, le serveur fonctionnant par ailleurs très bien sans ce paramétrage. Mais on est perfectionniste ou on ne l’est pas… en tout cas, dans ce domaine.

Cette opération, c’est la prise en charge des réseaux de type IPv6. Je ne vais pas, une fois de plus, rentrer dans les méandres techniques de ce que ça implique, il faut simplement savoir qu’internet est né, et fonctionne toujours en grande partie, avec des réseaux IPv4. Mais ces derniers ont tendance à saturer de plus en plus au fil des ans, si bien qu’il a fallu mettre en place un successeur, IPv6, qui permet de prendre en charge des réseaux bien plus vastes.

Et donc, pour faire les choses bien, comme IONOS le permet sans surcoût, j’ai eu la brillante idée de rajouter une carte réseau IPv6 à mon serveur, et surtout, de prendre en charge le trafic IPv6 pour accéder aux services de mon serveur. Mais j’ai oublié une étape cruciale de configuration, tout simplement parce que je ne la connaissais pas encore à ce stade.

Cette étape consiste à rajouter 3 lignes de paramétrage sur chacun des services web opérés sur mon serveur par le moteur NGINX, car ce dernier n’était alors configuré que pour écouter sur les réseaux IPv4. Les 3 lignes ajoutant la prise en charge des réseaux IPv6. Et donc, sans ce paramétrage, une requête d’accès à un des sites internet de mon serveur, transitant par le réseau IPv6, parcourait le serveur, sans jamais tomber sur le site correspondant, qui n’écoutait pas ce réseau. Et la requête finissait en erreur… Pour ajouter à la difficulté du diagnostic, lesdits sites internet fonctionnaient très bien lorsqu’on utilisait un réseau IPv4, l’écoute étant déjà bien opérationnelle sur ce réseau, avant la mise en place de la correction.

Le traitement fut rapide et efficace, après avoir identifié le paramétrage nécessaire : en moins de 5 minutes, les sites concernés sont redevenus opérationnels depuis les réseaux IPv6. Et donc l’intégralité des services hébergés sur mon serveur.

Bilan de mon installation, ce que je peux faire avec

Et donc au final, je fais quoi avec mon serveur ?

Déjà, j’ai remis en place mon site qui tournait chez l’ancien hébergeur, en mode hébergement partagé, à commencer par ce blog, mais aussi pas mal de petits scripts que j’ai conçu au fil du temps, qui se lancent à intervalle régulier pour récupérer des informations, liées à la météo et au trafic de ma ligne de train de banlieue, notamment en début et en fin de journée. Il y en a également un dédié à l’alimentation d’un compte Mastodon et d’un compte Bluesky, contenant une revue de presse de l’actualité traitée par la presse française, plus quelques autres bricoles de ce type.
Enfin, j’ai remis en place 2 petites applications web gratuites qui ne sont pas de moi, mais qui me sont très utiles, à savoir un agrégateur de flux RSS (FreshRSS), et un webmail (Roundcube) me permettant d’avoir accès à mes mails depuis n’importe quel PC, à la manière d’un Gmail.

Mais le fait d’avoir un VPS et donc de pouvoir avoir plus de contrôle sur son contenu m’a permis d’installer plusieurs petites applications web que je n’avais pas jusque là, à savoir :

Sous forme de containers Docker :

  • AliasVault, un très bon gestionnaire de mots de passe, gratuit, disponible sur iOS et Android, et sur ordinateur sous forme d’une extension pour les principaux navigateurs web modernes, et dont j’assure la traduction en français en tant que contributeur bénévole au projet. Avoir cette application sur mon serveur me permet de m’assurer que mes données, de par leur nature, sensibles, restent sur mon serveur et ne sont pas stockées ni exploitées ailleurs.
    Je possède un coffre de mots de passe à moi, mais il techniquement possible d’en héberger d’autres, d’utilisateurs différents, possédant leur propre compte dans l’application, auxquels je n’aurais pas accès (je ne serais alors qu’hébergeur de ces données).
  • AudioBookShelf, un service de lecture d’audiobook et de podcasts. Pour la partie Audiobook, le principe de fonctionnement est le même qu’un Audible d’Amazon, mais les données étant stockées sur mon serveur, le contenu provient d’autres sources. La partie podcast est anecdotique, sauf à créer et diffuser ses propres podcasts, ce qui n’est pas mon cas.
  • RustDesk, un logiciel de prise de main sur ordinateur à distance, notamment pour faire du support informatique. Il en existe d’autres, mais l’intérêt de cette solution, hébergées sur mon VPS sous forme d’un relai local communiquant avec d’autres serveurs liés à ce logiciel sur Internet, est de ne rendre visibles les ordinateurs sur lesquels je l’ai installé qu’en utilisant les informations d’identification de mon VPS. C’est à dire que même si vous connaissez le numéro associé à un de ces ordinateurs, si le client utilisé ne se connecte pas via mon VPS, il ne pourra pas communiquer avec l’ordinateur distant, ce qui apporte une sécurité appréciable.


Sous la forme d’une application écrite en Javascript (node.js) :

  • Strava Activity Exporter, une application web qui, comme son nom l’indique, permet d’exporter les activités enregistrées dans Strava, au format FIT, GPX ou TCX. Certes, Strava permet aussi de le faire, mais seulement activité par activité. Cette application web permet de le faire pour plusieurs activités en une seule fois, ce qui peut être très pratique pour archiver ses données brutes dans un autre emplacement que les serveurs de Strava.

Voilà pour l’état des installations au moment d’écrire cet article, bien sûr cette liste n’est pas figée dans le temps et pourra être amenée à évoluer.

Ce qui ne changera pas en revanche, en tout cas pas avant un moment, c’est que je n’y installerai pas ma boite mail ni mon stockage cloud, bien que ce soit techniquement possible (il y a des composants logiciels pour cela, que je pourrais installer sur mon serveur si je le voulais). Simplement, je ne souhaite pas mettre tous mes oeufs dans le même panier, sans quoi je prendrais le risque de perdre l’accès à mes mails et mon stockage cloud en cas de problème technique bloquant sur le VPS. Et donc pour ces 2 services, je fais confiance à la société suisse Infomaniak et à son offre kSuite dans sa formule Pro, qui en plus met à ma disposition 3 To de données pour le stockage cloud, bien plus que les 120 Go de mon VPS.

En résumé, je dédie mon VPS à un usage d’hébergement de sites et d’applications web assez légères, là où la messagerie et le stockage cloud nécessitent davantage de ressources matérielles. Pour, je le rappelle, moins de 6€/mois.

Ceci conclut la partie orientée sur l’installation du serveur et de son contenu. Dans la suite de l’article, je vais aborder des sujets plus généraux sur les bonnes pratiques à adopter pour maintenir le serveur dans un bon état de fonctionnement, dans la durée. Des sujets qui ne sont pas, dans le cadre d’un hébergement partagé, de la responsabilité, et donc de la gestion, du client, mais qui le sont dans le cadre de la gestion d’un VPS, et qu’il ne faut donc pas négliger.

Le monitoring, pour s’assurer que tout va bien

Cette partie est dédiée à mon employeur, qui ne lira pas cet article, mais qui m’a très fortement sensibilisé, à raison, à cette problématique, qu’on appelle chez nous la supervision.

Alors s’agissant d’un serveur personnel, la réactivité sur la remise en service n’a bien sûr rien à voir, mais le principe est le même : à l’aide d’outils de supervision, ou de monitoring, qui vérifient en temps réel ou presque, l’état, fonctionnel ou non, des composants logiciels du serveur préalablement paramétrés, et préviennent si un problème se produit, à l’aide notamment de notifications et/ou de mails envoyés sur smartphone.

On reste dans le domaine grand public, donc à la différence d’outils professionnels, ce type d’outils pour les particuliers ne va pas chercher à résoudre (remédier) le problème de lui-même, ce sera à moi d’intervenir, à ma guise en terme de timing, selon mes disponibilités.

Il existe plusieurs outils dédiés à ce rôle, j’ai même pendant un temps envisagé d’en utiliser un que je pouvais installer sur mon serveur… mais si le serveur tombe (devient inopérant), l’outils de monitoring tombera avec… donc je me suis orienté sur un service externe, qui plus est gratuit dans la limite de 50 tests, ce qui est bien assez pour mon besoin, puisque j’ai défini 10 tests. Il s’agit de l’outils UptimeRobot, qui en plus dispose d’une application iOS et Android, permettant de voir, sur son smartphone, le suivi et la l’historique de la disponibilité des services surveillés.


L’interface web d’UptimeRobot, qui présente les indicateurs de disponibilité de chacun des services surveillés (image d’illustration)

L’outils fonctionne de manière autonome et automatisée, une fois les paramètres de suivi définis, il n’y a plus rien à faire à son niveau.

La gestion des sauvegardes et procédure de restauration

Là encore un point très important, et un héritage de mon boulot. Car si le serveur tourne très bien la plupart du temps, il peut tout à fait se produire une défaillance logicielle ou, pire encore, un sinistre sur le lieu où il est hébergé, à l’image de ce que la société OVH a connu il y a quelques années, et qui avait fait grand bruit.

En la matière, IONOS, le fournisseur de mon VPS, propose sa propre solution de sauvegarde, mais je ne l’utilise pas pour 3 raisons :

  • Elle ne m’a pas paru très pratique à utiliser, je n’ai pas trouvé d’interface simple qui permette de gérer les sauvegardes et les restaurations,
  • Je dispose par ailleurs de tout le nécessaire pour gérer les sauvegardes moi-même, avec le NAS Synology dont je dispose à mon domicile, et l’espace de stockage Cloud que je possède chez Infomaniak
  • L’offfre de IONOS est payante, là où ma solution maison est gratuite. Enfin, pas tout à fait, puisque je paye mon espace cloud, mais j’en fait bien d’autres usages que la gestion des sauvegardes de mon VPS, cet usage n’induit pas de surcoût, donc je le considère comme étant gratuit.

Voici donc comment je procède à mes sauvegardes, l’ensemble de ce qui est décrit ci-dessous s’effectue de façon planifiée et totalement automatisée :

  • Chaque matin à 6h30, mon NAS se connecte à mon serveur, en utilisant le protocole « rsync », avec le logiciel « Active Backup for Business », dans lequel j’ai défini une tâche de sauvegarde, incluant toutes mes données stockées dans un dossier précis du VPS, ainsi que toutes les données du panneau de gestion du serveur. Je récupère donc, sur mon NAS, ces données essentielles, et j’en conserve les 5 dernières versions. Ce qui donne un premier niveau de sauvegarde. Mais il m’en faut un 2è, en cas de sinistre ou de coupure internet prolongée à mon domicile…
  • A 8h, le second composant, « Hyper Backup » entre en jeu. Lui va envoyer la plus grande partie du contenu de mon NAS, y compris donc les sauvegardes de mon VPS, sur mon espace de stockage cloud chez Infomaniak, qui pour rappel me permet de stocker jusqu’à 3 To de données. Cette connexion à mon espace de stockage cloud se fait elle avec le protocole « webdav ». La conservation des données est gérée coté Infomaniak, je n’ai donc pas besoin de gérer plusieurs versions à cette étape.

Voila pour la partie technique sur les transferts de données entre les différents composants logiciels entrant en jeu.

A côté de çà, je me suis fait une checklist des actions à mener en cas de réinstallation complète du serveur, que je n’ai pas encore eu l’occasion de tester, et que j’espère avoir besoin le plus tard possible 🙂

La sécurité : risques d’un VPS et mesures à prendre pour les limiter

Et c’est le dernier point crucial du maintient en bonnes conditions d’un VPS : gérer les mises à jour, limiter les accès au serveur au minimum nécessaire, et activer la double authentification partout où c’est possible pour accéder à des données sensibles du serveur.

Car tout serveur mal maintenu et/ou protégé des accès non désirés s’expose à être exploité par des personnes malveillantes, si par hasard elle arrivent à s’y connecter. La démarche consiste donc à empêcher le plus possible ces accès malveillants, ce qui est relativement simple dès lors qu’on applique avec sérieux les mesures à suivre.

Les mises à jour d’abord : je sais que les particuliers n’aiment pas trop recevoir une notification de Windows leur demandant d’installer des mises à jour, qui, bien souvent, s’accompagnent d’un besoin de redémarrer l’ordinateur. Mais pour ma part, de par mon métier, je sais que ces mises à jour sont faites avant tout pour protéger l’ordinateur, et combler des failles de sécurités que les pirates informatiques découvrent, puis exploitent, régulièrement. Et c’est encore plus vrai pour un serveur, fut-il sous Linux.
Donc pour mon serveur, ces mises à jours sont traitées de façon simples et automatisées, par 2 tâches planifiées : l’une s’occupe des mises à jour des composants logiciels du système d’exploitation, l’autre des mises à jour des containers Docker. Et chacune est exécutée chaque nuit entre 1h et 2h du matin. Si bien qu’à mon niveau, c’est complètement transparent.

Limitation des accès au serveur : une première action simple consiste à modifier le port d’accès à la connexion SSH (la ligne de commande à distance) du serveur, qui est par défaut sur le port 22. Je ne dévoilerai pas ici le numéro du port que j’utilise, mais il est bien différent puisque sur plus de chiffres. Cette simple action élimine la très grande majorité des tentatives d’accès, qui se font le plus souvent sur le port standard (22, donc). D’autre part, j’ai mis en place une limitation de l’accès à cette console à distance, à savoir qu’il n’est possible de s’y connecter qu’avec un fichier de clé chiffrée bien précis, que j’ai généré sur le serveur puis récupéré, et qui est stockée bien au chaud dans mes documents personnels. Ainsi, même en entrant le bon mot de passe du compte de l’administrateur du serveur, le serveur refusera la connexion. Il faut impérativement disposer de la clé chiffrée. Le résultat est implacable : depuis que j’ai mis en place ces 2 mesures, j’ai 0 tentative de connexion échouée sur mon serveur, comme en témoigne l’image ci-dessous, prise au moment d’écrire cet article 🙂

Dernier levier de sécurisation : l’activation de la double authentification. Pour rappel, ceci consiste à ajouter une étape pour valider une authentification, à savoir la saisie d’un code de validation aléatoire, qui change en moyenne toutes les 30 secondes, et qui est fourni par un logiciel spécialisé dans cette tâche. Pour ma part, c’est mon gestionnaire de mots de passe, Alias Vault, qui en a la charge.
J’ai mis en place cette sécurisation pour l’accès à mon panneau d’administration web de mon serveur (aaPanel), l’accès aux gestionnaire des bases de données du serveur, ainsi que pour l’accès à l’espace client et donc de gestion du serveur chez IONOS.

Il y a enfin un dernier point, que je ne vais pas trop détailler car on entrerait très vite dans de la pure technique, c’est la gestion des ouvertures firewall, aussi bien côté interface de gestion du serveur côté IONOS, que sur le serveur lui-même. Concrètement, tout le trafic vers et depuis le serveur est bloqué sur tout autre port que ceux déclarés et ouverts. Le but est donc d’en avoir le moins possible. A cet égard, c’est un autre avantage du Reverse Proxy donc je parlais plus haut dans l’article : en offrant la possibilité d’accéder depuis internet aux différents sites et services web à partir du même port standard 443 (HTTPS), il permet de ne pas ouvrir vers l’extérieur les ports réellement utilisés par ces sites et services, qui sont en réalité bien souvent différents, pour des raisons techniques de fonctionnement interne.

Conclusion

Et voilà, on arrive (enfin !) au bout de cet article, merci d’être encore là, le sujet a du vous intéresser 🙂

Si vous êtes du métier, j’espère que vous serez globalement en accord avec ce que j’ai fait pour mon serveur, après je conçois qu’on puisse avoir chacun sa façon de faire, je pense en particulier aux adeptes de la ligne de commande qui sont certainement capables de se passer d’une interface web de gestion du serveur. Je respecte, mais ce n’est pas mon cas 🙂

Et si vous n’êtes pas du métier, toutes mes félicitations pour être arrivé jusque là, vous venez de découvrir, à travers un usage personnel, ce qui alimente une partie de mon quotidien professionnel, et encore, je ne suis pas trop rentré dans les détails techniques.

Plus globalement, en-dehors de mon indéniable intérêt pour la gestion des serveurs, cette démarche entre dans ma logique de souveraineté numérique que j’ai détaillée dans un précédent article, car toutes les données qui sont stockées sur mon serveur sont en Europe, j’en maitrise le stockage et l’usage qui en est fait, c’est quelque chose que j’apprécie fortement.

Ainsi se termine cet article, merci encore pour votre attention.

Laisser un commentaire

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