Changer le numéro de port par défaut augmente-t-il réellement la sécurité?

J'ai vu des conseils disant que vous devriez utiliser différents numéros de port pour des applications privées (par exemple, un intranet, une base de données privée, tout ce qu'aucun utilisateur externe n'utilisera).

Je ne suis pas entièrement convaincu que cela puisse améliorer la sécurité parce que

1. Les scanners de ports existent
2. Si une application est vulnérable, elle le reste quel que soit son numéro de port.

Ai-je oublié quelque chose ou ai-je répondu à ma propre question?

Il ne fournit aucune défense sérieuse contre une attaque ciblée. Si votre serveur est ciblé, alors, comme vous le dites, il vous analysera au port et découvrira où se trouvent vos portes.

Cependant, le fait de déplacer SSH hors du port par défaut 22 dissuadera certaines des attaques de type kiddie non ciblées et de type amateur. Ce sont des utilisateurs relativement peu avertis qui utilisent des scripts pour balayer les ports à la fois, afin de vérifier si le port 22 est ouvert. Ils en lanceront une sorte d’attaque (attaque brutale, attaque par dictionnaire, etc.). etc). Si votre ordinateur se trouve dans ce bloc d'adresses IP en cours d'analyse et qu'il n'exécute pas SSH sur le port 22, il ne répondra pas et ne s'affichera donc pas dans la liste des ordinateurs que ce script kiddie peut attaquer. Ergo, il y a une sécurité de bas niveau fournie mais seulement pour ce type d'attaque opportuniste.

Par exemple, si vous avez le temps - enregistrez la plongée sur votre serveur (en supposant que SSH est sur le port 22) et extrayez toutes les tentatives infructueuses de SSH qui ont échoué. Déplacez ensuite SSH de ce port, attendez un moment et relancez la journalisation. Vous trouverez sans doute moins d'attaques.

J'avais l'habitude d'exécuter Fail2Ban sur un serveur Web public et c'était vraiment évident quand j'ai déplacé SSH du port 22. Cela a permis de réduire les attaques opportunistes de plusieurs ordres de grandeur.

Il est très utile de garder les journaux propres.

Si vous constatez des tentatives infructueuses de fonctionnement de sshd sur le port 33201, vous pouvez sans risque supposer que la personne vous cible et vous avez la possibilité de prendre les mesures appropriées si vous le souhaitez. Par exemple, contacter les autorités, enquêter sur l'identité de cette personne ( en faisant des renvois avec les adresses IP de vos utilisateurs enregistrés ou autre), etc.

Si vous utilisez le port par défaut, il sera impossible de savoir si quelqu'un vous attaque ou si ce sont juste des idiots aléatoires qui effectuent des analyses aléatoires.

Non, ça ne va pas. Pas vraiment. Le terme utilisé pour cela est sécurité par obscurité et ce n'est pas une pratique fiable. Vous avez raison dans vos deux points.

Au mieux, la sécurité par obscurité dissuadera les tentatives occasionnelles de recherche de ports par défaut, sachant qu’à un moment donné, ils trouveront quelqu'un qui aura laissé la porte ouverte. Cependant, s’il existe une menace sérieuse à laquelle vous faites face, le fait de changer de port deault ralentira tout au plus l’attaque initiale, mais très légèrement, à cause de ce que vous avez déjà signalé.

Faites-vous une faveur et laissez vos ports configurés correctement, mais prenez les précautions appropriées pour les verrouiller avec un pare-feu, des autorisations, des ACL, etc.

C'est un peu obscur, mais pas un ralentisseur important sur la route du piratage. Il est plus difficile de prendre en charge la configuration à long terme, car tout ce qui concerne ce service doit être expliqué sur les différents ports.

Il était une fois une bonne idée pour éviter les vers réseau, car ceux-ci avaient tendance à analyser un seul port. Cependant, le temps du ver qui se multiplie rapidement est maintenant passé.

Comme d'autres l'ont fait remarquer, changer le numéro de port ne vous offre pas beaucoup de sécurité.

