KDE Plasma 6.6 Released
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Il y a quelques semaines, Intel lançait son premier pilote gérant le XeSS 3 et la Multi Frame Generation. Il était cependant destiné aux iGPU intégrés aux processeurs Panther Lake, ce qui avait quelque peu fait grincer des dents, à supposer que vous en ayez encore ! Mais le 13 février, le support ét...
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Le 4 février 2026, nous vous parlions d'un "test à l'aveugle" organisé par nos confrères de ComputerBase. L'article présentait des vidéos de 6 jeux différents, avec chaque fois trois versions différentes en parallèle. L'une était en 4K UHD natif, l'autre en 4K UHD avec DLSS 4.5 SR Qualité, la troisi...
Read more of this story at Slashdot.
![]()
Avoir un serveur sur un MiniPC c’est bien, l’ouvrir vers l’extérieur c’est mieux. Si des usages locaux sont évidemment nombreux, le véritable intérêt d’un serveur est de proposer des usages en ligne, accessibles depuis n’importe quel point du globe avec une simple connexion internet. Fail2Ban permet de repousser les attaques de base.
![]()
Au sommaire de cette seconde partie, nous allons reprendre le travail effectué lors de l’installation du serveur en décembre et le compléter. La première étape consistera à installer Fail2ban pour sécuriser le système. Puis nous ouvrirons l’accès au serveur sur Internet. Une fois cela fait, nous pourrons installer la plateforme Docker et enfin profiter de celui-ci pour installer facilement un premier service en déployant Adguard.
Avant de rendre totalement accessible notre serveur sur internet, il est préférable de le protéger du mieux possible. Pour cela nous allons utiliser Fail2ban qui fait partie de la trousse à outils de base de tout serveur en ligne. L’idée de Fail2Ban est d’éviter les attaques les plus classiques des robots en ligne. Les attaques du type « bruteforce » qui vont simplement tenter de se connecter en essayant des listes et des combinaisons de mot de passe. Le principe de cette protection et simple, elle consiste à bannir l’adresse IP provenant d’un nombre déterminé de tentatives de connexion échouées. Si un robot tente, par exemple, trois mots de passe erronés, le serveur va empêcher son IP de recommencer pendant un certain temps. C’est une méthode assez classique et simple qui évitera les attaques les plus primitives.
Ne croyez pas que parce que vous êtes un particulier qui installe un serveur anonyme sur la toile vous n’allez pas subir de tentative d’intrusions. Des dizaines de milliers de robots se baladent en permanence en ligne à la recherche de la moindre faille possible pour tenter d’y pénétrer. Votre petit serveur perso subira les mêmes tentatives qu’un grand serveur d’entreprise.
Fail2ban se base sur des « logs » ou des journaux des différents outils logiciels disponibles. Ici, nous allons utiliser une règle qui concernera les connexions SSH. Cette règle est quasiment prête à l’emploi, ce qui est pratique, mais il est possible d’en faire des personnalisées ou de trouver d’autres exemples sur internet.
On va commencer par se connecter à notre serveur en SSH de la même manière que pendant la phase d’installation du serveur.
On ouvre un terminal depuis un PC sur le même réseau que son MiniPC/serveur et on pianote ssh kevin@192.168.1.214 -p 21422 en adaptant évidemment le login et l’IP en fonction des réglages effectués auparavant. Si vous avez suivi la première partie du guide, votre PC a déjà un login, une connexion SSH et une IP fixe.
Une fois cela fait, règle d’usage classique, on va charger la liste des mises à jour disponibles depuis la dernière connexion en pianotant sudo apt update.
![]()
Il y a logiquement un bon nombre de paquets à actualiser, on va donc le faire rapidement avec la commande :sudo apt upgrade.
![]()
Il suffit d’appuyer sur entrée pour poursuivre. Une règle existe pour ce type de question de la part du système : la lettre en majuscule proposée est celle qui sera validée par la touche entrée. Ici le « O » est en majuscule pour « Oui » et le « n » reste en minuscule pour « non ». On appuie donc sur entrée.
Le système se met rapidement à jour et nous allons pouvoir partir sur cette base « saine » pour installer Fail2ban. Ce n’est pas très complexe, on pianote :
sudo apt install fail2ban
![]()
On confirme notre intention d’installer le service avec la touche entrée. L’installation débute et se termine très rapidement. Une fois celle-ci terminée, il va falloir mettre en place une configuration adaptée à nos besoins. Pas besoin d’être un expert pour y arriver, on va se contenter pour le moment de partir sur les bases par défaut de l’outil. Pour cela, on va copier et coller le fichier de configuration fourni par défaut. Pour cela, on va utiliser la commande cp qui sert à copier des fichiers avec cette syntaxe : cp [Original] [Destination]. La destination indique l’endroit où le fichier original sera copié et sous quelle forme. Il est tout à fait possible de prendre un fichier et de changer son extension, c’est ce que nous allons faire ici
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Ici, on a pris le fichier « jail » ou « prison » avec une extension « .conf » qui correspond à la configuration standard et nous l’avons transformé en jail.local pour qu’il soit lu comme la configuration spécifique (locale) de notre serveur. Nous allons maintenant adapter cette configuration locale en éditant ce fichier avec l’ordre.
sudo vim /etc/fail2ban/jail.local
Une fois le fichier ouvert, il nous faut chercher une section particulière de son contenu. Pour cela, il y a une astuce toute bête dans l’éditeur de texte vim. On appuie sur la touche « slash » : / suivi directement du texte que l’on recherche. Vim prend alors le relais et affiche la première occurrence qu’il trouve. Évidemment, il ne faut pas être en train d’éditer le texte sinon le « / » s’inscrirait dans le fichier. Pour éviter cela il faut appuyer sur la touche ESC/Exhap située en haut à gauche de son clavier. Ici nous allons rechercher « sshd » et donc pianoter « /sshd » qui doit se trouver aux alentours de la ligne 274.
![]()
Une fois la séquence trouvée il faut enclencher le mode édition de Vim avec la touche « i ». On peut alors modifier le contenu de la section de la manière suivante :
[sshd]
enabled = true port = 21422 # Port SSH pour se connecter à notre serveur filter = sshd maxretry = 3 # Nombre d’essais autorisés avant de bannir l’IP bantime = 3h # Durée du bannissement findtime = 600 # Intervalle (en secondes) durant lequel les 3 tentatives doivent avoir lieu pour entrainer un bannissement. logpath = %(sshd_log)s # ne pas toucher backend = %(sshd_backend)s # ne pas toucher
![]()
Après modification, votre fichier édité doit ressembler à cela. Si tout est dans l’ordre, alors appuyez sur Echap pour arrêter l’édition du document, appuyez ensuite sur w pour écrire (write) le fichier et donc le sauvegarder. Puis sur q pour quitter vim.
Pour que le système prenne en compte ces modifications, il faut redémarrer le service fail2ban. Pour cela on pianote :
sudo systemctl restart fail2ban
On vérifie ensuite que le service est bien en cours de fonctionnement avec la commande
sudo systemctl status fail2ban.service
Et on obtient normalement ceci :
![]()
Vous devez avoir un retour d’écran qui ressemble à la capture ci-dessus. Si c’est le cas c’est que Fail2ban fonctionne.
![]()
Si vous avez à l’écran un status indiquant « Failed » comme ci-dessus, il y a manifestement un problème. Pas de panique.
![]()
Jetez un coup d’œil au journal qui liste les informations (log), vous y découvrirez sûrement un souci de syntaxe dans votre fichier (ligne en double…). Ici par exemple, l’édition du fichier était mal exécutée, la ligne logpath était entrée deux fois… Après correction, on relance fail2ban et le problème est résolu.
![]()
Si vous avez sous la main une autre machine, vous pouvez tester de vous auto-bannir pour vérifier que le service est parfaitement fonctionnel. Après plusieurs essais de connexion, Fail2ban refuse la connexion depuis l’IP qui a été bannie. Ca fonctionne !
Pour récupérer l’IP bannie pour cet essai, vous pouvez lancer la commande :
sudo fail2ban-client unban 192.168.1.21
Il est aussi possible d’en bannir une manuellement avec la commande :
sudo fail2ban-client ban 192.168.1.21
Cela peut être pratique de configurer ainsi Fail2ban si vous repérez une IP aux agissements particuliers.
Pour pouvoir accéder à l’ensemble des services qui seront mis à disposition sur le serveur, nous allons le rendre accessible sur internet. Pour cela nous allons d’abord utiliser une IP avant de simplifier la démarche en utilisant un nom de domaine.
L’ensemble de ces manipulations est beaucoup plus simple si votre fournisseur propose une adresse IP fixe. Certains fournisseurs d’accès proposent cela par défaut comme Bouygues. Free demande une petite manipulation détaillée ici. Chez SFR et Orange, c’est une option. Si votre opérateur ne propose pas cette option il faudra utiliser un service tiers. Un autre serveur en ligne qui fera le lien vers votre machine. Plusieurs sociétés proposent cela comme Cloudflare ou no-ip.com.
![]()
Ci-dessus vous pouvez voir le principe de fonctionnement de notre recherche de serveur en ligne de manière très simplifiée. Même si des administrateurs système vont surement trouver que le schéma est trop simpliste, on comprend ici ce qu’il se produit lors d’une requête en ligne de ce type.
Depuis un navigateur, un internaute appelle la page garage.mondomaine.com. Un serveur de DNS va répondre à cet appel parce que cette adresse pointera chez lui. Il répondre au navigateur en lui disant d’aller voir une adresse IP précise, ici : 1.2.3.4 pour l’exemple. Cette adresse ne correspond pas à votre serveur directement mais plus globalement à votre point de destination, la ligne tout entière de votre fournisseur d’accès. Avec cette information en mémoire, le navigateur change donc de destination et va toquer à la porte de l’IP 1.2.3.4. Et donc de votre box internet. Il se présente comme un navigateur et interroge sur le serveur pour savoir où trouver la page correspondant à garage.mondomaine.com. Au passage, il montre patte blanche en indiquant qu’il propose une liaison sécurisée de type HTTPS sur le port 443.
La Box internet va interroger ses règles de transmission de portgénéralement indentifiées dans ses réglages comme du « port forwarding ». Si une règle s’applique à cette requête, alors elle exécutera le transfert des données. Comme nous allons indiquer à la Box de transférer toutes les requêtes du port 443 vers le serveur que nous avons monté. Les informations en HTTP non sécurisées se feront via le port 80 qui sera également piloté par la Box.
Sur le serveur maison, il va falloir installer un outil baptisé « Caddy ». Une sorte de chef d’orchestre qui triera les requêtes de l’extérieur et les redirigera vers le bon service. On appelle cela un « Reverse proxy ». Caddy pilotera les différentes enquêtes vers des services intégrés dans une sorte de portefeuille de services piloté par un autre outil logiciel appelé « Docker ». Ce dernier fournira une réponse qui remontera ensuite de Caddy vers lme routeur puis du roteur au navigateur.
![]()
Imaginez que vous appellez un standard pour avoir en ligne Marcel Machin, le responsable réparation de la société Mongarage SARL (l’équivalent de votre serveur) au téléphone. Vous décrochez votre combiné, comme vous ne connaissez pas le numéro vous demandez un opérateur (Le serveur DNS), vous lui dites que vous voulez telle société, l’opérateur regarde dans son annuaure et vous met en ligne (indication de l’IP). Là vous tombez sur une personne qui décroche au standard (votre BOX), vous lui dites a qui vous voulez parler, elle vous passe l’atelier ou une personne décroche (Caddy) avant de gueuler « MARCEL, TELEPHONE » (Le service Docker voulu). Marcel répond « Allô, non pour demain c’est pas possible » et vous etes connecté.
Il va falloir monter ces services sur le serveur. Cela a l’air compliqué mais pas de panique. Avec un peu d’aide c’est à la portée de tout le monde. Voilà ce qu’il nous reste a faire :
Et nous verrons cela dans le prochain épisode qui ne devrait pas tarder.
A propos de Kevin :
Kevin est développeur et formateur indépendant php et spécialisé sur le CMS Drupal. Il aime bidouiller des infrastructures cloud mais aussi plus traditionnelles comme un bon vieux petit serveur dans son garage… Vous pouvez en savoir plus sur son travail sur le site kgaut.net. Il est par ailleurs présent sur Mastodon à l’adresse @Kgaut
Guide : protéger son serveur personnel Linux avec Fail2ban © MiniMachines.net. 2026
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Le Premier ministre a publié une circulaire « relative à la commande publique numérique » couchant noir sur blanc la doctrine de l’État concernant les choix et achats de logiciels par ses services. Elle priorise l’utilisation de solutions internes existantes avant l’achat de produits « sur étagère ». Le développement de solutions en interne n’arrive qu’après.
Depuis la mise en avant de la Suite numérique de l’État et notamment sa solution de visioconférence Visio, une partie du milieu de l’industrie numérique français criait à la concurrence déloyale. Une circulaire relative à la commande publique numérique signée par Sébastien Lecornu essaye de jouer l’équilibre entre la mise en avant des solutions mutualisées développées en interne et le soutien aux startups françaises.
Publiée le vendredi 13 février au Journal officiel, cette circulaire relative à la commande publique numérique avait été évoquée par le gouvernement Lecornu lors de l’annonce, au début du mois, d’une nouvelle phase de déploiement pour le programme « Je Choisis La French Tech ».
À cette occasion, David Amiel, le ministre délégué chargé de la Fonction publique et de la Réforme de l’État, affirmait que « l’État n’a pas pour mission de concevoir des produits » et qu’il fallait se tourner vers le secteur privé. Mais c’est, en même temps, ce même ministre qui a récemment annoncé la généralisation de Visio, développé par la Dinum au sein de sa plateforme La Suite numérique.
Avant la publication de la circulaire, Bercy affichait que son but était de clarifier la doctrine d’achat de solutions numériques de l’État. Tout en essayant de ménager les startups françaises, ce texte donne priorité aux « solutions mutualisées déjà développées […] disponibles au sein de l’administration, en particulier via les services offerts par les opérateurs mutualisés ».
La circulaire donne une liste non exhaustive de ces opérateurs : DINUM, IGN, Opérateur des systèmes d’information interministériels classifiés (OSIIC), Centre interministériel de services informatiques relatifs aux ressources humaines (CISIRH), Agence pour l’Informatique financière de l’État (AIFE). « Leur recours doit être étudié en premier lieu en prenant en compte, le cas échéant, les besoins de développements complémentaires qui pourraient être nécessaires », explique encore le texte. C’est la DINUM elle-même qui tient le catalogue des solutions disponibles.
Ce n’est qu’après avoir vérifié qu’aucune solution mutualisée n’existe qu’un service de l’État peut s’équiper via des solutions « sur étagère » du privé. Le texte affirme que « l’État accorde une priorité forte à l’achat auprès de PME innovantes pour soutenir la recherche et développement au sein de l’écosystème européen » et ajoute que « chaque secrétariat général se fixe pour objectif d’augmenter sa part d’achats auprès de PME innovantes ».
Le développement d’un logiciel en interne ne peut intervenir que s’il n’existe pas de solutions « sur étagère » ou si celles-ci existent mais ne sont pas satisfaisantes. La circulaire évoque quand même de nombreux motifs d’insatisfactions autres que le coût, ainsi sont énumérées « les conditions de sécurité, de durabilité, de besoin ou de délais précitées ».
Lorsqu’il y a achats numériques, la circulaire pose des objectifs prioritaires à prendre en compte. Le premier est « la performance métier ». La « souveraineté numérique » arrive en deuxième, puis la sécurité, le coût, la disponibilité, l’adaptabilité et la réversibilité, l’interopérabilité et enfin la durabilité.
Si la souveraineté numérique est bien placée, il restait à la définir. Le texte affirme qu’en pratique, elle s’appuie « en particulier » sur trois points : l’immunité au droit extra-européen à portée extraterritoriale, la capacité de l’État à substituer une composante de ses systèmes numériques par une solution alternative, la maîtrise des technologies clefs.
« La qualification SecNumCloud permet notamment d’attester qu’une offre de service d’informatique en nuage bénéficie d’une protection adéquate à l’égard des réglementations extra-européennes à portée extraterritoriale. Cette immunité est en particulier requise lorsque la sensibilité des données le justifie », affirme le texte, toujours sur le volet souveraineté.
Côté sécurité, le besoin doit être « défini dès le lancement du projet en prenant en compte les exigences réglementaires spécifiques à certains types de données ou d’activité ». La qualification SecNumCloud y est aussi évoqué pour l’hébergement de « données d’une sensibilité particulière telles que définies par la loi ».
Le texte fait enfin un « zoom sur l’open source », affirmant : « que les solutions soient directement disponibles auprès d’un opérateur ou résultent d’un achat « sur étagère », il est recommandé de privilégier, lorsque c’est pertinent, le recours à des produits open source ». L’utilisation des logiciels open source permet « d’investir dans les mêmes technologies et de bénéficier des avancées de chacun ». « Une attention particulière doit être portée sur les contributions au code ouvert, tant sur la qualité que sur la quantité, afin de garantir sa pérennité et sa sécurité », précise le texte.
Une étude réalisée par des chercheurs de l’École polytechnique fédérale de Zurich révèle que Bitwarden, LastPass et Dashlane pourraient, dans des conditions exceptionnelles, permettre la divulgation du mot de passe principal de leurs utilisateurs, en dépit de leur promesse relative au chiffrement « Zero Knowledge ». Les trois services indiquent avoir déjà implémenté les corrections nécessaires.
Devenus incontournables dans le quotidien de millions d’internautes, les gestionnaires de mot de passe opérés dans le cloud offrent-ils les garanties de sécurité nécessaires et suffisantes ? Une étude menée sous l’égide de l’École polytechnique fédérale de Zurich (ETH Zurich) conclut que trois services parmi les plus populaires du secteur présentaient des vulnérabilités susceptibles de conduire à la divulgation ou à la modification du mot de passe principal du compte de l’utilisateur.
Au cours de leurs travaux, les chercheurs ont exploité un scénario possible, mais très hypothétique : celui d’une prise de contrôle du serveur chargé des interactions avec l’utilisateur final. Dans ce contexte exceptionnel, ils indiquent avoir réussi à mener douze attaques différentes conduisant à une compromission du mot de passe chez Bitwarden, contre sept pour LastPass et six chez Dashlane. Les chercheurs ne remettent pas en cause la sécurité des chiffrements mis en œuvre : d’après leurs observations, c’est principalement au niveau des mécanismes chargés de faciliter la vie des utilisateurs que se situent les vulnérabilités.
Les gestionnaires de mot de passe en ligne invoquent en général le concept de Zero Knowledge (littéralement, « aucune connaissance ») pour rassurer leurs utilisateurs quant à la sécurité de leurs données. Bien qu’il n’obéisse pas à une définition ou à des conditions techniques de mise en œuvre strictes, il suppose que le serveur qui stocke les mots de passe est littéralement incapable d’en connaître le contenu, parce que ce contenu est chiffré et que seul l’utilisateur final dispose de la clé privée indispensable à son déchiffrement.
« Techniquement, Dashlane ne possède pas d’autre clé, mais nous avons bâti un mécanisme de chiffrement qui garantit que votre coffre-fort est sécurisé avec votre clé et que les données du coffre-fort ne sont accessibles que par vous, le propriétaire. C’est pourquoi toutes les opérations sensibles de Dashlane, le chiffrement et le déchiffrement de votre coffre-fort en l’occurrence, sont effectuées localement sur votre appareil. Cela garantit que nous ne les voyons pas sur nos serveurs. », illustre par exemple Dashlane.
Cette promesse tient-elle toujours si le serveur qui héberge les mots de passe est compromis ? L’étude complète, annoncée et publiée par l’ETH Zurich (PDF), répond par la négative. Au cours de leurs travaux, les chercheurs indiquent en effet avoir mené avec succès quatre types d’attaques, exploitant respectivement les fonctionnalités de séquestre utilisées pour la récupération de compte et la connexion unifiée (SSO), les manquements du coffre-fort en matière d’intégrité, les fonctionnalités de partage et les outils dédiés à la rétrocompatibilité.
Les auteurs précisent avoir sélectionné Bitwarden, LastPass et Dashlane à la fois parce que ces derniers peuvent être considérés comme représentatifs du secteur (par leur ancienneté et leur parc de clients, estimé à 60 millions d’utilisateurs cumulés, ou 23 % de parts de marché) et parce que le code de leurs clients logiciels est ouvert (totalement pour Bitwarden, partiellement pour les deux autres), contrairement à celui des solutions d’Apple ou de Google, très populaires puisque intégrées à leurs environnements mobiles.
Au total, 25 attaques ont donc ont été menées avec succès sur l’ensemble des services examinés. « Nous avons été surpris par la gravité des failles de sécurité », commente Kenneth Paterson, l’un des auteurs de l’étude, selon qui la découverte est d’autant plus criante que les gestionnaires de mots de passe constituent, par essence, une cible à très forte valeur perçue pour des attaquants. Les auteurs remarquent par ailleurs que si les conditions de test sont particulières (serveur malveillant), leurs attaques sont réalisées par le truchement d’interactions « normales » de l’utilisateur final avec le service.
Dans la discussion qui suit l’exposé de leurs attaques, ils remarquent que les gestionnaires de mot de passe sont tiraillés entre deux exigences contradictoires que sont la sécurité et le niveau de service fonctionnel rendu à l’utilisateur, qui s’attend à pouvoir récupérer son mot de passe en cas de perte, consulter son gestionnaire sur tous les écrans, ou disposer de fioritures telles que la création d’accès partagés.
« Après un examen plus approfondi, nous avons constaté que les gestionnaires de mots de passe sont loin d’être simples : ils ont évolué pour inclure des protocoles complexes pour la synchronisation, la récupération et la rotation des clés, le partage d’éléments chiffrés et la migration entre différentes primitives cryptographiques [les briques qui fournissent les fonctions de base du chiffrement, ndlr] », remarquent les auteurs. C’est, selon eux, cette complexité accrue qui augmenterait la surface d’attaque potentielle.
Avertis en amont de la publication de l’étude, les trois éditeurs de services concernés ont accusé réception de ces découvertes. « Tous les problèmes identifiés dans le rapport ont été traités », promet Bitwarden qui détaille les réponses apportées dans un rapport de transparence dédié (PDF). Trois ne seront cependant pas corrigés, parce que le remède compromettrait certaines fonctionnalités du service, indique tout de même l’éditeur. Qui profite de l’occasion pour « réaffirmer que Bitwarden n’a jamais subi de violation de données ».
Dashlane salue également ce travail de recherche, qualifié d’exercice utile, et précise avoir apporté tous les correctifs jugés nécessaires dans sa version 6.2544.1 publiée le 5 novembre dernier. Le service en profite pour souligner que les fonctionnalités de partage (basées sur une clé publique) et les mécaniques de synchronisation basées sur l’échange de transactions chiffrées sont des difficultés intrinsèques au service rendu.
« Cette recherche met en lumière plusieurs enseignements :
– Maintenir les méthodes cryptographiques à jour est essentiel pour la sécurité, mais cela introduit une complexité qui doit être gérée avec soin.
– L’authentification de clé publique à grande échelle est un défi connu que notre secteur doit relever. »
Même son de cloche du côté de LastPass, qui indique avoir déjà corrigé l’une des vulnérabilités mises au jour par l’ETH, et ajoute plancher sur la sécurisation des parcours de réinitialisation et de partage, ainsi que sur l’amélioration des mécanismes dédiés au contrôle d’intégrité.
Une démarche à laquelle adhèrent tacitement les chercheurs :
« Les vulnérabilités que nous décrivons sont nombreuses, mais pour la plupart mineures sur le plan technique. Pourtant, elles n’avaient apparemment pas été découvertes auparavant, malgré plus d’une décennie de recherche universitaire sur les gestionnaires de mots de passe et l’existence de multiples audits des trois produits que nous avons étudiés. Ceci motive la poursuite des travaux, tant sur le plan théorique que pratique. »