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


69

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?


30
Une chose que j'ai faite est d'utiliser certains ports par défaut (par exemple, le port 22 SSH) comme pots à miel. Toute personne tentant de se connecter à ces ports est totalement bloquée pendant un xcertain temps. Il s'est avéré efficace contre le balayage des ports. Bien entendu, il ne s'agit que d'un outil de la boîte à outils de sécurité.
Belmin Fernandez le

La question générale sur la sécurité par l'obscurité est posée ici: security.stackexchange.com/questions/2430/…
Tony Meyer le

Eh bien, c’est peut-être un obstacle pour "écrire des enfants"
Lukasz Madon,

1
@BelminFernandez, "un outil dans la boîte à outils de sécurité" ? Non, c'est pour réduire la charge du serveur (performances) et n'a rien à voir avec la sécurité en dehors de la simple illusion de celle-ci. Du point de vue de la sécurité, il est totalement inutile si le serveur est déjà fort et si le serveur est vulnérable, cela ne le rend pas plus sécurisé.
Pacerier

@Pacerier, a convenu que l'effort et l'accent devraient être mis sur la mise en œuvre de pratiques de sécurité plus solides. Cependant, il n'y a aucune raison pour que vous ne puissiez pas faire les deux.
Belmin Fernandez

Réponses:


68

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.


3
D'accord. J'ai constaté une baisse très similaire lorsque j'essayais de déplacer SSH vers un port non standard. Heureusement, avec l'autorisation de mot de passe désactivée, c'est vraiment un non-problème.
EEAA

3
Meilleure réponse ici jusqu'à présent. Tout se résume à qui attaque. Une fois, j'ai aidé à administrer un système qui avait été victime d'une attaque du jour au lendemain par une gamine qui scrutait Vraisemblablement dans MS-RDP, IIS n'était pas exposé par le pare-feu. Notre hôte ne nous autorisant pas à changer le port RDP (hébergement géré), nous avons donc dû rester assis pendant qu'ils travaillaient sur un nouveau modèle pour leur filtrage IDS / IPS. Bien que cela puisse ne pas aider autant pour des serveurs plus établis comme SSH, qui semblent avoir moins de problèmes de sécurité que certains produits MS.
Matt Molnar le

9
Vraiment d'accord. La sécurité est tout au sujet des couches, et plus vous en avez, plus vous êtes en sécurité. Cela peut être une couche faible, mais néanmoins une couche. Tant qu'on ne s'en remet pas à lui seul, cela ne peut que renforcer la sécurité.
Paul Kroon

1
Un autre point sur lequel déplacer SSH hors du port 22 est le grand nombre d'essais SSH et de services, car Fail2Ban peut parfois occuper un temps précieux. Il peut être négligeable sur le matériel haut de gamme, mais certains serveurs plus anciens peuvent connaître des pics de processeur. Son temps de calcul, sa mémoire et sa bande passante peuvent être utilisés pour d’autres tâches.
artifex le

J'ai fait la même chose avec RDP sur Server 2003: cela réduisait considérablement le nombre d'entrées d'authentification ayant échoué dans l'observateur d'événements.
Moshe

43

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.


8
merveilleuse distinction
ZJR

3
+1 C’est le meilleur argument que je connaisse pour changer les numéros de port et, jusqu’à présent, la seule chose qui me
pousserait

2
+1 C'est un très bon point. Les menaces ciblées sont beaucoup plus dangereuses que les sondes aléatoires (les script kiddies ne font que passer à des cibles plus faciles si vous avez une sécurité décente). L'attaquant ciblé peut en savoir beaucoup plus sur des vulnérabilités spécifiques ou même sur la structure de mots de passe. Il est bon de pouvoir reconnaître ces attaques en dehors de l'essaim de spams sur le port 22.
Steven T. Snyder

1
C'est faux. J'ai vu au moins un serveur compromis via une analyse sur un port SSH non standard. Il n'y a aucune raison inhérente pour laquelle un attaquant ne pourrait pas analyser d'autres ports également.
Sven Slootweg

@SvenSlootweg, True, en particulier avec les ordinateurs qui deviennent de plus en plus rapides et économiques, un scan prenant 65535 fois plus longtemps n’est plus beaucoup plus long .
Pacerier

28

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.


17
La projection de mots de passe (forts) et de chiffrement dans l'idée de sécurité par l'obscurité est un peu
exagérée

