Est-ce que l'utilisation de numéros de port obscurs améliore la sécurité?

Si vous utilisez déjà des mots de passe à haute entropie ou une authentification par clé publique, la réponse est "pas vraiment". La plupart du temps, vous vous débarrassez simplement du bruit des journaux.

Je m'inquiète des conséquences involontaires de s'écarter de 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 d'utilisateur peut écouter dessus s'il n'y a pas déjà un processus d'écoute.

Pourquoi est-ce important? Supposons que vous ayez choisi de configurer 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 se connecterait alors au serveur SSH des méchants.

Ce n'est pas aussi grave qu'avant, car de nos jours, seuls les membres du personnel informatique de confiance ont accès à la connexion. les serveurs. Mais quand même, cela peut potentiellement augmenter les privilèges et autres désagréments si un attaquant prend pied sur votre serveur.

À part être en dessous de 1024, il n'y a rien de spécial à propos du nombre 22. Il a été choisi en grande partie parce que SSH remplaçait telnet au port 23 , et 21 était déjà 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? Devrions-nous 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 base sur SSH, vous pouvez la trouver à: https://www.ssh.com/ssh/port

Oui, c'est le cas. La vraie question est: de combien?

Pourquoi? Vous disposez déjà d'une sécurité de base, donc les attaques quotidiennes de bots ne vous inquiètent pas. Mais il pourrait y avoir un jour 0 demain et les attaquants savent qu'il ne faudra pas longtemps avant qu'un correctif ne soit disponible, alors ils se bousculent pour l'utiliser et ne se soucieront pas de quelque chose de compliqué - ils frapperont juste 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 quiconque n'est pas un idiot total. Cela ne fait rien aux scénarios contre lesquels vous êtes déjà suffisamment protégé.

En intégrant ces chiffres à votre méthode d'analyse de risque préférée, vous devriez trouver quelque chose de relativement petit. En revanche, vous avez l'effort supplémentaire de définir un numéro de port non standard, de le documenter, peut-être de le manquer lors d'un dépannage et de perdre du temps, etc.

Je suppose que vous seriez à peu près égalité avec 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 en tant que SSH dans une analyse de port, et shodan.io.

Ces attaques automatisées visent généralement des résultats faciles, avec des noms d'utilisateur standard tels que root, smith et ainsi de suite, et des mots de passe faibles. S'ils réussissent, vous avez un problème en premier lieu.

Si vous configurez ssh pour n'autoriser que l'authentification par clé, interdire les connexions root et utiliser des mots de passe raisonnables, utilisez fail2ban ou un mécanisme similaire pour bloquer les contrevenants, ils ne sont pas une vraie menace.

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 tout progrès réel sur une attaque par force brute.

Pour un attaquant ciblé, le port d'écoute ne fera 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 épargner le scan de port et les script kiddies, mais vous ne pourrez peut-être pas résister à une attaque ciblée où l'attaquant pourrait identifier les services en cours d'exécution non pertinents pour les ports.

Si vous le souhaitez échappez-vous simplement au script kiddies, 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é, le déploiement d'une authentification basée sur un certificat avec SSH n'est autorisé que sur certaines sources de confiance.

Je dirais que oui, utilisez des numéros de port non normaux car cela filtrera BEAUCOUP de bots automatiques. mais ne comptez pas dessus, 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 est d'implémenter une bonne sécurité sur votre port SSH . désactiver la connexion root, ajouter les adresses IP à la liste blanche si vous le pouvez, ne pas utiliser de mots de passe pour les connexions (utiliser les clés), activer également une notification pour les connexions. Et configurer un pare-feu, c'est important.

Obscurcir les ports sur des nombres élevés comme celui-ci n'arrête que de simples bots qui chercheront des ports bien connus. Les script kiddies et les hackers déterminés peuvent simplement balayer le port du reste de la plage de ports pour trouver un service, vous arrêtez donc seulement quelques bruits de journaux.

La convention de ne pas écouter le standard n'a pas vraiment d'importance port 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 qui peut interagir avec lui aura une option pour spécifier à quel port vous voulez parler.