J'aimerais ajouter que changer le numéro de port peut en réalité nuire à votre sécurité.

Imaginez le scénario simplifié suivant. Un pirate analyse 100 hôtes. Quatre-vingt-dix-neuf de ces hôtes ont des services disponibles sur ces ports standard:

Port    Service
22      SSH
80      HTTP
443     HTTPS

Mais il y a aussi un hôte qui se démarque de la foule, car le propriétaire du système a essayé de masquer leurs services.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Maintenant, cela pourrait être intéressant pour un pirate, car l'analyse suggère deux choses:

1. Le propriétaire de l'hôte tente de masquer les numéros de port sur son système. Peut-être que le propriétaire pense qu'il y a quelque chose de précieux dans le système. Ce n'est peut-être pas un système courant.
2. Ils ont choisi la mauvaise méthode pour sécuriser leur système. L'administrateur a commis une erreur en croyant à l'obfuscation du port, ce qui indique qu'il peut s'agir d'un administrateur inexpérimenté. Ils ont peut-être utilisé l’obscurcissement du port à la place d’un pare-feu approprié ou d’un IDS approprié. Ils pourraient également avoir commis d'autres erreurs de sécurité et être vulnérables à de nouvelles attaques de sécurité. Sondons un peu plus loin maintenant, allons-nous?

Si vous étiez un cracker, choisiriez-vous d’examiner l’un des 99 hôtes exécutant des services standard sur des ports standard ou cet hôte utilisant l’obscurcissement de port?

Je vais aller à l'encontre de la tendance générale, au moins partiellement.

Par lui-même , changer de port peut vous faire gagner quelques secondes pendant la recherche, vous permettant ainsi de ne rien gagner en termes réels. Toutefois, si vous combinez l’utilisation de ports non standard à des mesures anti-balayage de port, cela peut accroître considérablement la sécurité.

Voici la situation telle qu'elle s'applique à mes systèmes: Les services non publics sont exécutés sur des ports non standard. Toute tentative de connexion à plus de deux ports à partir d’une même adresse source, qu’elle soit réussie ou non, dans un délai spécifié entraîne l’élimination de tout le trafic provenant de cette source.

Battre ce système nécessiterait soit de la chance (frapper le bon port avant d'être bloqué), soit un scan distribué, ce qui déclenche d'autres mesures, ou un temps très long, qui serait également remarqué et mis en oeuvre.

À mon avis, le déplacement du port sur lequel une application est exécutée n'augmente pas la sécurité du tout, simplement parce que la même application est en cours d'exécution (avec les mêmes forces et faiblesses) juste sur un port différent. Si votre application présente une faiblesse, le fait de déplacer le port écouté sur un autre port ne résout pas le problème. Pire encore, il vous encourage activement à NE PAS remédier à la faiblesse, car elle n’est pas constamment corrigée par une analyse automatisée. Cela cache le vrai problème, à savoir le problème à résoudre.

Quelques exemples:

• "Il nettoie les journaux" - Vous avez alors un problème avec la façon dont vous gérez vos journaux.
• "Cela réduit la surcharge de la connexion" - La surcharge est soit insignifiante (comme dans la plupart des analyses), soit vous avez besoin d'une sorte de filtrage / atténuation du déni de service effectué en amont.
• "Cela réduit l'exposition de l'application" - Si votre application ne résiste pas à l'analyse et à l'exploitation automatisées, votre application présente alors de graves problèmes de sécurité qui doivent être résolus (c'est-à-dire qu'il faut y remédier).

Le vrai problème est administratif: les gens s’attendent à ce que SSH soit à 22 ans, MSSQL à 1433 et ainsi de suite. Les déplacer est une couche supplémentaire de complexité et de documentation requise. Il est très agaçant de s’asseoir près d’un réseau et de devoir utiliser nmap pour savoir où les choses ont été déplacées. Les ajouts à la sécurité sont au mieux éphémères et les inconvénients ne sont pas négligeables. Ne le fais pas. Corrigez le vrai problème.

Vous avez raison de dire que cela n'apportera pas beaucoup de sécurité (car la plage de ports du serveur TCP ne comporte que 16 bits d'entropie), mais vous pouvez le faire pour deux autres raisons:

