Question:
Pourquoi l'accès externe à un serveur via SSH est-il considéré comme non sécurisé?
user142998
2017-03-25 09:52:43 UTC
view on stackexchange narkive permalink

J'ai récemment eu une conversation avec mon patron et un sous-traitant informatique qu'ils utilisent. Ma demande d'autoriser l'accès extérieur à une machine sur le réseau via SSH a été refusée au motif que SSH n'est pas sécurisé. J'ai demandé une explication et je ne l'ai malheureusement pas comprise - le contractant a déclaré que SSH n'était pas sécurisé mais ne savait pas pourquoi.

Pourquoi SSH n'est-il pas sécurisé? Il semble y avoir quelque chose que j'ai manqué au cours de notre conversation et que je veux désespérément comprendre.

Ma proposition pour SSH comprenait l'utilisation de l'accès basé sur les clés et de fail2ban.

MISE À JOUR: Pour expliquer la discussion, dès que j'ai demandé à l'entrepreneur pourquoi il pensait que SSH n'était pas sûr de lui, il a dit, textuellement, "Je ne sais pas" et a procédé avec colère avec un ton de voix accru pour le reste de la conversation. J'ai essayé de me dégager mais j'ai dû repousser quelques hommes de paille pour éviter d'avoir l'air complètement incompétent à cause de son harcèlement. J'ai présenté les arguments que la plupart des bonnes réponses à cette question font ci-dessous et ils ont été rapidement ignorés.

Ces mêmes réponses sont extrêmement peu convaincantes si elles sont vues avec un œil sceptique. Je ne sais pas si ma question (qui est celle de l'entrepreneur en TI) impose un fardeau de preuve déraisonnablement élevé qui ne pourra jamais être satisfait, dans les deux sens. Si tel est le cas, il serait sage d'en parler.

Je pense que ce n'est pas tellement "non sécurisé" que c'est que l'accès SSH externe est moins sécurisé que * aucun * accès externe.
Il est également bon de prendre en compte le fait que SSH est assez ancien (et soigneusement testé) mais que l'utilisation des anciennes versions (protocole ssh1 par exemple) n'est pas très sûre.le protocole ssh2 plus récent (et à ma connaissance uniquement utilisé) peut être assez sécurisé, cela dépend des clés / chiffrements / sécurité de l'appareil sur sa sécurité.En général, elle est plus sécurisée qu'une connexion HTTPS en raison des valeurs par défaut qui utilisent le plus haut niveau de connexion TLS possible pour chaque connexion (donc TLS 1.2 / 1.3 pour la plupart des connexions), ce qui n'est pas possible pour une utilisation généralisée sur les sites Web.
Pour répondre à la question, de manière spéculative, l'administrateur de la sécurité vous a dit qu'il ne vous faisait pas confiance pour l'ensemble du système de son entreprise, mais vous l'a dit poliment.Ce n'est pas que SSH n'est pas sécurisé, mais qu'un hacker pourrait pirater votre ordinateur, puis accéder au réseau de l'entreprise, et ils n'auraient aucun moyen de connaître la différence.Pour un troll mineur, essayez de demander un compte `rlogin` et voyez si cela vous mène quelque part.
Six réponses:
#1
+70
Trey Blalock
2017-03-25 11:08:09 UTC
view on stackexchange narkive permalink

SSH n'est généralement pas considéré comme non sécurisé en soi, mais il s'agit d'un protocole administratif et certaines organisations ont besoin de deux ou plusieurs couches de contrôle pour accéder à une console d'administration . Par exemple, se connecter via un VPN d'abord, puis ouvrir une session SSH qui se connecte via ce VPN. Cela fournit simplement plusieurs couches de défense en profondeur et empêche vos systèmes d'être directement affectés par les dernières vulnérabilités SSH.

Remarque: ce n'est PAS une faiblesse de SSH lui-même et de nombreuses organisations continueront d'exposer SSH sur des ports TCP élevés pour une utilisation en tant que serveurs SFTP, puis disposeront d'un script pour déplacer les données vers et à partir de cela système (ne permettant pas au serveur SSH / SFTP externe de se connecter au reste de son réseau).

Tous les protocoles ont finalement des vulnérabilités donc si vous pouvez exiger l'utilisation de deux protocoles différents (c'est-à-dire IPSEC VPN et SSH) et restez discipliné sur les efforts de correction lorsque des vulnérabilités sont découvertes, alors la fenêtre de temps où des vulnérabilités connues existent dans les deux protocoles en même temps sur votre réseau devrait être très petite. Statistiquement, la nécessité d'utiliser deux protocoles devrait réduire la durée pendant laquelle un seul protocole serait exposé avec une vulnérabilité connue (en supposant que vous corrigiez / corrigiez réellement les vulnérabilités).

