La modification du numéro de port par défaut accroît-elle réellement la sécurité?
J'ai vu des conseils disant que vous devriez utiliser des numéros de port différents pour les applications privées (par exemple, intranet, base de données privée, tout ce qu'aucun tiers n'utilisera).
Je ne suis pas entièrement convaincu que cela puisse améliorer la sécurité car
- Les scanners de port existent
- Si une application est vulnérable, elle le reste quel que soit son numéro de port.
Ai-je raté 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é, comme vous le dites, ils vous analyseront les ports et découvriront où se trouvent vos portes.
Cependant, déplacer SSH hors du port par défaut de 22 dissuadera certaines des attaques de type kiddie script non ciblées et amateurs. Ce sont des utilisateurs relativement peu sophistiqués qui utilisent des scripts pour scanner de gros blocs d'adresses IP à la fois spécifiquement pour voir si le port 22 est ouvert et lorsqu'ils en trouveront un, ils lanceront une sorte d'attaque dessus (force brute, attaque par dictionnaire, etc). Si votre machine se trouve dans ce bloc d'adresses IP en cours d'analyse et qu'elle n'exécute pas SSH sur le port 22, elle ne répondra pas et n'apparaîtra donc pas dans la liste des machines que ce script doit attaquer. Ergo, il existe une sécurité de bas niveau mais uniquement pour ce type d'attaque opportuniste.
À titre d'exemple, si vous avez la plongée avec enregistrement de l'heure sur votre serveur (en supposant que SSH est sur le port 22) et retirez toutes les tentatives SSH échouées uniques que vous pouvez. Déplacez ensuite SSH de ce port, attendez un peu et recommencez la plongée. Vous trouverez sans aucun doute moins d'attaques.
J'avais l'habitude d'exécuter Fail2Ban sur un serveur Web public et c'était vraiment, vraiment évident lorsque j'ai déplacé SSH du port 22. Il a coupé les attaques opportunistes par ordre de grandeur.
Il est très utile de garder les journaux propres.
Si vous voyez des tentatives infructueuses avec sshd exécuté sur le port 33201, vous pouvez supposer en toute sécurité que la personne cible vous et vous avez la possibilité de prendre les mesures appropriées si vous le souhaitez. Par exemple, contacter les autorités, enquêter sur qui cette personne peut être (par recoupement 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, non. Pas vraiment. Le terme pour cela est Security by Obscurity et ce n'est pas une pratique fiable. Vous avez raison dans vos deux points.
La sécurité par l'obscurité dissuadera au mieux les tentatives occasionnelles qui se déroulent à la recherche de ports par défaut sachant qu'à un moment donné, ils trouveront quelqu'un qui a quitté la porte d'entrée ouvert. Cependant, s'il y a une menace sérieuse à laquelle vous êtes confronté, le changement du port deault ralentira au plus l'attaque initiale, mais seulement de manière marginale à cause de ce que vous avez déjà souligné.
Faites-vous plaisir et laissez vos ports correctement configurés, mais prenez les précautions nécessaires pour les verrouiller avec un pare-feu, des autorisations, des listes de contrôle d'accès, etc. appropriés.
C'est un léger niveau d'obscurité, mais pas un ralentisseur significatif sur la route du piratage. C'est une configuration plus difficile à prendre en charge à long terme, car tout ce qui concerne ce service particulier doit être informé des différents ports.
Il était une fois une bonne idée pour éviter les vers de réseau, car ceux-ci avaient tendance à scanner un seul port. Cependant, le temps du ver se multipliant rapidement est désormais révolu.
Comme d'autres l'ont souligné, la modification du numéro de port ne vous offre pas beaucoup de sécurité.
Je voudrais ajouter que la modification du numéro de port peut en fait 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 ensuite un hôte qui se démarque de la foule, car le propriétaire du système a tenté de brouiller ses 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:
- 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 ordinaire.
- Ils ont choisi la mauvaise méthode pour sécuriser leur système. L'administrateur a fait une erreur en croyant à l'obscurcissement de port, ce qui indique qu'il peut s'agir d'un administrateur inexpérimenté. Peut-être ont-ils utilisé l'obscurcissement de port au lieu 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 à des attaques de sécurité supplémentaires. Voyons maintenant un peu plus loin, d'accord?
Si vous étiez un pirate, choisiriez-vous de jeter un œil à l'un des 99 hôtes exécutant des services standard sur des ports standard, ou à cet hôte qui utilise l'obscurcissement de port?
Je vais aller à l'encontre de la tendance générale, au moins partiellement.
De lui-même, le passage à un autre port peut vous faire gagner quelques secondes pendant qu'il est recherché, donc vous ne gagnez rien en termes réels. Cependant, si vous combinez l'utilisation de ports non standard avec des mesures anti-analyse de port, cela peut donner une augmentation vraiment intéressante de 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 adresse source unique, réussie ou non, dans un délai spécifié entraîne la suppression de tout le trafic provenant de cette source.
Pour battre ce système, il faudrait soit de la chance (atteindre le bon port avant d'être bloqué), soit un scan distribué, qui déclenche d'autres mesures, ou très longtemps, qui serait également remarqué et appliqué.
À mon avis, déplacer le port sur lequel une application s'exécute n'augmente pas du tout la sécurité - simplement parce que la même application s'exécute (avec les mêmes forces et faiblesses) que sur un port différent. Si votre application présente une faiblesse, le déplacement du port sur lequel elle écoute vers un autre port ne résout pas la faiblesse. Pire, cela vous encourage activement à NE PAS remédier à la faiblesse car maintenant elle n'est pas constamment martelée par une analyse automatisée. Il cache le vrai problème qui est le problème qui devrait être résolu.
Quelques exemples:
- "Il nettoie les journaux" - Ensuite, vous avez un problème avec la façon dont vous gérez vos journaux.
- "Il réduit la surcharge de connexion" - La surcharge est insignifiante (comme la plupart des analyses) ou vous avez besoin d'une sorte de filtrage/atténuation du déni de service 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 de graves lacunes de sécurité qui doivent être corrigées (c'est-à-dire, maintenez-la corrigée!).
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 de complexité supplémentaire et la documentation requise. C'est très ennuyeux de s'asseoir sur un réseau et d'avoir à utiliser nmap juste pour comprendre 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. Résolvez le vrai problème.
Vous avez raison, cela n'apportera pas beaucoup de sécurité (car la plage de ports du serveur TCP ne possède 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 de nombreuses connexions peuvent encombrer vos fichiers journaux (même si les attaques par dictionnaire à partir d'une seule IP peuvent être bloquées avec fail2ban);
- SSH a besoin de cryptographie à clé publique pour échanger des clés secrètes afin de créer un tunnel sécurisé (il s'agit d'une opération coûteuse qui, dans des conditions normales, n'a pas besoin d'être effectuée très souvent. ); les connexions SSH répétées pourraient gaspiller la puissance du processeur.
Remarque: je ne dis pas que vous devez changer le port du serveur. Je viens de décrire des raisons raisonnables (OMI) de changer le numéro de port.
Si vous faites cela, je pense que vous devez indiquer clairement à tous les autres administrateurs ou utilisateurs que cela ne devrait 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 le décrivant 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 pour la sécurité à exécuter votre sshd sur un autre port. Ce serait dans le scénario où une vulnérabilité distante exploitée de manière triviale est découverte dans le logiciel sshd que vous exécutez. Dans un tel scénario, l'exécution de votre sshd sur un autre port peut vous donner juste le temps supplémentaire dont vous avez besoin pour ne pas être une cible de passage aléatoire.
Moi-même, j'exécute le sshd sur un port alternatif sur mes machines privées, mais c'est principalement pour faciliter le désordre dans /var/log/auth.log. Sur un système multi-utilisateur, je ne considère vraiment pas le petit avantage de sécurité hypothétique présenté ci-dessus comme une raison suffisante pour que les tracas supplémentaires causés par le sshd ne soient pas trouvés sur la pièce standard.
Cela augmente légèrement la sécurité. En ce sens, l'attaquant ayant trouvé le port ouvert doit maintenant déterminer ce qui fonctionne sur le port. N'ayant pas accès à vos fichiers de configuration (encore :-)), il n'a aucune idée si le port 12345 exécute http, sshd ou l'un des mille autres services communs, ils doivent donc faire un travail supplémentaire pour déterminer ce qui fonctionne avant de pouvoir sérieusement l'attaquer.
Aussi, comme l'a souligné une autre affiche, alors que les tentatives de connexion au port 22 peuvent être des script kiddies, des chevaux de Troie zombies ou même des utilisateurs authentiques qui ont mal tapé une adresse IP. Une tentative de connexion au port 12345 est presque certainement un utilisateur authentique ou un attaquant sérieux.
Une autre stratégie consiste à disposer de quelques ports "pièges à miel". Aucun utilisateur authentique ne connaissant 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 certainement 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 exécutant sur un numéro de port différent et blocage tout accès externe depuis ce port.
Pas tout seul. Cependant, ne pas utiliser le port par défaut pour une application particulière (par exemple, SQL Server) forcera fondamentalement votre attaquant à analyser vos ports; ce comportement peut alors être détecté par votre pare-feu ou d'autres mesures de surveillance, et l'adresse IP de l'attaquant bloquée. En outre, le "script kiddie" moyen sera plus probablement dissuadé lorsque le simple outil ou script de commande qu'il utilise ne trouve pas d'instance de serveur SQL sur votre machine (car l'outil vérifie uniquement le port par défaut).