L'idée fausse que vous avez est que la sécurité par l'obscurité est mauvaise. Ce n'est en fait pas le cas, la sécurité uniquement par l'obscurité est terrible.

Mettez les choses de cette façon. Vous voulez que votre système soit totalement sécurisé si quelqu'un en connaissait le fonctionnement complet, mis à part le composant clé secret que vous contrôlez. La cryptographie en est un parfait exemple. Si vous comptez sur eux "ne pas voir votre algorithme" en utilisant quelque chose comme un chiffrement 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.

Ce qu'il faut savoir, c'est que vous ne voulez jamais compter sur l'obscurité mais cela ne fait certainement 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 passage du serveur 22 au port 2222 pour assurer la sécurité de ma connexion? Absolument pas. Est-il mauvais de changer mon serveur SSH sur le port 2222 tout en utilisant également 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 les ports normaux. Nous gagnons un avantage de sécurité par l’obscurité, ce qui est bien, mais nous ne comptons pas sur l’obscurité . S'ils l'ont trouvé, ils doivent encore 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é avec l'attaquant sachant que son fonctionnement est complet en dehors des informations secrètes spécifiquement contrôlables (c'est-à-dire les 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 rapidement vérifiés en 1 minute avec un scanner comme nmap. "Deviner" un mot de passe aléatoire, disons à 10 chiffres, de tous les caractères ascii est 1 / 1.8446744e + 19 et prendrait 5,8 millions d'années à 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 le fait que les attaquants ne connaissent pas les informations (mots de passe) et que la définition du dictionnaire de l'obscurité est "L'état d'être inconnu", vous pouvez donc dire correctement que tout compte sur un niveau d'obscurité.

Encore une fois, la valeur se résume à la sécurité pratique étant donné que les informations que vous pouvez contrôler restent inconnues. Les clés, qu'il s'agisse de mots de passe ou de certificats, etc., sont (relativement) simples à garder secrètes. Les algorithmes et autres méthodes faciles à vérifier sont difficiles à garder secrets. «Vaut-il la peine» se résume à déterminer ce qu'il est possible de garder inconnu et à juger de la possibilité d'un compromis sur la base de cette information inconnue.

Les secrets sont difficiles à garder secrets. Plus un secret est volumineux et plus de personnes le connaissent, plus il risque de fuir rapidement.

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 en réalité que nous pensons que leur secret pourrait être plus petit, connu par moins de gens et / ou plus facile à modifier .

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 sur le premier point.

La distinction entre quand quelque chose est un secret approprié et simplement obscur est de savoir si nous connaissons un moyen d'atteindre le même niveau de sécurité avec un plus petit secret qui est plus facile à changer et est connu par moins de gens.

Je ne suis pas d'accord avec l'affirmation selon laquelle l'obscurité supplémentaire ne fait jamais de mal.

Dans le cas des numéros de port SSH, il est un peu de temps supplémentaire requis pour taper -p 1234 chaque fois que vous utilisez SSH. Ce n'est qu'une seconde ou deux, mais avec le nombre de fois que j'utilise SSH, cela finirait par être significatif. Il faut se souvenir que ce client est légèrement différent et enseigner la même chose aux nouveaux employés. 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é à essayer de comprendre pourquoi vous ne pouvez pas vous connecter.

Puisque les numéros de port sont si faciles à découvrir avec un scan de port, vous devrez également implémenter un IPS qui détecte le scan de port et empêche le port correct de répondre lorsqu'il est vérifié ou implémente quelque chose comme le port-knocking. 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 à obscurcir les détails enlève de véritables 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écurisé.

La sécurité par l'obscurité est l'endroit où vous vous fiez à un fait que vous espérez inconnu d'un attaquant. Un problème majeur avec ceci est qu'une fois que le fait est divulgué, le schéma de sécurité est rendu inutile.

Cependant, tout ce que SSH fait est d'obscurcir les informations. Il repose sur l'espoir qu'un attaquant ne pensera pas à deviner la bonne clé cryptographique.

Lorsque l'expression « Sécurité par l'obscurité » est discutée, elle fait référence aux processus impliqués, plutôt qu'à des informations secrètes. Le problème avec SSH, c'est qu'en tant que processus , il a été soigneusement contrôlé pour garantir que la seule chose que vous devez garder secrète est la clé cryptographique. Ce n'est en principe 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 faire de la force brute une clé AES 256 bits dont vous auriez besoin au minimum , pour capturer la totalité de l'énergie du soleil pendant 32 ans (!). Peu importe la vitesse de votre ordinateur. C'est juste un résultat théorique de l'information qui tient quel que soit l'ordinateur que vous utilisez (nonobstant l'informatique quantique).

C'est totalement irréalisable avec la technologie actuelle. Cela ne veut pas dire que SSH utilise AES, mais c'est l'un des principes d'une bonne cryptographie.

Par exemple, un bogue est découvert dans un logiciel où un utilisateur (de confiance) trouve un l'entrée permet un contournement d'authentification. Un mauvais gestionnaire pourrait dire "ah, mais il est vraiment improbable que des utilisateurs non fiables découvrent jamais cela, pourquoi se donner la peine de le réparer". C'est la sécurité par l'obscurité.

Cela a été abordé dans plusieurs autres réponses, mais il y a trois pièces à ce puzzle.

1. Mécanismes
2. Implémentation / Configuration
3. Données

Un exemple de mécanisme serait AES, ou SHA-1, ou pour votre exemple, SSH.
Un exemple d'implémentation / configuration serait sur quel port SSH écoute, ou sur quel algorithme de cryptage vous avez choisi pour crypter 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 cela fonctionne» n'est pas la sécurité. Il doit pouvoir être examiné dans les moindres détails sans que les implémentations soient exploitables en l'absence de données secrètes.

Une mise en œuvre peut ou non être masquée. En règle générale, cela ne nuit ni ne contribue à la sécurité matériellement lorsque vous faites cela. Vous pouvez voir moins d'analyses de port identifiant votre port SSH, ou vous pouvez masquer l'algorithme de cryptage 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 ici un avantage marginal en matière de sécurité et un dommage marginal à la convivialité. 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 mots de passe, vous les révoquez, créez de nouvelles données secrètes et promettez de mieux les protéger la prochaine fois.

La sécurité à 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 de contournement pour combler vos lacunes. Lorsque cette couche de protection est supprimée, la vulnérabilité est ouverte pour ê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 un environnement de production. C'est en effet une menace un mythe de sécurité; mais c'est rapidement terni par quelqu'un qui a assez de connaissances pour faire de l'ingénierie inverse et parfois simplement en reniflant le réseau.

Habituellement, la principale raison pour laquelle ces menaces s'échappent dans la nature quand elles sont manquées dans la phase SDLC de conception de système / application; puis, quand il passe à l'environnement de production, cela coûte trop cher pour les choses à réparer à partir de ce point. 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.

Aussi comme un facteur de marché , vous devez savoir que de telles pratiques sont normalement suivies par les fournisseurs / la communauté de source fermée; pour un projet open-source, ce concept ne s'applique pas à des fins pratiques car le code est rendu public pour examen et à peu près tout le monde peut répondre à ses préoccupations grâce à des techniques telles que les révisions de code. Le moyen le meilleur et le plus fiable de l'attraper.

Vaincre la sécurité SSH grâce à des exemples pratiques de concept d'obscurité

1. Exécuter nessus scan sur le réseau ciblé serait vous apporter les services vulnérables et les ports mappés
2. Exécutez une analyse nmap sur le réseau ciblé pour les services ouverts.

La sécurité par l'obscurité n'est pas la sécurité est peut-être plus précisément énoncée comme suit: «Un système de sécurité 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é car 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 contienne un défaut. De plus, limiter la quantité à garder secrète permet de le garder plus facilement secret.

L'affirmation "la sécurité par l'obscurité n'est pas la sécurité" découle de l'idée que de nombreuses idées "intelligentes" surgissent tout simplement avec des façons compliquées de faire quelque chose pour essayer de rendre plus difficile pour un attaquant de comprendre quelque chose, mais souvent un détail de ces approches aura un impact sur d'autres détails d'autres étapes, il est donc impossible de dire à quel point ce sera difficile pour un attaquant avec connaissance partielle d'un algorithme secret pour déterminer le reste de l'algorithme.

Les clés par contre devraient être aléatoires, connaître quelques bits d'une clé cryptographique par exemple ne devrait pas vous aider à comprendre les autres bits dans la clé. De même, la difficulté de trouver 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, cela n'ajoute pas de sécurité statistiquement significative.

Qu'est-ce qui a un impact statistiquement significatif sur la sécurité de un algorithme est un problème avec l'algorithme. En général, les algorithmes publiés ont été beaucoup plus minutieusement examinés pour détecter toute faille qui les brise et fourniront donc généralement une plus grande confiance dans la sécurité qu'ils fournissent.

Pour terminer, la plupart des problèmes 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îneraient un mauvais comportement du système et révéler les secrets.

Dans chaque algorithme de chiffrement, à chaque invite de connexion, la «sécurité par l'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. Disons que vous avez inventé votre propre algorithme de chiffrement, par exemple "zip puis XOR avec votre clé". Un attaquant sonde votre système et peut déterminer l'algorithme de compression à partir du temps qu'il faut à votre schéma de chiffrement pour encoder 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, les données compressées et xor'ed 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 les données que vous voulez avec mais cela ne divulgue aucune information sur la clé secrète .

Le temps dont une personne a besoin pour accéder à vos données est très important pour distinguer une bonne sécurité d'une mauvaise sécurité. Dans votre exemple spécifique, passer du port 22 au port 2222 do est une autre information dont l'attaquant a besoin, c'est donc un avantage de sécurité. Comme cela est facile à comprendre en peu de temps, cela n'ajoute qu'une très petite quantité, mais ne laisse rien fuir sur votre clé. Comme cette analyse de port est triviale et ne coûte qu'une seule fois, seule la quantité totale d'informations nécessaires pour connaître votre clé secrète reste constante, c'est pourquoi elle n'est pas considérée comme améliorant la sécurité totale, d'où le dicton commun que «la sécurité par l'obscurité» n'aide pas.

"L'obscurité" concerne les hypothèses

Je pense que la "sécurité par l'obscurité" concerne en fait les hypothèses erronées.

Par exemple, si j'utilise naïvement mon propre chiffrement à la main, en pensant "personne ne saura comment le briser parce qu'il est unique":

• Je sais qu'il peut être brisé par quelqu'un qui a la clé.
• Je suppose qu'il ne peut pas être cassé par d'autres moyens. C'est probablement faux.

Si j'utilise une méthode de chiffrement éprouvée:

• Je sais qu'elle peut être interrompue par quelqu'un qui a la clé.
• J'ai de bonnes preuves qu'il ne peut pas être cassé 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 que nous faisons X", la réponse correcte est combien de preuves avez-vous? Le niveau de sécurité est très, très élevé.

Je le formulerais de cette façon:

«La sécurité par l'obscurité» fait référence à une situation où un attaquant est délibérément fourni avec tous les moyens / informations nécessaires pour briser le mécanisme de sécurité, en espérant ou en supposant que l'attaquant ne dépensera pas l'effort pour le révéler.

Parfois, on peut observer que certains programmes essaient de parvenir à la sécurité par un système de chiffrement `` automatique '', où à la fin, en plus de l'algorithme de cryptage, la clé de cryptage est contenue quelque part dans le programme lui-même. Le programme lui-même n'aura pas besoin d'informations supplémentaires pour pouvoir déchiffrer ses données «secrètes»; et aucun attaquant non plus.

La «vraie» sécurité essaiera de s'assurer qu'un attaquant n'aura jamais toutes les informations nécessaires pour la briser. Lors de l'utilisation du chiffrement, peu importe si l'attaquant a accès à la fois au message de chiffrement et à l'algorithme pour le créer tant que la clé de chiffrement ne lui est pas divulguée . 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é.

Vous pouvez utiliser ce que vous voulez pour la "clé secrète", mais les ports font un mauvais choix; il n'y en a que 2 ^ 16, ils peuvent être reniflés, et ils sont (généralement) statiques pour 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’ya pas d’autre bon choix. En particulier, la randomisation du port a été utilisée pour contrer l ' 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 32 bits de sécurité, 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 comme "pas grave" puisque DNS a toujours été vulnérable aux attaques MITM de toute façon. C'est la vie.

Donc, que votre exemple soit "sécurité par l'obscurité" ou pas dépend vraiment du contexte.

Si vous avez toute une suite de mécanismes de protection, vous pourriez dire que l’un 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 une "sécurité par l'obscurité" si ce mécanisme de protection dépend d'un attaquant qui n'attend pas quelque chose, ou si ce mécanisme de protection dépend du fait qu'il est inhabituel plutôt que cryptographique fort. En d'autres termes, mettre SSH sur le port 2222 est la sécurité par l'obscurité car un attaquant ne s'attendrait pas à ce qu'il soit là (ce ne serait pas sa première supposition), et parce que ce n'est pas le port normal. Cependant, protéger SSH avec un mot de passe de haute résistance est une véritable sécurité car il est destiné à être cryptographiquement fort. De plus, changer votre nom d'utilisateur de "root" à quelque chose qui ne peut pas être facilement deviné est également une vraie sécurité car il y a une mesure de la force cryptographique là-bas: 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 informatique ne connaît pas votre algorithme de chiffrement. Vous inversez simplement les caractères dans vos mots, comme PASS -> SAPP, ou faites une obfuscation plus complexe, et vous pouvez communiquer tant que personne ne repère l'algorithme. Si le dévoilement de l'algorithme de chiffrement brise toute votre sécurité, alors c'est l'obscurité, pas la sécurité. La vraie sécurité commence lorsque le pirate informatique ne pourra pas déchiffrer votre message, étant donné les algorithmes de chiffrement et de déchiffrement.

La sécurité est assurée 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 possède (par exemple, carte ATM, carte à puce)
• Quelque chose que l'utilisateur est (par exemple, caractéristique biométrique, telle qu'une empreinte digitale)

La plupart des mesures de sécurité utilisent l'authentification à un facteur. 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 le fait d'exiger une phrase de passe pour la clé serait une authentification à deux facteurs).