En tant que graphique de texte médiocre, regardez ce qui suit:

  Heure --- > IPSEC ------------------ ------ ---------------- SSH --------- ------------------ -----------  

Par rapport à avoir juste SSH, ou un VPN, par lui-même:

  SSH ----- ---- -----------------------------  

Dans le premier exemple où une vulnérabilité SSH est apparue, il n'y en avait pas pour IPSEC et vice versa donc il n'y a jamais eu de moment, dans cet exemple grossier, où vos systèmes avaient des vulnérabilités aux deux couches. Cette défense en profondeur est ce qui protège le système derrière ces protocoles qui peuvent parfois avoir des vulnérabilités.

Dans le deuxième exemple, SSH en lui-même, dès qu'il y a une vulnérabilité, ou une violation de mot de passe, ou tout autre problème, un attaquant peut accéder directement à votre système vulnérable pendant la fenêtre d'exposition.

Je demanderais si d'autres protocoles administratifs sont exposés et si tel est le cas, vous pouvez remettre en question le biais technologique, mais il est fort probable que vous apparteniez à une organisation qui ne permet pas d'accéder directement à des protocoles administratifs Internet.

@R0b0t1 - Dites-leur de copier toutes les données sur un disque dur et de graver toutes les copies restantes.Creusez un trou de 30 m, placez le disque en bas et remplissez de béton.Cela rendrait certainement les données plus sûres qu'elles ne le sont actuellement.Ils veulent payer en convivialité pour la sécurité, c'est donc un plan tout à fait valable.
@R0b0t1 Pourquoi ne pas simplement accéder au serveur via SSH une fois sur le VPN?Cela devrait satisfaire les besoins de chacun: c'est le plus sécurisé de ce type de configuration (et ce que fait mon entreprise, une société de services financiers), vous permet d'accéder à ce serveur en dehors du bureau, et atténue les situations où une faille est trouvée dansle serveur OpenSSH ou le protocole SSHv3.
Cette réponse montre clairement, pour moi, que l'objection n'est pas "SSH n'est pas sûr", mais est vraiment "Utiliser uniquement SSH n'est pas suffisamment sécurisé."Il n'atteint pas suffisamment la triade de sécurité des données de confidentialité, d'intégrité et de disponibilité pour la préférence de l'objecteur.
Le chiffrement @NanbanJim assure la confidentialité, le code d'authentification des messages assure l'intégrité.Vous pouvez utiliser un mode de chiffrement AE pour prendre soin de l'intégrité ou du MAC (hmac ou umac) Je crois qu'un serveur et un client SSH bien renforcés peuvent facilement atteindre le trio de sécurité des données
@rhymsy Et c'est votre prérogative.Vous n'êtes pas celui qui vous objecte.
#2
+29
Steve Sether
2017-03-25 21:22:51 UTC
view on stackexchange narkive permalink

J'ai demandé une explication et je ne l'ai malheureusement pas comprise - le contractant a déclaré que SSH n'était pas sécurisé mais ne savait pas pourquoi.

Pourquoi SSH n'est-il pas sécurisé? Il semble y avoir quelque chose que j'ai manqué au cours de notre conversation que je veux désespérément comprendre.

Traiter la sécurité comme un binaire «sécurisé» ou «non sécurisé» reflète une mauvaise compréhension de la sécurité; la sécurité est toujours un continuum, et rien n'est parfaitement sécurisé.