Je suis d'accord avec les autres publie ici que les ports sensibles comme SSH doivent être conservés dans l'espace de port privilégié sous 1024.

Une meilleure façon d'obscurcir SSH qui fonctionne réellement est de faire un coup de port. Cela implique de fermer le port à iptables jusqu'à ce qu'une séquence de ports ait été "frappée" qui ouvrira alors le port souhaité.

Par exemple, vous pouvez envoyer un paquet au 8000 4545 28882 7878. Une fois que vous avez souhaité la séquence est iptables entré déverrouillera le port souhaité. Cela arrête vraiment la majorité des script kiddies et hackers car aucun port n'est annoncé. Mais cela ne s'arrête pas contre les attaques de relecture, mais au moment où vous avez de plus gros problèmes à vous soucier.

https://en.wikipedia.org/wiki/Port_knocking.

En fait, vous devriez utiliser TCPWrappers et ne laisser que les ips et les plages réseau connus accéder aux ports comme SSH. Avez-vous besoin de laisser 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, transformez-les en 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 intéressante 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 quelqu'un cassé dans le pot de miel, il est fort probable qu'il s'agisse d'un pirate informatique, vous pouvez donc l'interdire automatiquement.

Et vous ne devriez sûrement pas utiliser de versions obsolètes de logiciels avec des vulnérabilités connues, quel que soit le numéro de port qu'ils doivent é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: quelle est la menace que nous voulons protéger de? La menace contre laquelle nous essayons de nous protéger est toute 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 consiste simplement à bloquer entièrement le port 22 au trafic extérieur. Le plus gros problème ici est que SSH est disponible pour l'Internet public 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 de connaissances qui pourraient trouver comment trouver le port que vous utilisez réellement.

Si vous perdez jusqu'à 1% des attaquants, vous perdez toujours . Vous avez besoin de protections qui fonctionnent contre 100% des attaquants. Si à la place vous bloquez avec succès 100% des attaquants (jusqu'à présent), vous devez disposer de protections plus robustes. Ces autres protections rendent le port obscur inutile, et si tel est (espérons-le) le cas, l'utilisation de l'autre port ne fait que confondre les personnes moins familiarisées avec les pratiques de sécurité réelles comme vous et, très probablement , gaspillez le temps des gens qui essaient d'obtenir un accès légitime lorsqu'ils essaient de se connecter (le nouveau système n'est pas configuré et doit demander à quelqu'un le bon port, l'administrateur a oublié de parler du port non standard à la personne et la personne doit à nouveau la déranger pour diagnostiquer le problème , etc.).

C'est pourquoi nous parlons de "la sécurité par l'obscurité" et du principe de Kerckhoffs. Nous devons éviter de nous distraire avec des pratiques qui ne nous protègent pas réellement. Nous devrions économiser du temps et des 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 sur les 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 grave. Vous pouvez également en savoir plus sur les ressources des attaquants lorsqu'ils se connectent toujours à votre port personnalisé. Il est peut-être plus intéressant de 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.

L'utilisation de ports non standard pour des applications hautement vulnérables est une TRÈS BONNE pratique. SSH a beaucoup de vulnérabilités et 22 est un port par défaut courant vers la force brute.

Cela étant dit, cela dépend probablement. Il est très courant, en particulier dans un environnement d'entreprise, de voir des attaques par force brute sur des serveurs DMZ contre le port 22. De nombreuses entreprises, dans la finance par exemple, utilisent un port par défaut différent pour le trafic SSH / SFTP pour un transfert de données valide entre les organisations.

L'idée dans ce cas est plus de filtrer une partie du bruit (Port 22 Brute Forcing) afin que l'autre trafic sur un autre port soit plus facile à surveiller. Toute personne assez bonne peut trouver n'importe quel port ouvert sur un serveur connecté à Internet.

Ceci est considéré comme une forme d'atténuation ou de réduction des risques.

Edit: Je devrais ajouter: Quand je dis bien pratique, je fais référence aux bonnes pratiques sur vos appareils connectés à Internet. Tout ce qui se trouve derrière vos pare-feu est généralement sûr.