Changer le port par défaut ne sert à rien d'autre qu'à réduire le bruit dans les logs (un scan révélera immédiatement le port de ton SSH)
Tu ne ressent pas une certaine contradiction dans ton propos. Changer le port par défaut bloque les attaques sans intelligences qui sont les plus nombreuses. Tu ne peux pas juste balayer ça en disant "ne sert à rien". Met deux machines en ligne avec un compte test / test et un shell à la con; une sur le port 22, une sur un autre port et observe laquelle est pétée le plus vite.
Bref un mot de passe peut tenir un certain temps en fonction de sa complexité mais finira par être découvert tôt ou tard.
Tard est largement suffisant. La complexité d'un mot de passe dépend avant tout de sa présence dans un dictionnaire. Craquer un mot de passe aléatoire par tentative de connexion ssh est trop couteux. Je ne l'ai vu que pour des mots de passes à la con. Ou dans des cas bien particulier (utilisateur ayant le même mot de passe partout, ou presque le même avec des variantes). C'est possible mais je n'y crois pas. L'essentiel en sécurité est quand même de toujours gagner du temps. C'est pour ça que tu met une porte blindé. Pas parce qu'elle est inviolable mais parce qu'elle est trop longue à ouvrir.
Par contre on est bien d'accord que l'authentification par clé est à privilégier.
L'essentiel des risques viennent du vol de mot de passes (keylogueurs sous Windows,transmission par mail …), d'erreurs (on a oublié un compte de test par exemple ou de changer un mot de passe par défaut) ou d'escalade (on passe d'un shell php en nobody à un bash en user, à root grace à sudo ou à suid et de root à noyau par modprobe …)
C'est pourquoi je pense que la base est l'administration des comptes utilisateurs : gestion fine des droits pour chaque service, un utilisateur different par service, l'habitude de tout interdire par défaut, le renouvellement régulier des mots de passes, l'imposition de mots de passes aléatoires, le bannissement des utilisateurs virtuels à la con qui ont tous la même uid, pas de chown/chmod intempestif, pas de sudoers écrit a la louche, pas de chmod +s inconsidéré, pas de /etc/shells contenant tout et n'importe quoi … C'est ça avant tout qui déterminera l'impact d'une attaque et c'est valable pour ssh comme pour le reste.
Quand cela est acquis tu peux commencer à parler de failtoban, de knockd … etc … mais ces outils ne sont rien si tu ne gères pas tes comptes. Si tu ne gères pas tes comptes, tu te fera péter tôt ou tard, failtoban ou pas.
[^] # Re: Sécurité et pdf
Posté par Joris Dedieu (site web personnel) . En réponse au journal Tutoriel d'autohébergement. Évalué à 4.
Tu ne ressent pas une certaine contradiction dans ton propos. Changer le port par défaut bloque les attaques sans intelligences qui sont les plus nombreuses. Tu ne peux pas juste balayer ça en disant "ne sert à rien". Met deux machines en ligne avec un compte test / test et un shell à la con; une sur le port 22, une sur un autre port et observe laquelle est pétée le plus vite.
Tard est largement suffisant. La complexité d'un mot de passe dépend avant tout de sa présence dans un dictionnaire. Craquer un mot de passe aléatoire par tentative de connexion ssh est trop couteux. Je ne l'ai vu que pour des mots de passes à la con. Ou dans des cas bien particulier (utilisateur ayant le même mot de passe partout, ou presque le même avec des variantes). C'est possible mais je n'y crois pas. L'essentiel en sécurité est quand même de toujours gagner du temps. C'est pour ça que tu met une porte blindé. Pas parce qu'elle est inviolable mais parce qu'elle est trop longue à ouvrir.
Par contre on est bien d'accord que l'authentification par clé est à privilégier.
L'essentiel des risques viennent du vol de mot de passes (keylogueurs sous Windows,transmission par mail …), d'erreurs (on a oublié un compte de test par exemple ou de changer un mot de passe par défaut) ou d'escalade (on passe d'un shell php en nobody à un bash en user, à root grace à sudo ou à suid et de root à noyau par modprobe …)
C'est pourquoi je pense que la base est l'administration des comptes utilisateurs : gestion fine des droits pour chaque service, un utilisateur different par service, l'habitude de tout interdire par défaut, le renouvellement régulier des mots de passes, l'imposition de mots de passes aléatoires, le bannissement des utilisateurs virtuels à la con qui ont tous la même uid, pas de chown/chmod intempestif, pas de sudoers écrit a la louche, pas de chmod +s inconsidéré, pas de /etc/shells contenant tout et n'importe quoi … C'est ça avant tout qui déterminera l'impact d'une attaque et c'est valable pour ssh comme pour le reste.
Quand cela est acquis tu peux commencer à parler de failtoban, de knockd … etc … mais ces outils ne sont rien si tu ne gères pas tes comptes. Si tu ne gères pas tes comptes, tu te fera péter tôt ou tard, failtoban ou pas.
Mes deux cents
Joris