L'entrepreneur en question semble avoir un grand manque d'informations sur SSH s'il ne peut même pas expliquer pourquoi SSH n'est pas sécurisé, mais croit fermement c'est tout. L'ignorance engendre la peur, et je suppose que l'entrepreneur réagit à la peur plutôt qu'à la connaissance.

SSH n'est pas moins sécurisé que les VPN des principaux fournisseurs. Les VPN ont également des failles de sécurité et ne sont pas «faits de magie». Nous le savons grâce aux différentes fuites de la NSA, et il n'y a aucune raison de croire que ces vulnérabilités sont uniquement entre les mains de la NSA.

La vraie question se résume au besoin d'accès vs besoin de sécurité, pas un protocole sur un autre. L'accès à distance diminuera probablement quelque peu votre sécurité. Deux méthodes d'accès à distance réduiront davantage votre méthode de sécurité. Le fait d'activer une ou plusieurs méthodes d'accès à distance doit être jugé par les compromis impliqués, et non par le maintien d'un faux sentiment de «sécurité» en tant que concept binaire.

L'entrepreneur qu'ils utilisent semble n'avoir pas ou très peu de connaissances Unix ou Linux et prendre principalement en charge Windows.J'ai essayé de proposer l'argument selon lequel Windows serait sensible aux mêmes arguments présentés contre l'utilisation de SSH ("l'absence de preuve n'est pas une preuve d'absence" en ce qui concerne les vulnérabilités de sécurité existantes) mais, encore une fois, je suis apparemment mal informé car c'estpas le cas.
Ici, je dois être d'accord.Je n'entends ces trucs que de personnes qui ne savent pas ce qu'est vraiment ssh.
+1 "rien n'est parfaitement sécurisé" - On pourrait imaginer un système parfaitement sécurisé, sauf que personne ne pourrait y accéder.Les mots de passe ou même les clés sont des vulnérabilités insolubles, dans certains cas, mais ils fournissent toujours un accès et tout point d'accès est une vulnérabilité potentielle.
#3
+11
WhiteWinterWolf
2017-03-25 18:27:36 UTC
view on stackexchange narkive permalink

Qu'est-ce qui n'est pas sécurisé, exactement?

Pour le dire brièvement, "Pourquoi l'accès externe à SSH est-il considéré comme non sécurisé?" : ce n'est pas "SSH" qui n'est pas sécurisé, c'est la partie "accès externe" de votre question qui l'est.

SSH n'est qu'un moyen technique parmi d'autres pour ouvrir votre réseau interne vers l'extérieur monde (qui est très risqué). Elle peut être utilisée, soit de manière autonome, soit associée à d’autres technologies, afin de mettre en œuvre votre politique d’accès à distance.

La politique d’accès à distance est la définition formelle indiquant qui peut accéder à quoi, quand et d’où elle définit toutes les règles qui seront ensuite mises en œuvre à l'aide de divers contrôles techniques qui, à leur tour, fourniront des services d'authentification, d'autorisation et d'audit appropriés. Tout cela, bien sûr, doit être correctement documenté et entretenu.

Bien sûr, vous pouvez simplement continuer sans toutes ces charges administratives et de maintenance, mais voici le point: prendre un tel raccourci est précisément ce que ne serait pas sûr dans votre question.

Alors, pourquoi l'accès externe à SSH est-il considéré comme non sécurisé? Parce qu'il en coûterait trop cher pour le mettre en œuvre correctement en ce qui concerne le retour sur investissement attendu par l'entreprise.

Question sur le coût

Le coût ici ne consiste pas à acheter un logiciel, il s'agira simplement de payer le temps aux gens d'abord pour concevoir et configurer ce service, puis pour le maintenir temps (pendant que ces personnes sont occupées à cela, il y a d'autres tâches qu'elles ne feront pas). Le coût réel sera donc très dépendant du salaire, des compétences actuelles et de la complexité de votre infrastructure actuelle.

