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
Bonjour tout le monde, je suis content de voir que mon article semble vous plaire ! Si vous l'avez lu, j'aimerais bien avoir votre retour, que ce soit sur le style d'écriture, le contenu, le design, ce que vous avez aimé, pas aimé, etc…
Merci !!
Pitié, passez à Adminer https://www.adminer.org/ . Il supporte bien plus de moteurs, et comme il n'a besoin que d'un fichier, il peut très facilement être renommé, administré, voire enlevé de vos serveurs.
D'ailleurs, vous ne devriez jamais avoir ce genre d'outils en prod
Sinon il y a un truc, dont je ne saurais garantir l'efficacité, qui consiste à ajouter un délai via PAM en cas de tentative échouée. C'est la méthode 3 décrite dans cette réponse : https://unix.stackexchange.com/a/105559
Mais je ne suis pas sûr que les outils de brute-force attendent un nouveau prompt du password pour lancer une nouvelle tentative de connexion.
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.
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
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.
Ça semble très sympa. Mais le fait de stocker la confie en local et d'avoir donc des choses différentes d'une machine à l'autre me rebute un peu.
C'est ce que j'apprécie beaucoup chez Shaarli, d'un de mes ordi d'une tablette ou du téléphone, j'accède à tous mes favoris !
Rien à stocker, au lieu de t'envoyer un mail avec l'info, ton serveur envoie l'info à cloudflare. Du coup tu n'as rien à faire du tout. Bien sûr il faut un cron qui lance le script sur ton serveur de temps en temps, mais je crois comprendre que tu as déja mis ça en place avec ta solution actuelle, non ?
L'article pourrait être plus clair je pense. Je ne saisis toujours pas l'intérêt de recevoir l'adresse ip de mon routeur par email…
une meilleure méthode à mon sens serait de mettre son nom de domaine sur cloudflare puis de créer un sous domaine. Enfin son script, au lieu d'envoyer un mail dont l'utilité peut être débattue, pourrait mettre à jour l'adresse ip du sous domaine avec l'ip du routeur grâce à l'api de cloudflare. Il reproduirait alors parfaitement la fonctionnalité de DynDNS
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.
Bonjour tout le monde, je suis content de voir que mon article semble vous plaire ! Si vous l'avez lu, j'aimerais bien avoir votre retour, que ce soit sur le style d'écriture, le contenu, le design, ce que vous avez aimé, pas aimé, etc… Merci !!
+1 ! Cependant phpMyAdmin est encore largement utilisé chez les hébergeurs et très connu historiquement.
Tcho !
Pitié, passez à Adminer https://www.adminer.org/ . Il supporte bien plus de moteurs, et comme il n'a besoin que d'un fichier, il peut très facilement être renommé, administré, voire enlevé de vos serveurs. D'ailleurs, vous ne devriez jamais avoir ce genre d'outils en prod
Sinon il y a un truc, dont je ne saurais garantir l'efficacité, qui consiste à ajouter un délai via PAM en cas de tentative échouée. C'est la méthode 3 décrite dans cette réponse : https://unix.stackexchange.com/a/105559
Mais je ne suis pas sûr que les outils de brute-force attendent un nouveau prompt du password pour lancer une nouvelle tentative de connexion.
A noter aussi l'option Match de SSH : https://www.blog-libre.org/2015/11/21/loption-match-de-sshd_config/
Tcho !
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 !
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
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)
Yo,
Elle concerne quoi le mise en prod si c'est pas trop indiscret ? (Je veux également les adresses IP des machines, les clés SSH, les mots de passe stp)
Tcho !
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 !
Pour ma part, grosse mise en prod de prévu jeudi soir, donc je prépares le tout.
Surtout 100% open source et sans trackers (cette fois-ci)
Compréhension et mise en pratique de l'architecture Master / Slave MySQL
J'ai pris du repos ! Ca fait du bien ! Mais la semaine 02 semble déjà dur !
Ça semble très sympa. Mais le fait de stocker la confie en local et d'avoir donc des choses différentes d'une machine à l'autre me rebute un peu. C'est ce que j'apprécie beaucoup chez Shaarli, d'un de mes ordi d'une tablette ou du téléphone, j'accède à tous mes favoris !
Rien à stocker, au lieu de t'envoyer un mail avec l'info, ton serveur envoie l'info à cloudflare. Du coup tu n'as rien à faire du tout. Bien sûr il faut un cron qui lance le script sur ton serveur de temps en temps, mais je crois comprendre que tu as déja mis ça en place avec ta solution actuelle, non ?
L'article pourrait être plus clair je pense. Je ne saisis toujours pas l'intérêt de recevoir l'adresse ip de mon routeur par email… une meilleure méthode à mon sens serait de mettre son nom de domaine sur cloudflare puis de créer un sous domaine. Enfin son script, au lieu d'envoyer un mail dont l'utilité peut être débattue, pourrait mettre à jour l'adresse ip du sous domaine avec l'ip du routeur grâce à l'api de cloudflare. Il reproduirait alors parfaitement la fonctionnalité de DynDNS