La définition d'un mot de passe très fort est-elle suffisante pour sécuriser un SSH sur le port 22?

8

En supposant que personne ne puisse me voler le mot de passe réel, est-il pratiquement impossible à 99,9% d'utiliser SSH pour pénétrer mon serveur exécutant SSH sur un port standard en utilisant très fort (24 symboles contenant des majuscules, des chiffres en minuscules, des parenthèses, des soulignements, des dollars, périodes, etc. et pas de mots en langage humain) mot de passe?

security ssh

— Ivan
source

2

Je ne posterais pas cela comme réponse parce que beaucoup de gens semblent être en désaccord avec moi pour une raison quelconque, mais changer le port en quelque chose de non standard aidera également à diminuer la surface d'attaque. Vous aurez évidemment besoin d'utiliser le mot de passe fort et de maintenir le serveur à jour pour fournir une réelle sécurité, mais cela aidera à éviter les analyses courantes des ports ouverts.

— Paul Kroon

3

bien que rares, il y a encore des exploits de 0 jour ... donc on ne sait jamais. peut-être pouvez-vous limiter l'accès au port 22 [au niveau du pare-feu] à quelques hôtes / réseaux seulement?

ou peut-être que vous pouvez opter pour la sécurité par l'obscurité et implémenter le port knocking ?

— pQd
source

1

Je pense que frapper au port est alors la meilleure idée. Limiter les réseaux / hôtes est un échafaudage, je suis très mobile et j'ai tendance à utiliser différents réseaux wifi et 3G.

— Ivan

8

N'oubliez pas que VOTRE mot de passe peut être très fort tandis que d'autres utilisateurs peuvent avoir des mots de passe vraiment faibles. Mettez AllowGroupsou AllowUsersdans /etc/ssh/sshd_configpour désactiver l'accès ssh pour les autres utilisateurs.

N'oubliez pas non plus que votre mot de passe est peut-être trop sûr: ce mot de passe sera presque certainement écrit.

Cela dit, je pense que vous êtes assez en sécurité; si vous combinez avec port frappant ou alors vous êtes très en sécurité.

— Moritz Both
source

1

+1 pour AllowUsers ... définitivement un plus.

— Paul Kroon

1

Et pour faire bonne mesure, ajoutez fail2ban

— tegbains

4

Tout dépend de la vitesse à laquelle un attaquant peut marteler votre port tcp / 22 pour les connexions. Si vous n'utilisez pas quelque chose pour mettre fin à de telles connexions répétées, à temps n'importe quel mot de passe peut être découvert. Dans ce cas, le temps sera très long. Des mois de martèlement constant. Dans les journaux SSH que j'ai parcourus, j'ai vu peu de coups dirigés contre des comptes spécifiques, et beaucoup de coups à la porte à la recherche de mots de passe faibles.

Cependant, vous ne pouvez pas supposer que tous les attaquants sont occasionnels. Quelqu'un qui vous cible spécifiquement aura l'investissement à attendre plusieurs mois pour s'introduire. C'est pour des raisons comme celle-ci que la clé partagée est préférée lorsque cela est possible. Le mot de passe que vous décrivez est très probablement trois-neuf impossible à déchiffrer (dans des délais raisonnables). Je ne retiendrais pas mon souffle pendant cinq neuf.

— sysadmin1138
source

1

"Tout dépend de la vitesse à laquelle un attaquant peut marteler votre port tcp / 22 pour les connexions. Si vous n'utilisez pas quelque chose pour mettre fin à de telles connexions répétées" - N'est-il pas configuré dans toutes les distributions courantes par défaut de nos jours?

— Ivan

2

@Ivan Malheureusement, non, ce n'est pas le cas. apt-get install denyhosts(basé sur Debian) pkg_add -r denyhosts(FreeBSD) est l'une des premières choses à faire sur une nouvelle boîte.

— Pete

2

Pas toujours. Ubuntu ne l'a pas par défaut et ni openSUSE ni Fedora / Centos. Des packages prédéfinis existent pour les trois, mais vous devez prendre des mesures positives pour l'activer.

— sysadmin1138

3

Utilisez denyhosts. Pensez également à utiliser une connexion basée sur des clés plutôt qu'un mot de passe.

— Pete
source

Oui, j'utilise une clé (et avec une bonne phrase de passe symbolique aléatoire, écrite uniquement dans mon esprit et avec une date d'expiration qui a du sens). Mais il y a toujours un mot de passe pour l'utilisateur que j'ai défini comme je l'ai décrit.

— Ivan

1

Déplacer sshd vers un port non standard serait probablement trivial à ajouter à votre configuration, et cela éliminerait probablement 99% du trafic du bot ssh. Pourquoi vous exposer à toutes les attaques par force brute alors que vous pouvez vous cacher si facilement. ;-)

Je recommande également généralement de configurer sshd pour utiliser uniquement l'authentification basée sur une paire de clés SSH, s'il doit être exposé à Internet en général. Tant que vous gardez votre clé privée sécurisée, il est presque impossible pour les méchants de s'authentifier comme vous auprès du serveur.

Comme un autre commentateur l'a déjà souligné, cela ne vous protège pas contre les exploits de 0 jour dans sshd lui-même. C'est toujours une bonne idée de limiter le trafic aux seules machines qui doivent se connecter via des règles de pare-feu.

— Patrick Heckenlively
source