D'un point de vue technique, l'authentification par clé et fail2ban est une bonne solution bien documentée. L'exécuter sur des ports élevés le fera également sortir de la plupart des bots. Mais cela n'empêchera pas par exemple un véritable employé de se connecter au réseau interne à partir de son ordinateur familial débordant de vers, virus et backdoors de toutes sortes, constituant ainsi involontairement le réseau de l'entreprise. C'est l'un des risques auxquels vous devrez peut-être faire face.

Du point de vue de la gestion, il y a de fortes chances que le «patron» soit plus intéressé par la pondération (monétaire) des divers risques par rapport au rendement attendu des investissements: coûtera l'installation et la maintenance? Combien cela permettra à l'entreprise de gagner ou d'économiser? Combien cela pourrait-il coûter en cas de catastrophe?

Le risque est toujours là, avec tout. Si vous parvenez à montrer que d'un point de vue commercial, l'ouverture du réseau interne (ou peut-être de certaines parties bien définies de celui-ci, ce qui serait un moyen efficace de réduire le risque) sera une opération rentable pour l'entreprise, vous en aurez fait la moitié. sinon la majeure partie du voyage. Comment le faire sera alors juste une question de choix techniques en fonction de ce que vous avez prévu de faire. Mais vous devez certainement résoudre la question d'un point de vue commercial et fonctionnel avant de rentrer dans les détails techniques.

Quelle est la bonne mise en œuvre?Quel est le coût de la mise en œuvre par défaut?Je proposais un système impliquant l'authentification par clé et fail2ban.
@R0b0t1: Bonjour, l'estimation du coût d'un changement dans une entreprise peut être complexe à très complexe selon l'entreprise, et va bien au-delà du coût d'achat d'un logiciel.J'ai ajouté une nouvelle section à ma réponse, j'espère que cela pourra vous être bénéfique de quelque manière que ce soit :)!
Eh bien, la mise en place du service m'a pris environ 30 minutes.La maintenance est un autre problème, mais j'aurais pu former l'un des ingénieurs à le faire ou j'aurais pu être de garde (ce à quoi ils ont certes une certaine résistance).Je crois avoir suivi la plupart des conseils de votre commentaire w.r.t.Coût.Malheureusement, mon employeur a eu l'impression que son réseau était plus sécurisé sans accès SSH distant quelle que soit la façon dont il a été configuré, et a basé son choix de l'interdire sur cette base.
@R0b0t1: Ne pas avoir de porte est en effet plus sûr que d'avoir une porte, aussi sûre qu'elle puisse l'être.Bien que la configuration de SSH et de fail2ban puisse être rapide à une échelle personnelle, pour un réseau d'entreprise, vous devrez peut-être également configurer la compartimentation du réseau pour garantir que les utilisateurs SSH ne peuvent pas accéder à plus qu'ils ne le devraient, et un audit approprié pour détecter une activité inhabituelle.Les risques sont là, c'est un fait, et s'il n'y a pas d'avantage commercial significatif à autoriser un tel accès, alors la réaction attendue est que la direction rejette la demande.
Cette ligne de pensée semble encore être un raisonnement spécieux.Comment, exactement, les mécanismes d'authentification de SSH seraient-ils subvertis?SSH s'appuie sur une technologie mature qui n'est pas considérée comme suspecte ailleurs.La spéculation dans la veine du phishing n'est pas quelque chose d'unique à SSH et, en tant que telle, je pense qu'elle ne répond pas à ma question
@R0b0t1: Premier exemple qui me vient à l'esprit et que j'ai brièvement mentionné précédemment: avec SSH, un employé (paresseux) est libre de copier sa clé SSH sur l'ordinateur familial par exemple et d'ouvrir une connexion au réseau d'entreprise à partir de cette machine non fiable.Certaines solutions VPN alternatives permettent d'appliquer une politique sur la machine client et refuseront l'accès ou fourniront un accès limité si la machine est inconnue, n'a pas la dernière mise à jour appliquée, a l'antivirus désactivé, etc. AFAIK il n'y a aucun moyenpour implémenter de telles choses avec un accès SSH standard.
Encore une fois, ce n'est pas un problème propre à SSH.Un VPN (apparemment considéré comme plus sécurisé, même s'il est utilisé seul) souffrirait du même problème.
#4
+11
Branden Jensen
2017-03-27 06:55:29 UTC
view on stackexchange narkive permalink

