Cela améliore-t-il la sécurité d'utiliser des numéros de port obscurs?
J'ai récemment commencé un travail dans une petite entreprise où le CTO préfère héberger des services SSH sur des ports obscurs et numérotés sur nos serveurs plutôt que sur le port 22 bien connu. Sa justification est qu '"il empêche 99% des attaques de script kiddy". Je suis curieux de savoir si cela est considéré comme une mauvaise pratique.
Intuitivement, cela semble raisonnable. Mais nous sommes tous deux en grande partie autodidactes, et Je suis mal à l'aise avec l'idée d'improviser nos propres procédures de sécurité plutôt que de suivre une convention bien établie. Je sais que dans les schémas et protocoles cryptographiques généraux sont minutieusement conçus par des équipes d'experts et que chaque détail est destiné à protéger contre une sorte d'attaque, aussi insignifiante qu'elle puisse paraître. Je m'inquiète des conséquences imprévues d'un écart par rapport à ces recommandations.
Mais mon collègue semble avoir des preuves de son côté. Il a pu démontrer que nous recevons chaque jour des dizaines d'attaques qui tentent le port 22 et continuent. Je sais que en général, nous devons éviter la sécurité par l'obscurité , mais s'éloigner de cette cible commune semble vraiment contrecarrer la plupart des attaques .
Est-ce une bonne pratique ou non? Faut-il utiliser des ports bien connus?
[~ # ~] addendum [~ # ~]
Nous ne comptons pas uniquement sur le port obscur. Nous avons de nombreuses autres mesures de sécurité en place, y compris obligatoires - clés matérielles . Je vais reformuler ma question plus clairement.
Y a-t-il une raison pour laquelle le port 22 en particulier a été choisi pour SSH? Y a-t-il quelque chose de dangereux à utiliser d'autres ports?
Cela améliore-t-il la sécurité d'utiliser des numéros de port obscurs?
Si vous utilisez déjà des mots de passe à entropie élevée ou une authentification par clé publique, la réponse est "pas vraiment". La plupart du temps, vous vous débarrassez simplement du bruit dans les journaux.
Je m'inquiète des conséquences imprévues d'un écart par rapport à ces recommandations.
Cela dépend du port choisi. Sous Linux, par défaut, tous les ports inférieurs à 1024 nécessitent un accès root pour les écouter. Si vous utilisez un port supérieur à 1024, n'importe quel compte utilisateur peut l'écouter s'il n'y a pas déjà d'écoute de processus.
Pourquoi est-ce important? Disons que vous avez choisi de définir ssh pour qu'il se lie au port 20,000. Si quelqu'un pouvait arrêter le processus SSH sur un serveur (disons qu'il avait trouvé un moyen de planter le processus) et avait un accès local à ce serveur, il pourrait alors exécuter son propre serveur SSH sur le port 20,000 avant le redémarrage du service. Toute personne se connectant serait alors connectée au serveur SSH des méchants.
Ce n'est pas une affaire aussi importante qu'autrefois, car ces jours-ci, seul le personnel informatique de confiance reçoit un accès de connexion aux serveurs. Mais encore, il a le potentiel d'une escalade de privilèges et d'autres méchancetés si un attaquant prend pied sur votre serveur.
Hormis en dessous de 1024, le nombre 22 n'a rien de spécial. Il a été choisi en grande partie parce que SSH remplaçait telnet au port 23, et 21 a déjà été pris par FTP. Tant que vous choisissez un port en dessous de 1024, le port n'a pas vraiment d'importance.
Est-ce une bonne pratique ou non? Faut-il utiliser des ports bien connus?
Je ne dirais pas que je le recommande. Je ne le déconseillerais pas non plus. Comme je l'ai dit, cela évite beaucoup de bruit dans les fichiers journaux, mais les avantages sont largement limités à cela.
Pour toute personne intéressée par l'histoire de fond sur SSH, vous pouvez la trouver sur: https://www.ssh.com/ssh/port
Oui. La vraie question est: de combien?
Pourquoi ça? Vous avez déjà une sécurité de base, donc les attaques quotidiennes des bots ne vous inquiètent pas. Mais il pourrait y avoir un jour 0 et les attaquants savent qu'il ne faudra pas longtemps avant qu'un patch soit sorti, alors ils se bousculent pour l'utiliser et ne se soucient pas de quelque chose de compliqué - ils vont juste toucher autant de machines que possible sur le port standard. Tout type de ver SSH théorique utiliserait également cette stratégie. Vous seriez protégé contre cela.
Combien de sécurité supplémentaire cela vous apporte-t-il? Il protège contre cela et peut-être 2-3 autres scénarios spécifiques. Cela ajoutera au mieux quelques minutes à toute attaque ciblée par toute personne qui n'est pas un idiot total. Cela ne fait rien aux scénarios contre lesquels vous êtes déjà suffisamment protégé.
Branchez ces chiffres dans votre méthode d'analyse des risques préférée et vous devriez trouver quelque chose de relativement petit. À la baisse, vous avez l'effort supplémentaire de définir un numéro de port non standard, de le documenter, de le manquer peut-être lors d'un dépannage et de perdre du temps, etc.
Je suppose que vous atteindriez à peine le seuil d'une analyse. Ou, en d'autres termes: oui, cela améliore la sécurité, mais cela ne vaut pas la peine car l'amélioration est très faible.
Non, cela n'améliorera pas la sécurité . Cela peut réduire l'encombrement des journaux, car les attaques automatisées n'essaieront que les ports par défaut, par exemple ssh. Mais le port apparaîtra toujours comme SSH dans une analyse de port, et shodan.io .
Ces attaques automatisées visent généralement des fruits bas, avec des noms d'utilisateur standard tels que root, smith, etc., et des mots de passe faibles. S'ils réussissent, vous avez un problème en premier lieu.
Si vous configurez ssh pour autoriser uniquement l'authentification par clé, interdire les connexions root et utiliser des mots de passe raisonnables, utiliser fail2ban ou un mécanisme similaire pour bloquer les contrevenants, ils ne constituent pas une menace réelle.
J'utilise fail2ban configuré pour bloquer temporairement pendant cinq minutes après trois tentatives infructueuses et pendant une semaine après 3 * 5 tentatives infructueuses. Cela réduit l'encombrement des journaux et bloque toute progression réelle d'une attaque par force brute.
Pour un attaquant ciblé, le port écouté ne fait aucune différence. Cela n'a d'importance que pour les attaques automatisées qui, à mon avis, présentent un risque négligeable.
La modification du port par défaut peut vous sauver de l'analyse des ports et des script kiddies mais vous ne pourrez peut-être pas résister à une attaque ciblée où l'attaquant pourrait identifier les services en cours non pertinents pour les ports.
Si vous vouliez simplement vous éloigner des enfants de script, cela peut être utile, mais vous ne pourrez peut-être pas vous protéger du reste des attaques avancées.
Ma recommandation est d'utiliser le port par défaut (peut réduire vos frais administratifs) et de déployer des défenses de sécurité multi-faces pour atténuer les attaques.
Par exemple, avec le port par défaut utilisé, déployer l'authentification basée sur un certificat avec SSH n'est autorisée que pour certaines sources fiables.
Je dirais que oui, utilisez des numéros de port non normaux car cela filtrera BEAUCOUP de robots automatiques. mais ne vous y fiez pas, car beaucoup de bots que j'ai remarqués vont scanner un réseau/hôte pour tous les ports ouverts et les essayer.
La meilleure chose à faire est de mettre en place une bonne sécurité sur votre port SSH. désactivez la connexion root, ajoutez les adresses IP si vous le pouvez, n'utilisez pas de mots de passe pour les connexions (utilisez les clés), activez également une notification pour toutes les connexions. Et configurer un pare-feu, c'est important.
L'obscurcissement de ports sur des nombres élevés comme celui-ci ne fait qu'arrêter les robots simples qui rechercheront des ports bien connus. Les script kiddies et les hackers déterminés peuvent simplement scanner les ports du reste de la plage de ports pour trouver un service, de sorte que vous ne faites qu'arrêter le bruit du journal.
Peu importe la convention de ne pas écouter le port standard pour ce service. Les développeurs de ce service vous donnent la possibilité de l'exécuter sur n'importe quel autre port, et tout programme pouvant interagir avec lui aura la possibilité de spécifier le port auquel vous souhaitez parler.
Je suis d'accord avec d'autres articles ici que les ports sensibles comme SSH doivent être conservés dans un espace de port privilégié en dessous de 1024.
Une meilleure façon d'obscurcir SSH qui fonctionne réellement est de faire un port knock. Cela implique de fermer le port sur iptables jusqu'à ce qu'une séquence de ports ait été "détruite" qui ouvrira alors le port souhaité.
Par exemple, vous pouvez envoyer un paquet au 8000 4545 28882 7878. Une fois que vous avez entré la séquence souhaitée, iptables déverrouillera le port souhaité. Cela arrête vraiment la majorité des kiddies et des hackers de script car aucun port n'est annoncé. Mais cela ne s'arrête pas aux attaques de rejeu, mais au moment où vous avez de plus gros problèmes à vous soucier.
https://en.wikipedia.org/wiki/Port_knocking .
Vraiment, vous devriez utiliser TCPWrappers et ne laisser que les ips et les plages de réseau connues accéder aux ports comme SSH. Devez-vous autoriser les IP de Chine à accéder à SSH? Ou les développeurs n'auront-ils besoin d'accéder qu'à partir du LAN du bureau? S'ils travaillent à distance, faites-les VPN dans le LAN
Comme mentionné par d'autres, la migration vers un port non standard n'est pas une solution de sécurité car vous filtrez uniquement les attaques de niveau naïf.
En même temps, la migration peut être beaucoup plus précieuse si elle est combinée avec d'autres précautions. Par exemple, vous placez un pot de miel sur le port standard (un environnement qui est physiquement isolé du reste de votre système mais qui ressemble à une pièce légitime pour l'attaquant). Ensuite, si vous voyez que quelqu'un s'est cassé dans le pot de miel, c'est très probablement un pirate informatique, vous pouvez donc l'interdire automatiquement.
Et vous ne devez certainement pas utiliser des versions obsolètes de logiciels avec des vulnérabilités connues, quel que soit le numéro de port qu'ils lient pour écouter.
Non, ce n'est pas le cas, ou si je veux être plus précis, c'est la mauvaise protection contre la menace .
Faites un pas en arrière: de quelle menace voulons-nous nous protéger? La menace contre laquelle nous essayons de nous protéger est any personne sur Internet public qui peut contourner le mécanisme d'authentification normal. C'est ce que ces "script kiddies" essaient de faire: accéder au serveur en utilisant SSH même s'ils ne sont pas autorisés. En particulier, votre supérieur souhaite empêcher ces attaquants de pouvoir même commencer à établir une connexion SSH.
Quelle est la technologie standard pour empêcher l'établissement de connexions réseau? Un pare-feu. La réponse standard à ce problème est de bloquer entièrement le port 22 au trafic extérieur. Le plus gros problème ici est que SSH est disponible sur Internet public pas du tout, et le pare-feu résout cela complètement, tandis que le port obscur ne le cache que légèrement et n'empêche pas réellement les connexions. Si un accès externe est requis, la réponse standard pour autoriser cet accès autorisé est un VPN dans le réseau. Cela bloquerait à la fois les script kiddies et les attaquants du savoir qui pourraient trouver comment trouver le port que vous utilisez réellement.
Si vous perdez à 1% des attaquants, vous perdez toujours. Vous avez besoin de protections qui fonctionnent contre 100% des attaquants. Si, à la place, vous réussissez à bloquer 100% des attaquants (jusqu'à présent), vous devez disposer de protections plus robustes. Ces autres protections rendent le port obscur non pertinent, et si tel est (espérons-le) le cas, tout ce que fait l'autre port est de confondre les gens moins familiers avec les pratiques de sécurité réelles comme vous et, très probablement, perdez le temps des personnes essayant d'obtenir un accès légitime lorsqu'elles essaient de se connecter (nouveau système non configuré et devez demander à quelqu'un le bon port, l'administrateur a oublié de parler à la personne du port non standard et la personne doit les déranger à nouveau pour diagnostiquer le problème, etc.).
C'est pourquoi nous parlons de "sécurité par l'obscurité" et principe de Kerckhoffs . Nous devons éviter de nous distraire avec des pratiques qui ne nous protègent pas réellement. Nous devons économiser notre temps et nos efforts pour des protections qui fonctionnent réellement et éviter le faux sentiment de "sécurité" que ces méthodes d'obscurcissement nous donnent.
Je veux ajouter qu'en fin de compte, la sécurité est un jeu de ressources des deux côtés. Le temps est une telle ressource.
Cette mesure fait perdre du temps aux attaquants, donc ce n'est pas si mal. Vous pouvez également en savoir plus sur les ressources des attaquants lorsqu'ils se connectent toujours à votre port personnalisé. Peut-être qu'il y a un intérêt plus élevé à vous cibler en particulier.
Cependant, si cela ajoute des frais généraux importants à vos tâches administratives, vous voudrez peut-être investir votre temps ailleurs. Sinon, faites-le, mais ne vous y fiez pas.