Vous n'êtes pas identifié(e).
bendia a écrit :Par ailleurs, si tu relis le reste de la discussion du dessus, le firewall pour se protéger (de quoi ?) sur le PC de Mamie, en particulier sous Linux, ben ça ne semble pas servir à grand chose
oui sur le PC de Mamie, en particulier sous Linux, ça ne semble pas servir à grand chose, quoi que.....Enfin bref. En revanche Pour celui qui utilisent un serveur ssh (C'est mon cas) Il est sûrement utile, de connaître le fonctionnement du réseau et de iptable etc....Et j'avoue que c'est particulièrement difficile à comprendre pour moi. Je ne sais pas si c'est facile à expliquer de manière simple, et compréhensible, à quelqu'un qui n'a pas forcément beaucoup de connaissances en informatiques, mais en tout cas, je trouve que ça vaudrait le coup d'essayer.
@JPP: Iptables ne protègent pas, il filtre des paquets ! Iptables est un truc pour sysadmin qui comprend un peu se programme, il est très souple et puissant quand tu le maîtrises. C'est pour cela qu'un front-end a vu le jour, il s'appelle ufw et pour les allergiques au terminal, gufw.
La doc est ton meilleur ami : https://www.inetdoc.net/guides/iptables … ering.html
Par ailleurs, je t'invite à regarder les fichiers /etc/hosts.deny et /etc/hosts.allow. Pour ton histoire de serveur ssh, une authentification par clé permet d'être serein ! Exemple: https://www.sylvaindurand.fr/authentifi … -avec-ssh/ . Dans ce cas, fail2ban et Iptables ne servent à rien !
. Pour ton histoire de serveur ssh, une authentification par clé permet d'être serein !
Pas vraiment. Il suffit d'attaquer le mot de passe de la machine cliente pour compromettre ensuite le serveur.
L'identification par mot de passe et un fail2ban bien configuré constitue un barrage efficace permet d'être prévenu en cas d'attaque.
Chaque siècle fera son œuvre, aujourd’hui civique, demain humaine. Aujourd’hui la question du droit, demain la question du salaire. Salaire et droit, au fond c’est le même mot. L’homme ne vit pas pour n’être point payé ; Dieu en donnant la vie contracte une dette ; le droit, c’est le salaire inné ; le salaire, c’est le droit acquis.
Quatrevingt-treize
Victor Hugo.
Hors ligne
Pas vraiment. Il suffit d'attaquer le mot de passe de la machine cliente pour compromettre ensuite le serveur.
L'identification par mot de passe et un fail2ban bien configuré constitue un barrage efficace permet d'être prévenu en cas d'attaque.
Bonjour Philou92
J'ai cru comprendre aussi que iptable doit être bien configuré pour que fail2ban fonctionne bien, pourrais-tu apporter un peu de lumière sur tout ça, et pourquoi pas, nous faire un petit tuto qui expliquerai ça de manière assez simple ? Je pense que nous t'en serions tous reconnaissants
Trisquel 8 64bits
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Et on active:
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
En ligne
Je ne sais pas si on peut faire une attaque par force brute d'une clé ?
Sauf erreur de ma part, sans user et mot de passe, je ne vois pas trop comment un brut force pourrait forcer quoi que ce soit ! Dans ce cas fail2ban éviterait que tes fichiers logs se remplissent par leurs tentatives infructueuses...
C'est jouer au chat et à la souris de toute façon, les bots sont légions avec donc, une multitude d'IP. Autant leur supprimer le droit de forcer une sécurité standard
------------------------------
Wiki 'buntu
Fail2ban n'est pas a proprement parler un outil de sécurité. L'objectif principal est d'éviter de surcharger les logs du système avec des milliers de tentatives de connexion. Un serveur avec un accès SSH sur le port standard, par exemple, recevra très rapidement des centaines, voire des milliers de tentatives de connexions provenant de différentes machines. Ce sont des attaques par force brute lancées par des robots. Fail2ban en analysant les logs permet de bannir les IP au bout d'un certain nombre de tentatives ce qu limitera le remplissage des logs et l'utilisation de la bande passante. Mais cela n'améliore en rien la sécurité du service concerné. Si l'accès SSH n'est pas suffisamment sécurisé (mot de passe faible par exemple) fail2ban n'empêchera pas un attaquant d'arriver à ses fins.
Autrement dit, utilisez votre temps de travail pour analyser vos configurations et sécuriser vos services plutôt que d''installer et paramétrer des outils d'analyse de logs plus ou moins gourmands en ressources système.
@Jean-Pierre Pinson : déjà, rien que de changer le port par défaut de SSH, tu supprimes quasiment toute les tentatives d'intrusion.
@Philou92 : faut un gros mot de passe, pas facile à mémoriser, donc à écrire quelque part, genre keepass. Est-ce bien différent d'une clé protégée elle aussi par un mot de passe ?
Je ne sais pas si on peut faire une attaque par force brute d'une clé ? Par ailleurs, une clé n'empêche pas de mettre fzil2ban malgré tout
Exact. Mon propos est de souligner qu'aucune des deux solutions mot de passe ou échange de clefs (même si dans le cas du mot de passe il y a aussi échange de clefs) n'est pas plus sereine l'une que l'autre.
Les deux solutions se valent, la deuxième apportant juste le confort de ne pas avoir à taper un mot de passe. Mais si l'attaquant à accès au(x) client(s), le serveur sera compromis. Les postes clients comme les nôtres (style Michu) étant la plupart du temps moins bien protégés (mots de passe faibles) qu'un serveur, c'est probablement par là qu'un attaquant essayera de passer.
Pour la solution avec mot de passe, comme tu l'indique l'utilisation de keepassx (en graphique) ou pass (en ligne de commande) permet de faciliter la tâche et de changer de mot de passe super fort autant que l'on veut. Fail2ban est un frein efficace pour les attaques de force brute. On peut facilement configurer le nombre d'échecs de connexion (exemple 3) au delà duquel l'IP du client est bannie et le temps pendant lequel cette IP est mise en prison(exemples 10mn, une heure, toujours...). En plus des logs, il est aussi possible d'être averti par mail : des IP bannies, de l'arrêt ou du démarrage du service fai2ban . Ce qui permet de prendre rapidement les mesures qui s'imposent en cas d'attaque avérée (changement du mot de passe, durcissement de la configuration fail2ban etc...).
La méthode par échange de clefs sans mot de passe est bonne si le ou les poste(s) client(s) possède(nt) un mot de passe de connexion fort. Du coup c'est kif kif.
A chacun de choisir la méthode ce qui lui convient le mieux.
Chaque siècle fera son œuvre, aujourd’hui civique, demain humaine. Aujourd’hui la question du droit, demain la question du salaire. Salaire et droit, au fond c’est le même mot. L’homme ne vit pas pour n’être point payé ; Dieu en donnant la vie contracte une dette ; le droit, c’est le salaire inné ; le salaire, c’est le droit acquis.
Quatrevingt-treize
Victor Hugo.
Hors ligne
Trisquel 8 64bits
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Ce n'est pas un signe de bonne santé mentale d'être bien adapté à une société malade -Cit. Jiddu Krishnamurti
Hors ligne
Depuis que j'ai mis openwrt sur mon routeur, avec son interface graphique à iptables, je n'ai plus besoin de m'embêter à mettre un parefeu sur le pc et à le configurer ligne par ligne. /me est bien content.
Un parefeu pour un reseau domestique c'est bien, si on héberge des services, http, samba etc ... sinon je n'en vois pas l'utilité.
Un parefeu nat suffit également.
Il faut juste relativiser.
si tu as un portable en déplacement, le pâre-feu est important.
Ce n'est pas un signe de bonne santé mentale d'être bien adapté à une société malade -Cit. Jiddu Krishnamurti
Hors ligne
Tu verra que tu as des ports ouverts meme sans services.
Il est obligatoire d'avoir un firewall.
Ce n'est pas un signe de bonne santé mentale d'être bien adapté à une société malade -Cit. Jiddu Krishnamurti
Hors ligne
- If it works, dont update it.
- You don't know how, just do it, you will learn.
- Test, re-stest, test again, and maybe it will work.
- https://nextcloud.rkn.ovh/index.php/s/3yp93A7oNMPexcp
Hors ligne