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.
Installation de Fail2Ban, une protection indispensable avant connexion
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 [email protected] -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.
Maintenant que le serveur est un peu plus résistant aux attaques, on va pouvoir l’ouvrir sur Internet
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.
Pour comprendre ce qu’il se passe il faut s’intéresser à la manière dont fonctionne cette requête HTTP particulière
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 :
- Configurer un nom de domaine et l’ensemble de ses sous-domaines pour indiquer notre ip fixe
- Configurer notre routeur pour activer le transfert des ports 443 et 80 vers notre serveur
- Installer Caddy pour faire office de reverse proxy
- Tester notre tout premier service (une page html toute simple)
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
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
> nous pourrons installer la plateforme Docker
Heu non faut arrêter docker ça fait tout tourner en root. Préférez Podman en rootless et des comptes de services pour séparer les « services ». Avec Quadlet pour gérer les services (https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html)
@Djip007: Super , tu nous fais un tuto détaillé pas à pas ?
@Djip007 : https://docs.docker.com/engine/security/rootless/
ça fait quelque temps que c’est disponible quand même ;)
Après, docker n’est pas le sujet de cet article et tu l’as presque plus cité dans ton commentaire que dans tout l’article !
Pour en revenir au sujet : fail2ban est un bon outil, mais il est à utiliser en plus d’autres bonnes pratiques :
– Exposer le strict minimum (usage firewall +++)
– Maintenir le système et les applications à jour
– …
@zer oui on est jamais assez protégé, j’ai personnellement ajouté carrément du geoblocking via mon routeur, mon serveur n’est accessible que depuis la France et la Belgique, ça ne fait pas tout, mais c’est déjà ça.
Personnelement, je n’ouvre le ssh que pour les adresses IPv4.
Pour IPv6, on dispose souvent d’un /64, ce qui veut dire que l’on a un nombre presque illimité d’adresse IP et donc on peut probablement faire beaucoup de tests connexion par groupe de 3.
Dans mes log, je constate quand même que certains arrivent à faire plus de 3 tentatives en IPv4. Je suppose qu’ils renouvellent à l’issue de la période de ban.
Mieux que le vieillissant fail2ban, en France on a reaction : https://blog.ppom.me/fr-reaction/
Dommage que ce document n’aille pas plus loin
en rajoutant par exemple la partie apache :
[apache-auth]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache2/error.log
maxretry = 5
findtime = 600
bantime = 3600
ou wordpress
[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 600
bantime = 3600
Parce que sinon le fail2ban ecoute uniquement le port SSH
Avec Fail2Ban penser aussi à vérifier de temps en temps le status actif, y compris avec un redémarrage: Je protège les accès https de ma domotique avec lui via des règles d’analyse de log adaptées et au redémarrage il est systématiquement inactif après échec.
Probable que si un fichier de log manque, ici en tmpfs car c’est un PI dont j’économise la SD, au démarrage de fail2ban ce dernier coince. Ou bien une dépendance systemd à ajouter pour que fail2ban démarre après la domotique, mais avec l’inconvénient si on a d’autres services de ne par exemple plus protéger le ssh si sa domotique a eu un pb au démarrage.
Dans mon cas, je n’expose plus SSH en direct et knockd n’étant pas compatible IPV6 j’ai depuis un script qui ouvre le FW pour SSH sur 30s, déclenché de ma domotique accessible en https. Cela laisse le temps d’ouvrir une connection ssh si un pb dépasse les actions possibles via le webUI de la domotique.
ssh est bien trop ciblé, https beaucoup moins même si cela semble un peu changer: Ce fut longtemps essentiellement limité aux robots de moteurs de recherche qui lâchaient l’affaire sur la page de connexion.
Sinons certains diront qu’il y a le VPN, mais l’inconvénient principal est de ne pas pouvoir se connecter avec juste le contenu de sa tête de n’importe où via n’importe quoi (enfin pas trop qd même!) ou on n’a pas le client VPN dispo. L’autre inconvénient majeur à mon sens est qu’une faille du VPN donne accès à tout son LAN et non un service d’une machine, avec un peu de travail d’escalade de privilège derrière pour arriver à ce que donnera direct le passage à travers le VPN.
Alors fail2ban je l’utilise depuis longtemps, mais il est isolé et tant a été remplacé par des solutions plus communautaire ou centralisé comme crowdsec. C’est le nextgen
J’ai pas encore pris le temps d’y regardé mais j’avais découvert via korben https://korben.info/proteger-wordpress-crowdsec.html
Et depuis il en a fait du chemin et on en a récemment parlé sur https://www.it-connect.fr/reverse-proxy-traefik-integration-de-crowdsec-pour-bloquer-les-attaques/
Intéressant mais question bête : c’est utile uniquement si on ouvre un serveur sur Internet ? Si le seul point d’entrée c’est un port redirect vers un serveur wireguard ça rentre en compte ?
@Gaëtan: Oui, fail2ban est la base.
Après, si on veut aller plus loin, il faut mettre en place un WAF avec, par exemple Bunkerweb. Mais ça nécessite un autre niveau de compétences que fail2ban ! ;)
@Pascal: Personnellement j’ai adopté une politique plus stricte de 0 port ouverts sur l’extérieur. 0, nada.
Si je dois me connecter via SSH c’est au moyen d’un tunnel Wiregard (avec Tailscale) idem pour servir des applications à l’extérieur.
@Franck: Fail2ban est là pour surveiller toutes les entrées. Donc si tu n’as que Wiregard en point d’entrée (bravo au passage, c’est une excellente pratique !) fail2ban pourra toujours surveiller l’activité autour de Wiregard est donc couper des IP un peu insistantes.
Bon ça c’était pour la théorie. En pratique, Wiregard ne fonctionnant qu’avec des clés (il me semble bien ?) il n’y a quasi aucune chance d’attaque par brute force ou même d’attaque par clés random trouvées sur Internet par exemple.
@gUI: Sauf que Wireguard ne log pas il me semble ce genre de mauvaises tentatives ? Vu qu’il ne répond pas si tu n’as pas de clé ? En tout cas il me semble.
À lire tout de même :
https://wiki.archlinux.org/title/Fail2ban
https://doc.ubuntu-fr.org/fail2ban
Ce type d’outil (crowdsec fontctionne exactement de la même manière en moins bien) ne permet que de diminuer le bruit dans les logs, un peu de trafic réseau inutile et d’enrichir les listes noires d’IP malveillantes. Il faut d’abord sécuriser les services actifs avant de songer à installer une surcouche de « sécurité ».
@Djip007: ou mieux VM avec bootc c’est des nid a faille les containers
@Barnabé: Exactement. Après, je crois comprendre que cet article s’adresse à des néophytes, ceci pour héberger des services personnels, donc sans grandes ambitions. Et c’est vraiment « une base ».
Évidemment, comme à chaque fois que l’on parle technique, on a un flot d’avis qui veulent aller plus loin, mais je crois vraiment que ce n’est pas le bon endroit pour ça. Ici, on parle juste d’internautes néophytes qui veulent utiliser leur petit serveur perso depuis l’extérieur, c’est tout, et fail2ban est tout ici indiqué. C’est un excellent compromis entre sécurité, consommation de ressources, et accessibilité. Utiliser des outils plus évolués c’est prendre le risque de perde les utilisateurs, et donc de les voir faire n’importe quoi, ce qui ruinerait l’intérêt de la chose.
@Jle: Oui…
Même si, je suis totalement ouvert à toute proposition sérieuse de rédaction détaillée, captures d’écran et mise à niveau de belles tranches de compétences évoquées ici. Mais souvent ceux qui me disent (je ne vise personne en particulier, les lecteurs ci-dessus veulent réellement prodiguer des conseils) « il vaut mieux utiliser telle configuration » qui nécessite de larges compétences, ne sont pas très chauds pour faire ce que propose Kevin ici. a savoir le travail pédagogique qui va plus loin qu’un namedropping d’un outil réseau exotique.
@faelar: j’ai lu l’article, en gros c’est plus léger sauf pour la conf qui fait 25 fois celle de fail2ban, quand tu as 10 service tu dois commencer a pleurer pour gérer le fichier de conf, sans compter que toute les connexion passe par le produit, ça signifie 2 choses, 1 tu as sacrement confiance, 2 tu as inspecter tout le code est il est carré aussi si ton produit a une faille c’est terminer game over contrairement a f2b qui ne fait que d’interpréter
Je sais pas si tu comprend ou je veux en venir, on passe notre temps a vouloir mettre en oeuvre des nouveaux produit pas ou peu fiable parce-que c’est cool et que tu as gagne 10 mo de RAM (j’abuse mais tu vois ce que je veux dire) le plus important c’est la vision globale dans l’ordre: sécurité, fiabilité, performance : f2b en respecte 2 les 2 plus important alors que ton produit n’en a qu’un, le loin important. Je tient juste a dire que j’ai pas de préférence juste il faut voir la globalité des choses est pas juste une particularité qu’on nous vend, dans ton cas la perf
@Tanega: tu as aussi knockport mais bon tes outil ne sont pas non plus exempte de fail 0 days
@Tanega: C’est intéressant, je ne connaissais pas. Cependant, tu fais confiance à un tiers appelé Tailscale.
Imagine qu’une personne s’introduise sur la passerelle de Tailscale. Est-ce que la configuration en place sera suffisamment robuste pour ne pas exposer ton serveur à l’attaquant ?
@Jle:
C’est justement lorsque l’on s’adresse à des néophytes qu’il convient de ne pas leur donner de mauvaises informations. Le gain de sécurité d’un fali2ban plus ou moins bien configuré sur un accès SSH sécurisé, par exemple, est nul. C’est juste un faux sentiment de sécurité parce que l’on voit les IP des bots qui essaient des combinaisons utilisateur/mot de passe triviales être temporairement bloquées.
Une petite question purement hardware, je veux passer mon optiplex 3050 (i5 7500t 16GB RAM) en server.
J’ai un emplacement m.2 pour le nmve avec l’os et un emplacement SATA.
Je me demandais si mettre un adaptateur SATA 3, pour accueillir 2 ssd ngff 1to, serait pertinent pour la partie stockage?
@Madwill: un adaptateur m2 vers SATA oui après faut juste voir la bande passante de ton port et faire le calcule pour savoir combien de disque SATA tu peux mettre,mais bon deux SATA ça fait du 1go/s max a mon avis tu es bon
@Barnabé: un fail2ban limitera la casse sur un accès ssh par login/mdp (et à priori, le login/mdp c’est ce que fera un néophyte), donc je ne vois pas en quoi sa sécurité serait « nulle ». Un bot ne pourra plus essayer des combinaisons login/mdp à un rythme effréné, et c’est tout l’intérêt de ce tuto. Alors biensûr, si un margoulin alloue de nombreux bots et de multiples IP pour taper spécifiquement sur ton ssh, fail2ban ne fera pas de miracle, mais on parle ici d’un serveur de particulier, pas d’un site/service dont on sait qu’il vaudrait la peine de déployer ce genre de moyens. Faut pas être parano.
Encore une fois, il vaut mieux commencer modestement et bien, plutôt qu’aller trop loin trop vite et prendre le risque de se planter en beauté (et là, c’est le drame). Si qqun suit ce tuto, et s’il n’en sort pas avec un mal de crâne, alors peut être va t-il s’informer un peu plus sur le sujet et, par ex, il utilisera une clef SSH. Le gain en sécu sera important, mais ce n’est pas à portée de tout le monde, loin de là.
@leclerc: Merci pour ton retour, je vais donc aller la dessus.
@leclerc:
Merci pour ce retour, mais je ne suis pas d’accord avec les observations sur reaction même.
1. Je n’ai absolument pas compris ton point sur les connexions. Reaction te permet de suivre un flux de log, le cas le plus « simple » via un fichier. Il realise ensuite l’action que tu as indiqué via ton firewall. C’est exactement le mēme fonctionnement que f2b.
2. Oui j’ai confiance : codé en rust depuis la v2 et j’ai lu (partiellement je te l’accord) le code. Tout est sur framagit. Il a reçu du financement via NGI0 core. La personne qui développe est disponible.
3. Ce qui m’attire plus que les perfs (qui ont aussi leur importance dans un contexte sècuritaire), c’est la flexibilité et justement la configuration. C’est plus propre, templatisable, et donc plus simple à maintenir que celle de f2b. F2b a pour lui son historique de servives préconfigurés.
Bref, j’invitais juste les gens à regarder si reaction peut mieux convenir à leurs besoins que f2b, parce que je trouve le logiciel intéressant.
@Jle: Je suis 100% sur cette ligne.
Un matin, Michel-Ange ne s’est pas levé pour aller démarrer le plafond de la chapelle Sixtine. Commencant un travail gigantesque et demandant une virtuosité extrême de but en blanc. Il avait commencé bien avant, par bien plus petit et plus modestement. Et, progressivement, en mettant la main à la pâte et en accumulant de l’expérience, il a pu devenir l’artiste qui a marqué la postérité.
Certains ne voient pas le but de ce genre de billet sur un blog comme minimachines. L’objectif n’est pas de dégouter les gens de Linux en leur exposant des monstruosités techniques qui vont rendre la tâche de départ absolument titanesque. C’est de leur faire comprendre que les opérations à mener sont assez simples. Leur donner envie de plonger le petit doigt dans le bain et leur montrer que l’environnement n’est pas si inhospitalier qu’on veut bien nous l’expliquer.
Le serveur proposé ne sera pas aussi parfait que celui développé par un administrateur système qui tripatouille des environnements depuis 30 ans. Mais qui en doutait ? Est-ce que le but de ces billets n’est pas de proposer une solution de travail et d’usage, pas un cours magistral sur la sécurité système ? On est sur minimachines.net, pas sur securisetonserveurlinux.com
Bonjour, en plus de Fail2ban, on peut mettre en place du port-knocking : https://wiki.archlinux.org/title/Port_knocking
Perso je ne laisse pas non plus mon serveur (OpenVPN) tout le temps allumé, je l’allume à la demande avec le WOW et l’éteins une fois que j’en ai plus besoin.
@faelar: Mon bute n’etait pas de démonté ton commentaire, si c’est ce qui à été interpreté je suis désolé
Concernant l’interpretation, c’est cela qui me fait dire qu’il devient passe plat au lieu d’interpretteur
start:
– [ ‘iptables’, ‘-w’, ‘-N’, ‘reaction’ ]
– [ ‘iptables’, ‘-w’, ‘-I’, ‘INPUT’, ‘-p’, ‘all’, ‘-j’, ‘reaction’ ]
stop:
– [ ‘iptables’, ‘-w’, ‘-D’, ‘INPUT’, ‘-p’, ‘all’, ‘-j’, ‘reaction’ ]
– [ ‘iptables’, ‘-w’, ‘-F’, ‘reaction’ ]
– [ ‘iptables’, ‘-w’, ‘-X’, ‘reaction’ ]
Mais je me rend compte de mon erreur en faite tu crée une regle que tu utilise, du coup seul le stockage des tes regle dans un seul fichier peut paraitre mauvaise, j’ai vu aussi que la regex de la definition des IP est fausse mais bon c’est un autre sujet
en tout cas si ca te plait c’est le principal et en entreprise faut prendre en compte la sécurité avant le reste, c’etait juste mon message a la base
@Jle:
Il n’est pas question d’utiliser des clefs (même si c’est l’idéal), il suffit d’un mot de passe un peu solide.
Le problème de genre de tutoriel est qu’il va donner l’illusion de la sécurité en faisant installer un outil inutile pour le néophyte (et plutôt difficile à configurer proprement) plutôt que d’apprendre LA BASE : SÉCURISER LES SERVICES. Si un couple nom d’utilisateur mot de passe faible est utilisé, le serveur sera compromis très très rapidement, même avec fail2ban.
@Barnabé: Je ne présuppose pas que mes lecteurs sont des imbéciles en fait. Je suppose qu’ils savent qu’en achetant une serrure à 5€ sur une porte en carton ils seront moins bien protégés qu’avec une serrure a 300€ sur une porte blindée. Qu’ils se doutent qu’en utilisant un mot de passe comme 1234 ou leur date de naissance ils seront moins bien protégés qu’avec un truc plus solide.
Surtout quand, dans la première partie de ce guide, il a été indiqué la nécessité d’une certaine robustesse du mot de passe et la mise en place de clés SSH.
@Barnabé: Sinon, comme toujours, je suis preneur d’un tuto détaillé pas à pas de la meilleure pratique de sécurisation pour un néophyte selon toi.
Salut
pour en rajouter une couche dans la sécurité sans prise de tête, on peut aussi, pour un serveur SSH, mettre en place une authentification double facteurs en plus de l’authentification par clé privée clé publique.
On trouve plein de tutos sur le net, c’est très facile à mettre en place (et cerise sur le gâteau, c’est compatible FileZilla).