Pourquoi l'accès externe à un serveur via SSH est-il considéré comme non sécurisé?
J'ai récemment eu une conversation avec mon patron et un entrepreneur 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 malheureusement je ne l'ai pas comprise - l'entrepreneur a déclaré que SSH n'était pas sûr mais ne savait pas pourquoi.
Pourquoi SSH n'est-il pas sécurisé? Il semble qu'il y ait quelque chose que j'ai manqué pendant notre conversation que je veux désespérément comprendre.
Ma proposition pour SSH incluait l'utilisation de l'accès par clé 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, il a dit, textuellement, "Je ne sais pas" et a continué avec colère avec un ton de voix accru pour le reste de la conversation. J'ai essayé de m'extirper mais j'ai dû repousser certains 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) établit une charge de preuve déraisonnablement élevée qui ne pourra jamais être satisfaite, pour l'une ou l'autre direction. Si tel est le cas, il serait sage d'en parler.
Premièrement, toute personne qui dit "ce n'est pas sûr, mais je ne sais pas pourquoi" nie complètement le droit de parler d'une position d'autorité sur la question.
Quelques personnes ont expliqué pourquoi l'ouverture d'un vecteur d'attaque est souvent découragée, mais voici certaines choses qui annulent le besoin de peur si elles sont utilisées correctement:
- VPN dans le réseau, puis SSH vers l'appareil
- Utiliser un port non standard
- Utiliser des paires de clés privées
- Implémenter des outils comme fail2ban
- Refuser les connexions des utilisateurs root
Honnêtement, une seule de ces options rend le piratage beaucoup plus difficile. Implémenter au moins deux signifie que vous pouvez utiliser SSH sans souci.
Cet entrepreneur informatique devrait vraiment envisager un nouveau métier.
SSH n'est généralement pas considéré comme non sécurisé en soi, mais c'est un protocole administratif et certaines organisations nécessitent deux couches de contrôle ou plus pour accéder à une console d'administration. Par exemple, la connexion via un VPN d'abord, puis l'ouverture d'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 exposeront toujours SSH en haut TCP à utiliser comme serveurs SFTP ont ensuite un script pour déplacer les données vers et à partir de ce système (ne permettant pas au serveur SSH/SFTP externe de se connecter au reste de leur réseau).
Tous les protocoles ont éventuellement des vulnérabilités donc si vous pouvez exiger l'utilisation de deux protocoles différents (ie IPSEC VPN et SSH) et restez discipliné sur les efforts de correction lorsque des vulnérabilités sont découvertes, puis la fenêtre de temps où des vulnérabilités connues existent dans les deux protocoles en même temps sur votre réseau doivent être très petits. 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 corrigez/corrigez réellement des vulnérabilités).
Comme un mauvais graphique de texte, regardez ce qui suit:
Time --->
IPSEC ------------------------ ----------------
SSH --------- -----------------------------
Contre avoir juste SSH, ou un VPN, par lui-même:
SSH --------- -----------------------------
Dans le premier exemple, lorsqu'une vulnérabilité SSH est apparue, il n'y en avait pas pour IPSEC et vice versa, il n'y a donc jamais eu, dans cet exemple grossier, où vos systèmes avaient des vulnérabilités sur les deux couches. Cette défense en profondeur est ce qui protège le système derrière ces protocoles qui peuvent parfois présenter des vulnérabilités.
Dans le deuxième exemple, SSH en lui-même, au moment où il y a une vulnérabilité ou une violation de mot de passe, ou un certain nombre d'autres problèmes, 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 c'est le cas, vous pouvez remettre en question le biais technologique, mais vous êtes probablement dans une organisation qui n'autorise pas l'accès à des protocoles administratifs directement depuis Internet.
J'ai demandé une explication et malheureusement je ne l'ai pas comprise - l'entrepreneur a déclaré que SSH n'était pas sûr mais ne savait pas pourquoi.
Pourquoi SSH n'est-il pas sécurisé? Il semble qu'il y ait quelque chose que j'ai manqué pendant notre conversation que je veux désespérément comprendre.
Traiter la sécurité comme un système 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ûr, mais il le croit catégoriquement. 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 présentent également des failles de sécurité et ne sont pas "faits de magie". Nous le savons par les diverses fuites de la NSA, et il n'y a aucune raison de croire que ces vulnérabilités sont entre les mains de la seule NSA.
La vraie question se résume au besoin d'accès par rapport au besoin de sécurité, pas à un protocole par rapport à 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é. Que vous activiez 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.
Qu'est-ce que l'insécurité, 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 le "accès externe " partie de votre question qui est.
SSH n'est qu'un moyen technique parmi d'autres pour ouvrir votre réseau interne au monde extérieur (ce qui est très risqué). Il peut être utilisé, seul ou associé à 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 appropriés d'authentification, d'autorisation et d'audit. Tout cela, bien sûr, doit être correctement documenté et tenu à jour.
Bien sûr, vous pourriez simplement continuer sans toutes ces charges administratives et d'entretien, mais voici le point: prendre un tel raccourci est précisément ce qui ne serait pas sûr dans votre question.
Ainsi, pourquoi l'accès externe à SSH est-il considéré comme non sécurisé? Parce que cela coûterait trop cher de le mettre en œuvre correctement en ce qui concerne le retour sur investissement attendu par l'entreprise.
Question sur les coûts
Le coût ici ne concerne pas l'achat de logiciels, il s'agit simplement de donner du temps aux gens pour concevoir et configurer ce service, puis pour le maintenir au fil du temps (alors que ces personnes sont occupées par 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 disparaître de la majorité des robots. 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 que vous devrez peut-être affronter.
Du point de vue de la gestion, il est probable que le "patron" soit plus intéressé par la pondération (monétaire) des différents risques par rapport au retour sur investissement attendu: combien cela coûtera-t-il pour l'installation et la maintenance? Combien cela permettra-t-il à 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 certaines parties bien définies de celui-ci, ce qui serait un moyen efficace de réduire le risque) sera une démarche rentable pour l'entreprise, vous 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 prévoyez de faire. Mais vous devez certainement résoudre la question d'un point de vue commercial et fonctionnel avant de descendre dans les détails techniques.
SSH n'est pas dangereux, mais ce n'est pas nécessairement une bonne pratique d'exposer SSH à Internet par crainte de 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 du réseau.
Si vous l'exposez sur Internet, désactivez l'authentification par mot de passe et désactivez la connexion root, autorisez uniquement 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.
SSH peut être considéré comme non sécurisé car votre organisation peut ne pas avoir de stratégie en place 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 à distance.
Toute organisation autorisant l'accès SSH voudra probablement empêcher la compromission du 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 la connexion par mot de passe via SSH, ou comme d'autres mentionnés peuvent nécessiter une authentification à double facteur. Cependant, s'ils n'ont pas de stratégie, la meilleure stratégie peut être de ne pas autoriser l'accès à distance SSH.
Si l'entrepreneur ne sait pas pourquoi cela pourrait ne pas être sûr, il peut en fait prendre la meilleure décision pour ne pas autoriser l'accès à distance.