5
En utilisant seulement 8 caractères avec toute la gamme de caractères alphabétiques et numériques (sans même autoriser les caractères spéciaux), le nombre de combinaisons possibles est de 62 ^ 8 (218 340 105 584 896). 65535 n’est même pas dans le même univers que celui-là, même en utilisant des détecteurs de balayage de port. Remarque, je décote les mots de passe faibles
squillman

3
Encore une fois , "ce n’est pas comme si le port non standard était l’appareil de sécurité complet". Chaque petit geste compte. C'est un réglage de 10 secondes qui, à tout le moins, va empêcher votre serveur de se présenter à quelqu'un qui recherche SSH pour commencer à frapper aux portes.
ceejayoz

8
Meh Garder une trace des ports non standard ne vaut pas la peine dans mon livre. Je suis d'accord pour ne pas être d'accord avec qui que ce soit ... L'ajout de contre-mesures autres que le changement de port fait certainement partie de l'équation et je préférerais de loin que les choses restent en suspens.
squillman

6
D'après ce que j'ai vu, les ports non standard sont devenus assez standard. 2222 pour ssh, 1080, 8080, 81, 82, 8088 pour HTTP. Sinon, cela devient trop obscur et vous vous demandez quel service est sur le port 7201 et pourquoi vous ne pouvez pas vous connecter à ssh sur 7102.
BillThor

13

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é.


2
+1 pour un problème de configuration et de support plus difficile. Vous fait perdre du temps qui pourrait être consacré à sécuriser la porte (au lieu d'avoir à chercher où vous l'avez mis sur votre maison).
Macke

12

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?


14
Je regarderais les 99 hôtes à moins que l'expérience m'a enseigné autrement. Quelqu'un qui déplace des ports est probablement plus enclin à patcher et à sécuriser, si vous me le demandez.
ceejayoz

4
Je regardais l'hôte 1 qui se démarquait, à la moindre occasion que certains PFY se disent: "Si je change les numéros de port, JE SUIS INVINCIBLE!" mais le mot de passe root est défini sur "mot de passe".
Andrew

3
@Ceejayoz, complètement d'accord. J'exécute SSH sur 2222, pas de valeur de sécurité, mais coupe les kiddies de script. J'imagine qu'ils sont plus susceptibles de m'ignorer aussi, prenant la peine de changer de port, ont probablement également pris d'autres mesures. De toute évidence, la configuration par défaut n'est pas complète ...
Chris S

1
Je comprends que tout le monde n’est pas d’accord avec mon opinion. Mais, selon mon expérience, de nombreux propriétaires de système utilisaient l'obscurcissement de port, mais ils commettaient des erreurs telles que ne pas mettre à jour OpenSSH après l'exposition de vulnérabilités de sécurité critiques, ou utilisaient des clés SSH non chiffrées d'un système universitaire partagé, etc. ces systèmes étaient des cibles juteuses.
Stefan Lasiewski

3
Par extension: en passant à un port non standard, vous êtes plus susceptible de décourager les script kiddies, mais également plus susceptible d'intriguer un pirate informatique expérimenté. Ce qui pose la question: de quoi craignez-vous le plus d'être ciblé?
retarder

9

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.


Si vous combinez cela avec le point d'Andreas Bonini sur les attaques ciblées, c'est un argument de poids pour l'utilisation de ports alternatifs.
JivanAmara

5

À 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.


2

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.


Les fichiers journaux peuvent facilement être épurés avec des filtres appropriés. Si vous parlez des performances du serveur en raison de la réduction des journaux, nous ne parlons plus de sécurité. La performance est un sujet complètement différent.
Pacerier

Pas lorsque l'ordinateur devient inutilisable en raison d'une utilisation excessive du disque.
Curiousguy

Oui, c'est un problème de performance. Les performances sont également importantes, mais ce fil particulier ne traite que de la sécurité. (Pour les besoins de ce fil de discussion, imaginez que vous avez la taille de Google et que Google souhaite réellement utiliser ces données à des fins d'analyse et / ou de vente.)
Pacerier

1

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.


Le scénario ne serait valable que si tous les administrateurs ne prenaient absolument aucune marge de manoeuvre avec ce "temps supplémentaire" pour aller déjeuner , etc.
Pacerier

1

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.


L'augmentation de sécurité d'environ 0,1% doit être comparée à la diminution de sécurité correspondante , ce qui entraînera probablement une perte totale nette de sécurité en fonction du cas d'utilisation et du contexte.
Pacerier

0

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).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.