L'authentification à deux facteurs est quelque chose qui a été mis en œuvre par de nombreux fournisseurs de services et logiciels ces derniers temps. 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 réelle sécurité.

L'obscurité ne peut vous blesser 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 contre des vulnérabilités futures inconnues, si vous essayez de maintenir les meilleures pratiques (phrases de passe fortes, appliquer des mises à jour de sécurité, utiliser des algorithmes et protocoles vérifiés par la sécurité, 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 un Ruby On Rails et a annoncé cela et s'est avéré être en vacances en janvier dernier, des 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 exécutiez et essayer chaque site Web aléatoire.

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é Debian SSH il y a quelques années. Les gens commenceront à scanner au hasard pour trouver ssh fonctionnant sur le port 22 sur des adresses IP aléatoires, puis exécuteront l'exploit. Bien sûr, ils pourraient d'abord effectuer une analyse de port pour rechercher ssh, mais les attaquants chercheront d'abord le fruit bas. Une recherche complète rendrait leur analyse plus de 10000 fois plus lente. J'espère que vous avez corrigé le problème. La plupart des adresses IP aléatoires n'auront pas de ssh ou quoi que ce soit d'autre en cours d'exécution, 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 abandonne tous les paquets vers les ports autres que 39325, ils passeront probablement à autre chose avant de trouver votre serveur ssh. C'est l'obscurité qui vous aide. Oui, un espion réseau pourrait facilement trouver votre port à l'écoute sur une seule 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 votre trafic réseau. De plus, même pour ces attaquants, 99,9% du temps, vous pensez que votre configuration ssh est sécurisée et ne présente aucune vulnérabilité.

