Je partage les critiques sur Fail2ban, on en parle systématiquement pour la sécurisation d'un système mais il est assez perfectible. Il reste cependant simple d'accès et fait le job quand même, en gros je voudrais pouvoir m'en passer mais c'est ce qu'il y a encore de mieux.
La solution proposée me parait lourde à comprendre et mettre en place, ce sera source d'erreur pour une personne qui veut reprendre le sujet derrière. Je préfère utiliser un outil bien connu avec une doc abondante et des fichiers de conf bien identifiés qu'éparpiller des fichiers de conf (ou scripts) pour être plus pointu au niveau de la sécurisation. Avis perso of course.
Effectivement, je n'avais pas pensé à ajouter de précision sur la complexité de la solution.
Je viens d'ajouter une note dans l'introduction de la dernière partie, pour préciser que la configuration présentée est plutôt destinée à des utilisateurs avancés.
Merci pour la remarque ;)
Après, comme chaque article de mon blog, c'est avant tout une explication de ce que je fais, en essayant d'expliquer pourquoi et comment. À chacun de prendre les informations qui l'intéressent dedans :P
Ton article est excellent, ma remarque était d'ordre générale, je connais malheureusement trop de monde qui font un copier-coller sans rien comprendre à ce qu'ils font, ce que ça fait et comment ça fonctionne.
A mes yeux, rien de plus efficace pour réduire à 0 les attaques par force brute sur un service que d'utiliser le port knoking. D'autant plus qu'il évite que le daemon SSH soit visible de tous, ce qui permet de se prémunier d'une quelconque 0day sur ssh.
Après, dans un contexte où la configuration ssh doit être standard. Rien de mieux que:
- limité les connexions en ssh à une liste de user spécifique
- désativé la connexion par root
- mettre en place la connexion par clé ssh
- log des connexion valides et envois mail
Hello,
Je partage les critiques sur Fail2ban, on en parle systématiquement pour la sécurisation d'un système mais il est assez perfectible. Il reste cependant simple d'accès et fait le job quand même, en gros je voudrais pouvoir m'en passer mais c'est ce qu'il y a encore de mieux.
La solution proposée me parait lourde à comprendre et mettre en place, ce sera source d'erreur pour une personne qui veut reprendre le sujet derrière. Je préfère utiliser un outil bien connu avec une doc abondante et des fichiers de conf bien identifiés qu'éparpiller des fichiers de conf (ou scripts) pour être plus pointu au niveau de la sécurisation. Avis perso of course.
Tcho !
Effectivement, je n'avais pas pensé à ajouter de précision sur la complexité de la solution. Je viens d'ajouter une note dans l'introduction de la dernière partie, pour préciser que la configuration présentée est plutôt destinée à des utilisateurs avancés.
Merci pour la remarque ;)
Après, comme chaque article de mon blog, c'est avant tout une explication de ce que je fais, en essayant d'expliquer pourquoi et comment. À chacun de prendre les informations qui l'intéressent dedans :P
Ton article est excellent, ma remarque était d'ordre générale, je connais malheureusement trop de monde qui font un copier-coller sans rien comprendre à ce qu'ils font, ce que ça fait et comment ça fonctionne.
Tcho !
C'est un poil complexe mais pas mal du tout.
Un truc qui est rarement abordé est l'utilisation de whitelist dans sshd. Ça limite grandement le risque de brèche. (AllowUsers)
A noter aussi l'option Match de SSH : https://www.blog-libre.org/2015/11/21/loption-match-de-sshd_config/
Tcho !
A mes yeux, rien de plus efficace pour réduire à 0 les attaques par force brute sur un service que d'utiliser le port knoking. D'autant plus qu'il évite que le daemon SSH soit visible de tous, ce qui permet de se prémunier d'une quelconque 0day sur ssh.
Après, dans un contexte où la configuration ssh doit être standard. Rien de mieux que: - limité les connexions en ssh à une liste de user spécifique - désativé la connexion par root - mettre en place la connexion par clé ssh - log des connexion valides et envois mail
Avec ça, tu peux dormir dormir.