• comme d'autres l'ont déjà dit: les intrus essayant plusieurs logins peuvent encombrer vos fichiers journaux (même si les attaques par dictionnaire depuis une IP unique peuvent être bloquées avec fail2ban);
• SSH a besoin de la cryptographie à clé publique pour échanger des clés secrètes afin de créer un tunnel sécurisé (opération coûteuse qui, dans des conditions normales, n’a pas besoin d’être effectuée très souvent); Des connexions SSH répétées peuvent entraîner une perte de puissance du processeur .

Remarque: je ne dis pas que vous devriez changer le port du serveur. Je viens de décrire des raisons raisonnables (IMO) pour changer le numéro de port.

Si vous faites cela, je pense que vous devez expliquer clairement à tout autre administrateur ou utilisateur que cela ne doit pas être considéré comme une fonctionnalité de sécurité et que le numéro de port utilisé n’est même pas un secret, et qu’il est décrit comme une fonctionnalité de sécurité. cela apporte une réelle sécurité n'est pas considéré comme un comportement acceptable.

Je peux voir une situation hypothétique où il y aurait un avantage potentiel de sécurité à exécuter votre sshd sur un port alternatif. Ce serait dans le cas où une vulnérabilité à distance exploitée de manière triviale est découverte dans le logiciel sshd que vous exécutez. Dans un tel scénario, exécuter votre sshd sur un autre port peut vous donner le temps supplémentaire nécessaire pour ne pas devenir une cible aléatoire.

Moi-même, j’exécute sshd sur un autre port de mes machines privées, mais c’est surtout pour des raisons pratiques que de garder l’encombrement dans /var/log/auth.log. Sur un système multi-utilisateur, je ne considère vraiment pas que le petit avantage de sécurité hypothétique présenté ci-dessus constitue une raison suffisante pour que le problème supplémentaire causé par le fait que sshd ne soit pas détecté sur la partie standard.

Cela augmente légèrement la sécurité. En cela, l'attaquant ayant trouvé le port ouvert doit maintenant déterminer ce qui tourne sur le port. N'ayant pas accès à vos fichiers de configuration (pour le moment :-)), il ne sait pas si le port 12345 utilise http, sshd ou l'un des milliers d'autres services communs. attaquez-le.

Également, comme l’a souligné une autre affiche, les tentatives d’ouverture de session sur le port 22 pourraient être des scriptes sans intelligence, des chevaux de Troie zombies ou même des utilisateurs authentiques qui ont mal entré une adresse IP. Une tentative de connexion au port 12345 est presque certainement un véritable utilisateur ou un attaquant sérieux.

Une autre stratégie consiste à disposer de quelques ports "pièges à miel". Comme aucun utilisateur authentique ne connaît ces numéros de port, toute tentative de connexion doit être considérée comme malveillante et vous pouvez bloquer / signaler automatiquement l'adresse IP incriminée.

Il existe un cas particulier où l'utilisation d'un numéro de port différent rendra votre système plus sécurisé. Si votre réseau exécute un service public tel qu'un serveur Web, mais également un serveur Web à usage interne, vous pouvez bloquer tout accès externe en exécutant un numéro de port différent et en bloquant tout accès externe à partir de ce port.

Pas tout seul. Cependant, ne pas utiliser le port par défaut pour une application particulière (par exemple, SQL Server) forcera votre attaquant à analyser vos ports; Ce comportement peut ensuite être détecté par votre pare-feu ou par d'autres mesures de surveillance, et l'adresse IP de l'attaquant bloquée. En outre, le "script kiddie" moyen sera plus probablement dissuadé si l'outil simple ou le script de commande qu'ils utilisent ne trouve pas d'instance de serveur SQL sur votre machine (car l'outil ne vérifie que le port par défaut).