Et pour les tracas supplémentaires liés à la saisie de ssh -p 39325 -Y foologin@foo.subdomain.example.com , quiconque utilise ssh configure fréquemment un ~ / .ssh / config (ainsi que 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 de passe 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 de port s'il est connecté à Internet et je ne l'utilise que (ma machine domestique, mon VPS) car c'est un problème pour que tout le monde utilise le même port que vous. Pour les trucs internes à plusieurs utilisateurs au travail, je garde un 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 de faire fonctionner ssh sur le port 22 et je me suis mis à ~ 10000 mauvaises tentatives d'authentification / jour (toutes avec des noms d'utilisateur inexistants) enregistrées dans les fichiers journaux. Au cours des trois derniers mois de fichiers journaux, je n'ai eu aucune exécution sur un autre port.

Je suppose que l'obscurité peut être mesurée en comparant sa valeur de sécurité à combien cela compliquera l'utilisation du support protégé. Quelqu'un a déjà mentionné que changer le port SSH augmentera un peu votre sécurité, mais en même temps compliquera beaucoup l'utilisation du shell, car vous devrez vous souvenir du port sur lequel il se trouve, apprendre à tous les nouveaux employés cette sécurité. mesure, et finalement cela finira comme une note collante attachée aux affichages 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 restaure les significations originales des fonctions et des variables (par exemple par un débogage soigneux) rendant l'obscurcissement inutile. D'autre part, 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) simplement de travailler sur du code avec une convention de dénomination étrange.

À mon avis, vous perdez plus que vous ne gagnez en utilisant l'obscurité et c'est pourquoi la sécurité par l'obscurité est considérée comme une mauvaise pratique.