À quel moment quelque chose compte-t-il comme «sécurité par l'obscurité»?
Donc, je continue de trouver la sagesse conventionnelle selon laquelle "la sécurité par l'obscurité n'est pas du tout une sécurité", mais j'ai le problème (peut-être stupide) de ne pas pouvoir dire exactement quand quelque chose est "bonne sécurité" et quand quelque chose est juste " obscur'.
J'ai vérifié d'autres questions liées tangentiellement à cela et je n'ai pas pu comprendre la différence précise.
Par exemple: quelqu'un a dit que l'utilisation de SSH sur un port non standard était considérée comme une sécurité par l'obscurité. Vous comptez simplement sur l'autre personne pour ne pas vérifier cela. Cependant, tout ce que fait SSH est de masquer les informations. Il repose sur l'espoir qu'un attaquant ne pense pas à deviner la bonne clé cryptographique.
Maintenant, je sais que la première circonstance (que quelqu'un penserait à vérifier les ports non standard pour un service particulier) est beaucoup plus probable que la seconde (que quelqu'un devinerait au hasard une clé cryptographique), mais est-ce vraiment la différence?
Et, dans l'affirmative, comment suis-je (un infosec n00b, si ce n'est pas déjà très clair) censé pouvoir distinguer le bon (c'est-à-dire ce qui vaut la peine d'être mis en œuvre) du mauvais (ce qui ne l'est pas)?
De toute évidence, les schémas de cryptage qui se sont révélés vulnérables ne devraient pas être utilisés, donc parfois c'est plus clair que d'autres, mais ce que je lutte, c'est comment je sais où la sagesse conventionnelle s'applique et ne s'applique pas.
Parce que, à première vue, c'est parfaitement clair, mais lorsque j'essaie d'extrapoler un algorithme dur et rapide, applicable de manière cohérente pour vérifier les idées, je rencontre des problèmes.
L'idée fausse que vous avez est que la sécurité à travers l'obscurité est mauvaise. Ce n'est pas le cas, la sécurité seulement à travers l'obscurité est terrible.
Mets le comme ça. Vous voulez que votre système soit complètement sécurisé si quelqu'un en connaissait le fonctionnement complet, à l'exception du composant secret clé que vous contrôlez. La cryptographie en est un parfait exemple. Si vous comptez sur eux pour ne pas voir votre algorithme en utilisant quelque chose comme un chiffre ROT13, c'est terrible. D'un autre côté, s'ils peuvent voir exactement l'algorithme utilisé mais ne peuvent toujours pratiquement rien faire, nous voyons la situation de sécurité idéale.
La chose à réaliser est que vous ne voulez jamais compter sur l'obscurité mais cela ne fait jamais de mal . Dois-je protéger par mot de passe/utiliser des clés pour ma connexion SSH? Absolument. Dois-je compter sur le changement du serveur de 22 au port 2222 pour assurer la sécurité de ma connexion? Absolument pas. Est-il mauvais de changer mon serveur SSH en port 2222 tout en utilisant un mot de passe? Non, c'est la meilleure solution. Changer ("obscurcir") le port réduira simplement un tas de scanners d'exploit automatiques recherchant des ports normaux. Nous obtenons un avantage de sécurité grâce à l'obscurité, ce qui est bien, mais nous ne sommes pas compte sur l'obscurité. S'ils l'ont trouvé, ils doivent toujours déchiffrer le mot de passe.
TL; DR - Ne compter que sur l'obscurité est mauvais. Vous voulez que votre système soit sécurisé, l'attaquant sachant que son fonctionnement est complet, à l'exception des informations secrètes spécifiquement contrôlables (c'est-à-dire des mots de passe). L'obscurité en soi n'est cependant pas mauvaise et peut en fait être une bonne chose.
Edit: Pour répondre plus précisément à votre question de probabilité, oui d'une manière que vous pourriez voir comme ça, tout en appréciant les différences. Les ports vont de 1 à 65535 et peuvent être vérifiés rapidement en 1 minute avec un scanner comme nmap. "Deviner" un mot de passe aléatoire à 10 chiffres de tous les caractères ascii est 1/1.8446744e + 19 et il faudrait 5,8 millions d'années pour deviner 100 000 mots de passe par seconde.
Edit 2: Pour répondre au commentaire ci-dessous. Les clés peuvent être générées avec une entropie suffisante pour être considérées comme vraiment aléatoires ( http://tools.ietf.org/html/rfc4086 ). Sinon, c'est un défaut de mise en œuvre plutôt que de philosophie. Vous avez raison de dire que tout repose sur des attaquants qui ne connaissent pas les informations (mots de passe) et la définition du dictionnaire de l'obscurité est "l'état d'être inconnu", donc vous pouvez correctement dire que tout est en train de compter à un niveau d'obscurité.
Encore une fois, bien que la valeur se résume à la sécurité pratique étant donné que les informations que vous êtes en mesure de contrôler restent inconnues. Les clés, qu'il s'agisse de mots de passe ou de certificats, etc., sont (relativement) simples à maintenir secrètes. Les algorithmes et autres méthodes faciles à vérifier sont difficiles à garder secrets. "Est-ce utile" revient à déterminer ce qu'il est possible de garder inconnu et à juger de la possibilité de compromis sur la base de ces informations inconnues.
Les secrets sont difficiles à garder secrets. Plus un secret est grand et plus il y a de gens qui le connaissent, plus il risque de fuir tôt.
Les bons secrets sont:
- Petit.
- Connu par une seule personne.
- Facile à changer.
Lorsque nous accusons quelqu'un de sécurité par l'obscurité ce que nous disons vraiment comme ce que nous pensons leur secret pourrait être plus petit, connu par moins de personnes et/ou plus facile à changer.
Les algorithmes, les numéros de port et les mots de passe partagés échouent tous aux deuxième et troisième points ci-dessus. Les algorithmes échouent également au premier point.
La distinction entre quand quelque chose est un secret approprié et juste obscure est de savoir si nous connaissons un moyen d'atteindre le même niveau de sécurité avec un secret plus petit qui est plus facile à changer et est connu par moins de gens.
Je ne suis pas d'accord avec l'affirmation selon laquelle une obscurité supplémentaire ne fait jamais de mal.
Dans le cas des numéros de port SSH, il faut un peu de temps supplémentaire pour taper -p 1234 chaque fois que vous utilisez SSH. Ce n'est qu'une seconde ou deux, mais avec le nombre de fois où j'utilise SSH, cela finirait par être significatif. Il y a la surcharge de se rappeler que ce client est légèrement différent et d'enseigner aux nouveaux employés de la même façon. Il y a le cas où vous oubliez que ce client est sur un port étrange et perdez des minutes à regarder les configurations de pare-feu et les moniteurs de disponibilité essayant de comprendre pourquoi vous ne pouvez pas vous connecter.
Étant donné que les numéros de port sont si faciles à découvrir avec une analyse de port, vous devrez également implémenter un IPS qui détecte l'analyse de port et empêche le port correct de répondre lorsqu'il est vérifié ou implémenter quelque chose comme le port Ces deux méthodes peuvent être surmontées et n'ajoutent rien de plus que plus d'obscurité, mais elles prennent votre temps à jouer au chat et à la souris avec votre attaquant.
Le même temps passé à désactiver les connexions root et les mots de passe et à passer aux clés aura un meilleur impact sur la sécurité. Perdre du temps sur des détails obscurcissants enlève de vraies mesures de sécurité.
Dans le cas d'un algorithme secret, l'algorithme passe à côté de l'examen supplémentaire que de nombreux chercheurs en sécurité peuvent fournir. L'obscurité (ou le secret) de l'algorithme le rend probablement moins sûr.
La sécurité par obscurité est l'endroit où vous comptez sur un fait qui, vous l'espérez, n'est pas connu d'un attaquant. Un problème majeur avec cela est qu'une fois que le fait est révélé, le système de sécurité est rendu inutile.
Cependant, tout ce que fait SSH est de masquer les informations. Il repose sur l'espoir qu'un attaquant ne pense pas à deviner la bonne clé cryptographique.
Lorsque l'expression " Sécurité par obscurité" est discutée, elle fait souvent référence aux processus impliqués, plutôt qu'aux informations secrètes . La chose à propos de SSH est qu'en tant que processus , il a été fortement vérifié pour s'assurer que la seule chose dont vous avez besoin pour garder le secret est la clé cryptographique. En principe, cela n'est pas possible pour l'attaquant de "penser et deviner", car l'espace dans lequel vivent les clés cryptographiques est vaste .
Bruce Schneier a montré que pour forcer brutalement une clé AES 256 bits, vous auriez besoin au minimum , pour capturer toute l'énergie du Soleil sortie depuis 32 ans (!). Peu importe la vitesse de votre ordinateur. Ce n'est qu'un résultat théorique de l'information qui est valable quel que soit l'ordinateur que vous utilisez (malgré l'informatique quantique).
Ceci est totalement impraticable avec la technologie actuelle. Cela ne veut pas dire que SSH utilise AES, mais c'est l'un des principes d'une bonne cryptographie.
Un exemple pourrait être lorsqu'un bogue est découvert dans un logiciel où un utilisateur (de confiance) trouve une entrée spécifique autorise un contournement d'authentification. Un mauvais gestionnaire pourrait dire "ah, mais il est très peu probable qu'un utilisateur non fiable le découvre, pourquoi s'embêter à le réparer". C'est la sécurité par l'obscurité.
Il a été abordé dans plusieurs autres réponses, mais il y a trois pièces à ce puzzle.
- Mécanismes
- Implémentation/configuration
- Les données
Un exemple de mécanisme serait AES, ou SHA-1, ou pour votre exemple, SSH.
Un exemple d'implémentation/configuration serait le port sur lequel SSH écoute ou l'algorithme de chiffrement que vous avez choisi pour chiffrer les données de votre application. Un exemple de données est une clé privée ou un mot de passe.
Un mécanisme ne doit jamais être obscur. "C'est sûr parce que vous ne savez pas comment ça fonctionne" n'est pas de la sécurité. Il devrait pouvoir être examiné dans les moindres détails sans que les implémentations soient exploitables en l'absence de données secrètes.
Une implémentation peut ou non être masquée. En règle générale, cela ne fait ni mal ni sécurité de façon importante lorsque vous procédez ainsi. Vous pouvez voir moins d'analyses de port identifiant votre port SSH, ou vous pouvez masquer l'algorithme de chiffrement utilisé pour un texte chiffré particulier, mais pour un mécanisme sécurisé sans les données secrètes, cela ne devrait pas avoir d'importance. Le mécanisme devrait toujours être inexploitable. Il y a un argument selon lequel il y a un avantage de sécurité marginal ici, et un préjudice marginal à la facilité d'utilisation. Votre kilométrage peut varier.
Les données secrètes doivent toujours être obscures. Si quelqu'un met la main sur vos clés privées ou vos mots de passe, vous les révoquez, créez de nouvelles données secrètes et vous promettez de mieux les protéger la prochaine fois.
La sécurité contre l'obscurité s'applique à tout ce qui concerne le fait de ne pas corriger la faiblesse particulière au niveau du code/source au lieu de trouver une solution pour couvrir vos trous. Lorsque cette couche de protection est supprimée, la vulnérabilité est susceptible d'être exploitée.
Un tel exemple est le programme-hooks qui donne aux développeurs une sorte de moyen secret de se connecter aux applications dans l'environnement de production. C'est en effet une menace un mythe de la sécurité; mais son rapidement terni par quelqu'un qui a suffisamment de connaissances pour faire de l'ingénierie inverse et parfois juste en reniflant le réseau.
Habituellement, la principale raison pour laquelle ces menaces s'échappent dans la nature lorsqu'elles sont manquées dans la phase SDLC de conception du système/de l'application; puis quand il va à l'environnement de production, c'est tout simplement trop cher pour les choses à réparer à partir de ce moment. C'est là que des solutions de contournement ou des dissimulations commencent à émerger.
Un autre exemple Les gens écrivent leur mot de passe sur des morceaux de papier et le mettent sous leur clavier.
En outre, en tant que facteur de marché vous devez savoir que de telles pratiques sont normalement suivies par les fournisseurs/communauté de source fermée; pour un projet open-source, ce concept n'a aucune utilité pratique, car le code est rendu public pour examen et à peu près tout le monde peut répondre aux préoccupations par des techniques telles que les révisions de code. La meilleure façon et la plus fiable de l'attraper.
Défaite de la sécurité SSH à travers des exemples pratiques de concept d'obscurité
- Exécuter l'analyse Nessus sur le réseau ciblé vous apporterait les services vulnérables et les ports mappés
- Exécutez l'analyse nmap sur le réseau ciblé pour les services ouverts.
La sécurité par l'obscurité n'est pas une sécurité, c'est peut-être plus précisément déclaré: "Un système de sécurité n'est aussi sûr que ses secrets sont difficiles à deviner." Vraiment, quand vous y arrivez, le cryptage pourrait être considéré comme une sécurité par l'obscurité puisque la clé de cryptage est obscure. La différence est qu'il est si obscur qu'il est mathématiquement impossible à trouver et donc à sécuriser.
Dans tout système de sécurité basé sur le secret, vous voulez que le secret soit aussi limité que possible et aussi difficile à deviner que possible. Plus un secret est complexe, plus il est probable qu'il comporte une faille. En outre, la limitation de la quantité qui doit être gardée secrète facilite le maintien du secret.
L'énoncé "la sécurité par l'obscurité n'est pas la sécurité" découle de l'idée que de nombreuses idées "intelligentes" proposent simplement des moyens compliqués de faire quelque chose pour essayer et de rendre plus difficile pour un attaquant de comprendre quelque chose, mais souvent un détail de ces approches auront un impact sur d'autres détails d'autres étapes, il est donc impossible de dire à quel point il sera difficile pour un attaquant ayant une connaissance partielle d'un algorithme secret de déterminer le reste de l'algorithme.
Les clés, en revanche, doivent être aléatoires, la connaissance de quelques bits d'une clé cryptographique par exemple ne devrait pas vous aider à comprendre les autres bits de la clé. De même, la difficulté à comprendre la clé est assez bien comprise. Étant donné que la sécurité relative de l'algorithme n'est pas affectée de manière significative (ou quantifiable de manière fiable) par le secret de l'algorithme, il n'ajoute pas de sécurité statistiquement significative.
Ce qui a un impact statistiquement significatif sur la sécurité d'un algorithme, c'est tout problème avec l'algorithme. En général, les algorithmes publiés ont été examinés de manière beaucoup plus approfondie pour détecter tout défaut qui les briserait et fourniront donc généralement une plus grande confiance dans la sécurité qu'ils fournissent.
Donc, en conclusion, la plupart des mesures de sécurité impliquent un certain niveau d'obscurité, mais l'astuce consiste à minimiser la quantité et à maximiser la facilité de protection de ces secrets tout en essayant de s'assurer qu'il n'y a pas de failles non détectées qui entraîneront un mauvais comportement du système et révéleront le secrets.
Dans chaque algorithme de chiffrement, à chaque ouverture de session, la "sécurité par obscurité" est un composant majeur. Il repose toujours sur une sorte de connaissance secrète (à l'exception de l'authentification à deux facteurs).
La différence entre une bonne sécurité et une mauvaise sécurité est liée aux propriétés de la connaissance secrète : Reste-t-elle secrète?
Un mauvais exemple est un système où vous pouvez obtenir des informations sur ce secret à partir d'autres canaux. Supposons que vous ayez inventé votre propre algorithme de chiffrement, par exemple "Zip puis XOR avec votre clé". Un attaquant sonde votre système et pourrait déterminer l'algorithme de compression à partir du temps qu'il faut à votre schéma de chiffrement pour coder différents messages en texte brut. L'attaquant a acquis des connaissances sur votre système, connaît les éléments internes de l'algorithme Zip et pourrait être en mesure d'utiliser ces données pour déterminer votre clé. De l'extérieur, cela ressemble à un algorithme parfaitement bon, le compressé et le xor'ed les données sembleront assez aléatoires mais ne poseront qu'un petit défi à un attaquant sophistiqué. Votre clé peut être très longue mais cela ne vous aide pas à faire la distinction entre la mauvaise et la bonne obscurité. Vous avez accidentellement intégré un chemin pour acquérir des connaissances sur votre clé secrète dans l'algorithme:
Le contre-exemple est le chiffrement à clé publique RSA. Ici, la clé secrète est un grand nombre premier. La clé publique est le produit de la clé secrète et d'un autre grand nombre premier. Maintenant, même avec l'algorithme RSA bien connu, je peux vous donner ma clé publique, vous pouvez encoder toutes les données que vous voulez avec mais il ne fuit aucune information sur la clé secrète .
La quantité de temps dont une personne a besoin pour accéder à vos données est si importante pour distinguer une bonne d'une mauvaise sécurité. Dans votre exemple spécifique, passer du port 22 au 2222 do est une autre information dont l'attaquant a besoin, c'est donc un plus pour la sécurité. Comme cela est facile à comprendre en peu de temps, cela n'ajoute qu'une très petite quantité mais ne laisse rien couler sur votre clé. Comme cette analyse de port est triviale et ne coûte qu'une seule fois la quantité totale d'informations nécessaires pour connaître votre clé secrète reste constante, c'est pourquoi il n'est pas considéré comme améliorant la sécurité totale, d'où le dicton commun selon lequel "la sécurité par l'obscurité" n'aide pas.
"L'obscurité" concerne les hypothèses
Je pense que la "sécurité par l'obscurité" est en fait une hypothèse erronée.
Par exemple, si j'utilise naïvement mon propre chiffrement roulé à la main, en pensant que "personne ne saura le casser parce qu'il est unique":
- Je sais il peut être cassé par quelqu'un qui a la clé.
- I supposez il ne peut pas être cassé par d'autres moyens. C'est probablement faux.
Si j'utilise une méthode de cryptage éprouvée:
- Je sais il peut être cassé par quelqu'un qui a la clé.
- I avoir de bonnes preuves qu'il ne peut pas être brisé par d'autres moyens.
Je compte toujours sur "l'obscurité" de ma clé. Mais c'est la seule chose que je dois protéger.
Donc, pour détecter la "sécurité par l'obscurité", contester les hypothèses. Si quelqu'un dit "personne ne peut deviner ou détecter ce que nous faisons X", la bonne réponse est combien de preuves en avez-vous? La norme en matière de sécurité est très, très élevée.
Je le formulerais ainsi:
La `` sécurité par l'obscurité '' fait référence à une situation où un attaquant dispose délibérément de tous les moyens/informations nécessaires pour briser le mécanisme de sécurité, en espérant ou en supposant que l'attaquant ne consacrera pas l'effort à le révéler.
Parfois, on peut observer que certains programmes tentent de garantir la sécurité par un schéma de chiffrement "automatique", où en fin de compte, en plus de l'algorithme de chiffrement, la clé de chiffrement est contenue quelque part dans le programme lui-même. Le programme lui-même n'aura besoin d'aucune autre information pour pouvoir décrypter ses données "secrètes"; et aucun attaquant non plus.
La sécurité "réelle" essaiera de s'assurer qu'un attaquant n'aura jamais tous les informations nécessaires pour le briser. Lors de l'utilisation du chiffrement, il n'a pas d'importance si l'attaquant a accès à la fois au message de chiffrement et à l'algorithme pour le créer tant que le chiffrement clé ne lui est pas divulgué . De cette façon, il se voit refuser des informations critiques et ne peut pas, à partir des informations qu'il a simplement contourner le mécanisme de sécurité.
Je suppose que cette obscurité peut être mesurée en comparant sa valeur de sécurité à combien cela compliquera-t-il l'utilisation du support protégé. Quelqu'un a déjà mentionné que le changement de port SSH augmentera un peu votre sécurité, mais en même temps compliquera beaucoup l'utilisation du shell, car vous devrez vous rappeler, sur quel port il est, enseigner à tous les nouveaux employés de cette sécurité mesurer, et finalement il finira comme une note collante attachée aux écrans de l'utilisateur ou aux scripts automatiques avec le port codé en dur, annulant ainsi sa valeur de sécurité.
De même, vous pouvez masquer le code source pour le protéger. Mais si quelqu'un y accède, ce n'est qu'une question de temps avant qu'il ne rétablisse les significations originales des fonctions et des variables (par exemple par un débogage soigneux) rendant l'obscurcissement inutile. D'un autre côté, vous devez vous rappeler d'exécuter un programme spécial avant de compiler le code ou (ce qui est encore pire, mais je l'ai vu) de simplement travailler sur du code avec une convention de dénomination étrange.
À mon avis, vous perdez plus que vous gagnez en utilisant l'obscurité et c'est pourquoi la sécurité par obscurité est considérée comme une mauvaise pratique.
Vous pouvez utiliser tout ce que vous voulez pour la "clé secrète", mais les ports sont un mauvais choix; il n'y en a que 2 ^ 16, ils peuvent être reniflés et ils sont (généralement) statiques pendant la durée de la connexion.
Cependant, ils ont été utilisés comme (partie de) la clé secrète dans le passé, quand il n'y a pas d'autre bon choix. En particulier, randomiser le port a été utilisé pour contrer attaque d'empoisonnement du cache DNS Kaminsky d'il y a quelques années. Combiné à la randomisation de l'ID de requête 16 bits, cela nous donne une sécurité de 32 bits, ce qui est plus que suffisant pour nous protéger pendant la durée d'une requête DNS typique (~ 0,1 seconde). La clé secrète peut toujours être reniflée, mais elle est considérée "pas un gros problème" car DNS a toujours été vulnérable aux attaques MITM de toute façon. C'est la vie.
Donc, que votre exemple soit "la sécurité par l'obscurité" ou non dépend vraiment du contexte.
Si vous avez toute une série de mécanismes de protection, vous pourriez dire que n'importe lequel de ces mécanismes de protection n'est que "la sécurité par l'obscurité", mais il est plus important de considérer la sécurité du système dans son ensemble.
Individuellement, un mécanisme de protection est considéré comme "la sécurité par l'obscurité" si ce mécanisme de protection dépend d'un attaquant qui ne attend pas quelque chose, ou si ce mécanisme de protection dépend d'être inhabituel plutôt que cryptographiquement fort. En d'autres termes, mettre SSH sur le port 2222 est une sécurité par l'obscurité car un attaquant ne s'attendrait pas à ce qu'il soit là (ce ne serait pas leur première supposition), et parce que ce n'est pas le port normal. Cependant, la protection de SSH avec un mot de passe à haute résistance est une véritable sécurité car elle est conçue pour être cryptographiquement solide. De plus, changer votre nom d'utilisateur de "root" en quelque chose qui ne peut pas être facilement deviné est également une réelle sécurité car il y a une mesure de force cryptographique: si l'attaquant ne peut pas comprendre le nom d'utilisateur, il ne peut pas très bien pénétrer dans le système même si ils obtiennent le mot de passe correct.
Par obscurité, je comprends que votre sécurité est basée sur le fait que le pirate n'a pas connaissance de votre algorithme de cryptage. Vous inversez simplement les caractères de vos mots, comme PASS -> SAPP, ou faites de l'obscurcissement plus complexe, et vous pouvez communiquer tant que personne ne repère l'algorithme. Si le dévoilement de l'algorithme de cryptage brise toute votre sécurité, c'est de l'obscurité, pas de la sécurité. La vraie sécurité commence lorsque le pirate ne sera pas en mesure de décrypter votre message, compte tenu des algorithmes de cryptage et de décryptage.
La sécurité se fait en authentifiant que vous êtes le destinataire ou l'utilisateur prévu. Il y a 3 facteurs d'authentification
- Quelque chose que l'utilisateur sait (par exemple, mot de passe, code PIN, modèle)
- Quelque chose que l'utilisateur a (par exemple, une carte ATM, une carte à puce)
- Quelque chose que l'utilisateur est (par exemple, une caractéristique biométrique, telle qu'une empreinte digitale)
La plupart des mesures de sécurité utilisent l'authentification à facteur unique. SSH, par exemple, nécessite de connaître un mot de passe ou d'avoir une clé privée (je suppose que vous pourriez dire que demander une phrase secrète pour la clé serait une authentification à deux facteurs).
L'authentification à deux facteurs a été mise en œuvre récemment par de nombreux fournisseurs de services et logiciels. Cela nécessite deux des facteurs énumérés ci-dessus, généralement un mot de passe et un numéro de téléphone. Avec l'authentification à deux facteurs, un attaquant peut accéder à l'une ou l'autre des informations d'identification de sécurité et ne peut toujours pas accéder au système sécurisé.
La sécurité par l'obscurité est une authentification à facteur zéro. Vous n'êtes pas obligé de connaître un secret, de posséder quoi que ce soit ou d'être une personne en particulier. Sans authentification, il n'y a pas d'authentification et donc pas de véritable sécurité.
L'obscurité ne peut vous nuire que si vous pensez qu'elle vous offre une véritable sécurité et adoptez des pratiques faibles. Cependant, l'obscurité peut aider légèrement car elle vous fait gagner du temps à partir de vulnérabilités futures inconnues, si vous essayez de maintenir les meilleures pratiques (phrases de passe fortes, appliquez des mises à jour de sécurité, utilisez des algorithmes et protocoles de sécurité approuvés, etc.). L'obscurité n'empêche pas une attaque de quelqu'un qui vous a ciblé si votre système est vulnérable, mais elle n'annonce pas non plus le fait que vous êtes vulnérable au monde entier.
Si vous aviez une Ruby on Rails app et que vous l'aviez annoncé et que vous étiez absent en vacances en janvier dernier, les gens auraient pu exécuter des commandes arbitraires sur votre serveur Web. En fait, la publicité permettrait aux attaquants de vous trouver beaucoup plus rapidement que s'ils devaient deviner au hasard le type de pile technologique que vous utilisiez et essayer chaque site Web au hasard.
Ou disons qu'il y a une faiblesse du jour zéro dans SSH; un peu comme le problème de génération de clés Debian SSH il y a quelques années. Les gens commenceront à analyser au hasard pour trouver ssh en cours d'exécution sur le port 22 sur des adresses IP aléatoires, puis exécuter l'exploit. Bien sûr, ils pourraient d'abord effectuer une analyse de port pour rechercher ssh, mais les attaquants chercheront d'abord les fruits bas. Une recherche complète rendrait leur scan plus de 10000 fois plus lent. J'espère que d'ici là, vous avez corrigé le problème. La plupart des adresses IP aléatoires ne disposeront pas de ssh ou de quoi que ce soit d'autre, il est donc logique que les attaquants arrêtent de scanner après le port 22 (et peut-être quelques autres 222 et 2222 et 22222 également). Si votre serveur domestique ne répond pas aux pings et dépose tous les paquets dans les ports mais autres que 39325, ils continueront probablement avant de trouver votre serveur ssh. C'est l'obscurité qui vous aide. Oui, une écoute indiscrète du réseau pourrait trouver trivialement votre port à l'écoute sur une connexion ssh. Mais pour la grande majorité des attaquants qui vous ont ciblé au hasard, ils n'auront pas observé de connexion ssh en écoutant le trafic de votre réseau. De plus, même pour ces attaquants, 99,9% du temps, vous vous attendez à ce que votre configuration ssh soit sécurisée et ne présente aucune vulnérabilité.
Et pour les tracas supplémentaires de taper ssh -p 39325 -Y [email protected], toute personne qui utilise ssh configure fréquemment un ~/.ssh/config fichier (avec authorized_keys et id_rsa.pub/id_rsa) afin qu'ils puissent simplement taper ssh foo pour se connecter après avoir tapé la phrase secrète de leurs clés privées. Maintenant, votre fichier de configuration se souvient du nom de domaine complet, de votre nom d'utilisateur, du port (sinon 22) et de tout autre indicateur. Pour ssh, je changerai les ports si c'est face à Internet et seulement je l'utilise (ma machine domestique, mon VPS) comme un tracas pour que tout le monde utilise le même port que vous. Pour les trucs internes à plusieurs utilisateurs au travail, je le garde pare-feu sur Internet extérieur et j'ai besoin d'un accès extérieur pour passer par un VPN.
Pour mémoire, mon VPS avait l'habitude d'avoir ssh en cours d'exécution sur le port 22 et a enregistré environ ~ 10000/mauvaises tentatives d'authentification (toutes avec des noms d'utilisateurs inexistants) enregistrées dans les fichiers journaux. Au cours des trois derniers mois de fichiers journaux, j'ai obtenu exactement zéro exécution sur un port différent.