Premièrement, quiconque dit "ce n'est pas sûr, mais je ne sais pas pourquoi" nie complètement le droit de parler à partir d'une position d'autorité en la matière.

Quelques personnes ont a abordé les raisons pour lesquelles l'ouverture d'un vecteur d'attaque est souvent déconseillée, mais voici quelques éléments qui annulent le besoin de peur s'il est utilisé correctement:

  • VPN dans le réseau, puis SSH sur l'appareil
  • Utiliser un port non standard
  • Utiliser des paires de clés privées
  • Mettre en œuvre des outils tels que fail2ban
  • Refuser les connexions utilisateur root

Honnêtement, une seule de ces options rend le piratage beaucoup plus difficile. Mettre en œuvre au moins deux signifie que vous pouvez utiliser SSH sans souci.

Cet entrepreneur informatique devrait vraiment envisager un nouveau métier.

Pourquoi utiliser un VPN est-il plus sûr que d'utiliser SSH directement avec des clés?Surtout si le VPN vous fait pénétrer dans les défenses périphériques du réseau cible et ouvre éventuellement toute une panacée d'ordinateurs cibles.
#5
+8
Andrew
2017-03-25 10:02:45 UTC
view on stackexchange narkive permalink

SSH n'est pas non sécurisé, mais ce n'est pas nécessairement une bonne pratique d'exposer SSH à Internet par peur d'un compromis à distance. En ouvrant SSH au monde, vous invitez des visiteurs inutiles qui exécuteront des bots contre votre déploiement en essayant de l'obtenir. Même s'ils ne réussissent pas, c'est toujours inutile; s'ils réussissent, vous pourriez être dans un monde de souffrance. Si le système exposé est compromis, il est facile d'installer une porte dérobée persistante et d'utiliser ce système comme point de levier pour attaquer d'autres personnes sur le réseau.

Si vous l'exposez sur Internet, désactivez l'authentification par mot de passe et désactivez-la connexion root, n'autorisez que l'accès par clé. Si vous devez autoriser les mots de passe, ne l'autorisez pas pour root et utilisez une solution à 2 facteurs avec des mots de passe générés aléatoirement.

