La modification du numéro de port par défaut augmente-t-elle réellement la sécurité ?

Je vais aller à l'encontre de la tendance générale, du moins en partie.

Par lui-même Le fait de changer de port peut vous faire gagner quelques secondes pendant la recherche, mais ne vous apporte rien en termes réels. Cependant, si vous combinez l'utilisation de ports non standard avec des mesures anti-scanner de ports, vous pouvez obtenir une augmentation de la sécurité qui en vaut vraiment la peine.

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 laps de temps donné, entraîne l'abandon de tout le trafic provenant de cette source.

Pour déjouer ce système, il faudrait soit de la chance (toucher le bon port avant d'être bloqué), soit un scan distribué, qui déclenche d'autres mesures, soit un temps très long, qui serait également remarqué et suivi.

À mon avis, le déplacement du port sur lequel une application s'exécute n'augmente pas du tout la sécurité - simplement pour la raison que la même application s'exécute (avec les mêmes forces et faiblesses) simplement sur un port différent. Si votre application a une faiblesse, le fait de déplacer le port sur lequel elle écoute vers un port différent ne résout pas cette faiblesse. Pire encore, cela vous encourage activement à NE PAS remédier à cette faiblesse, car elle n'est plus constamment mise en évidence par l'analyse automatique. Cela cache la problème réel qui est le problème qui devrait être résolu.

Quelques exemples :

• "Il nettoie les journaux" - Alors vous avez un problème avec la façon dont vous gérez vos journaux.
• "Il réduit les frais de connexion" - Les frais sont soit insignifiants (comme la plupart des scans), soit vous avez besoin d'une sorte de filtrage ou de déni de service en amont.
• "Elle réduit l'exposition de l'application" - Si votre application ne peut pas résister à l'analyse et à l'exploitation automatisées, elle présente de sérieuses lacunes en matière de sécurité qui doivent être corrigées (c'est-à-dire qu'il faut y apporter des correctifs !).

Le vrai problème est d'ordre administratif : Les gens s'attendent à ce que SSH soit à 22, MSSQL à 1433 et ainsi de suite. Le fait de les déplacer est une couche supplémentaire de complexité et de documentation requise. Il est très ennuyeux de s'asseoir sur un réseau et de devoir utiliser nmap juste 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 faites pas. Résolvez 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 n'a que 16 bits d'entropie), mais vous pouvez le faire pour deux autres raisons :

• comme d'autres l'ont déjà dit : les intrus qui tentent de se connecter à plusieurs reprises peuvent encombrer vos fichiers journaux. (même si les attaques par dictionnaire à partir d'une seule IP peuvent être bloquées avec fail2ban) ;
• Besoins en SSH la cryptographie à clé publique d'échanger des clés secrètes pour créer un tunnel sécurisé (il s'agit d'une opération coûteuse qui, dans des conditions normales, ne doit pas être effectuée très souvent) ; Les connexions SSH répétées peuvent gaspiller la puissance du CPU .

Remarques : Je ne dis pas que vous devez changer le port du serveur. Je décris simplement les raisons raisonnables (IMO) de changer le numéro de port.

Si vous faites cela, je pense que vous devez faire comprendre à tous les autres administrateurs ou utilisateurs que cela ne doit pas être considéré comme une fonction de sécurité, et que le numéro de port utilisé n'est même pas un secret, et que décrire cela comme une fonction de sécurité qui 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 en termes de sécurité à exécuter votre sshd sur un port alternatif. Ce serait dans le scénario où une vulnérabilité à distance trivialement exploitée est découverte dans le logiciel sshd que vous exécutez. Dans un tel scénario, l'exécution de votre sshd sur un port alternatif pourrait vous donner juste le temps supplémentaire dont vous avez besoin pour ne pas être une cible aléatoire de drive-by.

Pour ma part, j'exécute le sshd sur un autre port sur mes machines privées, mais c'est principalement pour des raisons de commodité, afin de ne pas encombrer le fichier /var/log/auth.log. Sur un système multi-utilisateurs, je ne considère vraiment pas que le petit avantage hypothétique de sécurité présenté ci-dessus soit une raison suffisante pour justifier les tracas supplémentaires causés par le fait que sshd ne se trouve pas sur la partie standard.

Cela augmente légèrement la sécurité. En effet, l'attaquant ayant trouvé le port ouvert doit maintenant découvrir ce qui fonctionne sur ce port. N'ayant pas accès à vos fichiers de configuration (pour l'instant :-) ), il n'a aucune idée si le port 12345 exécute http, sshd, ou l'un des milliers d'autres services courants, il doit donc faire un travail supplémentaire pour savoir ce qui fonctionne avant de pouvoir l'attaquer sérieusement.

De plus, comme l'a souligné un autre poster, les tentatives de connexion au port 22 peuvent être le fait d'un script enfantin, d'un trojan zombie ou même d'un véritable utilisateur qui a mal saisi son adresse IP. Une tentative de connexion au port 12345 est presque certaine d'être soit un utilisateur authentique, soit 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/rapporter 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ûr. Si votre réseau exécute un service public tel qu'un serveur Web, mais également un serveur Web à usage interne uniquement, vous pouvez absolument bloquer tout accès externe en utilisant un numéro de port différent et en utilisant les options suivantes blocage tout accès externe à partir de ce port.