Comment ces robots pourraient-ils réussir?J'ai lu qu'il est préférable de désactiver les mots de passe et d'utiliser l'authentification par clé.L'authentification par clé n'est-elle pas sécurisée?
Un bot ordinaire n'obtiendra pas un mot de passe sécurisé ou une authentification par clé.Un attaquant déterminé commencerait à essayer de hameçonner un mot de passe ou même à rechercher des exploits contre la version spécifique de SSH.Personnellement, j'ai un VPS qui a 22 ouvert et je l'utilise régulièrement, mais il est également configuré avec l'authentification par clé et fail2ban pour aider à bloquer les bots.Mon réseau domestique a juste un VPN qui doit être activé avant de pouvoir accéder à SSH.
Ma solution proposée impliquait l'authentification par fail2ban et par clé.Pourquoi cela pourrait-il encore être considéré comme peu sûr?Malheureusement, tout ce que vous avez fait est d'indiquer en termes vagues que vous pensez que SSH n'est pas sécurisé, sans aucune preuve qu'il en est ainsi.Je me rends compte que cette conversation se déroule généralement à l'inverse, mais j'avais l'impression que SSH, correctement configuré, était considéré comme sécurisé, en partie parce qu'il est basé sur des technologies de transport sécurisées considérées comme matures.
J'ai dit que ce n'était pas une bonne pratique.La sécurité n'est rien de plus que le risque contre la récompense.Le risque est de vous exposer à des jours 0 inconnus ou à un ordinateur portable d'un utilisateur compromis qui expose les clés.Cela est vrai pour tous les services exposés.De toute évidence, n'importe quel ordinateur portable peut être utilisé pour infiltrer un réseau, mais le fait d'avoir un port déjà ouvert comme ssh facilite cet accès une fois obtenu.Seuls vous et votre organisation pouvez déterminer si le risque en vaut la peine.J'ai déjà déclaré que SSH était ouvert sur mon VPS, je ne fais que fournir un aperçu de * certaines * raisons pour lesquelles c'est une mauvaise pratique.
SSH est une méthode d'accès à distance.La sécurité de celui-ci doit être comparée à d'autres méthodes d'accès à distance.En quoi SSH est-il moins sécurisé qu'un VPN?
Oui.La sécurité est entièrement un jeu basé sur les risques.Vous devez analyser votre environnement, vos configurations et vos besoins afin de déterminer quel risque vaut la peine d'accepter et dans quelle mesure un service doit être configuré pour être considéré comme sécurisé dans votre environnement.Je dis simplement que c'est une mauvaise pratique à faire, non pas que cela ne peut pas être fait pour être une méthode d'accès à distance sécurisée.Regardez autour de vous des centaines et des milliers de serveurs mal configurés avec SSH qui agissent comme des centres de spam pour les sites de courrier électronique et de phishing.Historiquement, il a été mal configuré et laissé à des fins malveillantes.
@R0b0t1 Des erreurs de configuration se produisent.Par exemple, quelqu'un met à jour OpenSSH et réinitialise accidentellement la configuration pour permettre l'authentification par mot de passe et permettre à root de s'authentifier.Exiger un accès via un VPN * avant * d'avoir accès à SSH est une défense en profondeur, et pas nécessairement une exigence de sécurité déraisonnable.
@StephenTouset: J'ai reçu plusieurs commentaires dans la même veine que le vôtre.Il manque le point de la question que j'ai posée car de tels problèmes ne sont pas du tout liés à SSH et existent pour tout mécanisme d'authentification.
OpenSSH et le protocole SSH sont, pour autant que nous le sachions et indépendamment de tout le reste, sécurisés - l'entrepreneur impliqué avait tout simplement tort sur ce front.Cela dit, la notion fondamentale d'exécuter un processus appartenant à la racine qui donne un accès shell à une machine sur une interface réseau publique est, par certaines mesures, un * risque * de sécurité inacceptable qui justifie une défense en couches.Cela ne manque pas du tout le point de votre question: l'entrepreneur a mal exprimé et surestimé ses préoccupations techniques, mais l'origine probable de ses préoccupations est raisonnable.
#6
+6
IAmBarry
2017-03-26 18:11:56 UTC
view on stackexchange narkive permalink

SSH peut être considéré comme non sécurisé, car votre organisation n'a peut-être pas mis en place de politiques pour contrôler les informations d'identification.

Au fil du temps, les employés vont et viennent. Ils peuvent également changer de rôle. S'il n'y a pas de mécanisme pour désactiver l'accès SSH en cas de besoin, SSH ne serait pas sécurisé. Cela n'indique pas un problème avec le protocole ou le logiciel. C'est plutôt un problème général applicable à tout accès distant.

Toute organisation autorisant l'accès SSH voudrait probablement empêcher la compromission de mot de passe par une attaque par dictionnaire (en plus de s'assurer que le logiciel SSH est à jour). Ils pourraient choisir de limiter les tentatives de connexion infructueuses peut-être par IP. Ils peuvent choisir de ne pas autoriser du tout la connexion par mot de passe via SSH ou, comme d'autres l'ont mentionné, une authentification à deux facteurs. Cependant, s'ils n'ont pas de politique, la meilleure politique peut être de ne pas autoriser l'accès à distance SSH.

Si le contractant ne sait pas pourquoi il pourrait être peu sûr, il peut en fait prendre la meilleure décision pour ne pas autoriser l'accès à distance.

La dernière ligne est très pertinente: "Si l'entrepreneur ne sait pas pourquoi il pourrait être peu sûr, il peut en fait prendre la meilleure décision pour ne pas autoriser l'accès à distance."
«ne pas autoriser l'accès à distance» - le danger ici est qu'il y a vraisemblablement une exigence d'accès à distance et qu'une personne mal informée a une sorte de contrôle sur la façon dont cela sera mis en œuvre.Il y a un réel danger de se retrouver avec une solution bien pire que ssh ici.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...