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 étranger n'utilisera).
Je ne suis pas entièrement convaincu que cela puisse améliorer la sécurité car
Ai-je manqué 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, ils vont scanner votre port et trouver où se trouvent vos portes.
Cependant, le fait de déplacer SSH du port par défaut de 22 dissuadera certaines des attaques non ciblées et amateurs de type script. Il s'agit d'utilisateurs relativement peu sophistiqués qui utilisent des script pour scanner le port de grands blocs d'adresses IP à la fois, spécifiquement pour voir si le port 22 est ouvert et lorsqu'ils en trouvent un, ils lancent une sorte d'attaque sur celui-ci (force brute, attaque par dictionnaire, etc.). Si votre machine se trouve dans ce bloc d'adresses IP scannées 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 peut attaquer. Ergo, il y a une certaine sécurité de bas niveau fournie mais seulement pour ce type d'attaque opportuniste.
À titre d'exemple, si vous avez le temps, connectez-vous à votre serveur (en supposant que SSH est sur le port 22) et relevez toutes les tentatives uniques de SSH qui ont échoué que vous pouvez. Puis déplacez SSH hors de ce port, attendez un peu et recommencez à vous connecter. 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 quand j'ai déplacé SSH du port 22. Cela a réduit les attaques opportunistes de plusieurs ordres de grandeur.
D'accord. J'ai constaté une baisse très similaire en essayant de déplacer SSH vers un port non standard. Heureusement, avec l'authentification par mot de passe désactivée, ce n'est vraiment pas un problème.
La meilleure réponse jusqu'ici. Tout dépend de la personne qui attaque. Une fois, j'ai aidé à administrer un système qui a été frappé par une attaque de type "zero-day" d'un enfant scanneur. Probablement en MS-RDP, car IIS n'était pas exposé par le pare-feu. Notre hébergeur ne nous permettait pas de changer le port RDP (hébergement géré) et nous devions donc rester là pendant qu'ils travaillaient sur un nouveau modèle pour leur filtrage IDS/IPS. Bien que cela puisse ne pas être aussi utile pour des serveurs plus établis comme SSH qui semblent avoir moins de problèmes de sécurité que certains produits MS.
Tout à fait d'accord. La sécurité est une question de couches, et plus vous en avez, plus vous êtes en sécurité. C'est peut-être une couche faible, mais c'est quand même une couche. Tant qu'on ne s'y fie pas uniquement, cela ne peut que renforcer la sécurité.
C'est très utile pour garder les journaux propres.
Si vous voyez des tentatives échouées avec sshd fonctionnant sur le port 33201, vous pouvez supposer sans risque que la personne cible vous et vous avez la possibilité de prendre les mesures appropriées si vous le désirez Par exemple, contacter les autorités, enquêter sur l'identité de cette personne (en recoupant 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 s'il s'agit simplement d'idiots qui effectuent des analyses au hasard.
+1 C'est le meilleur argument en faveur du changement de numéro de port que j'aie jamais entendu et, jusqu'à présent, la seule chose qui m'inciterait à le faire.
+1 C'est un excellent point. Les menaces ciblées sont beaucoup plus dangereuses que les sondes aléatoires (les script gamins passent simplement à 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 des modèles de mots de passe. Il est bon de pouvoir reconnaître ces attaques en dehors de l'essaim de spam sur le port 22.
Non, ça ne l'est pas. Pas vraiment. Le terme pour cela est La sécurité par l'obscurité et ce n'est pas une pratique fiable. Vous avez raison sur les deux points.
Au mieux, la sécurité par l'obscurité dissuadera les tentatives occasionnelles qui se contentent de rechercher les ports par défaut en sachant qu'à un moment donné, ils trouveront quelqu'un qui a laissé la porte d'entrée ouverte. Cependant, si vous êtes confronté à une menace sérieuse, le fait de changer le port d'alerte ralentira tout au plus l'attaque initiale, mais seulement de façon marginale à cause de ce que vous avez déjà souligné.
Faites-vous une faveur et laissez vos ports configurés correctement, mais prenez les précautions nécessaires pour les verrouiller avec un pare-feu approprié, des autorisations, des ACL, etc.
Il y a 65535 ports. En choisissant un port aléatoire, vous obtiendrez un mot de passe de 16 bits.
Pourquoi ? Un mot de passe fort est juste une chaîne de caractères plus obscure qu'un mot de passe faible. Ce n'est pas comme si le port non standard était le dispositif de sécurité tout entier.
En utilisant seulement 8 caractères avec la gamme complète des caractères alphabétiques et numériques (et 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 cela, même en utilisant des détecteurs de port scan. Notez que je ne tiens pas compte des mots de passe faibles.
C'est un léger niveau d'obscurité, mais pas un obstacle important sur la route du piratage. C'est une configuration plus difficile à prendre en charge à long terme, car tout ce qui communique avec ce service particulier doit être informé du port différent.
Il fut un temps où c'était une bonne idée pour éviter les vers de réseau, car ceux-ci avaient tendance à ne scanner qu'un seul port. Cependant, l'époque du ver qui se multiplie rapidement est désormais révolue.
Comme d'autres l'ont souligné, la modification du numéro de port ne vous offre pas une grande sécurité.
J'aimerais ajouter que la modification du numéro de port peut en fait être préjudiciable à votre sécurité.
Imaginez le scénario simplifié suivant. Un pirate scanne 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 HTTPSMais il y a un hôte qui sort du lot, parce que le propriétaire du système a essayé d'obscurcir ses services.
Port Service
2222 SSH
10080 HTTP
10443 HTTPSCela pourrait être intéressant pour un pirate, car le scan suggère deux choses :
Si vous étiez un pirate, choisiriez-vous de jeter un coup d'œil à l'un des 99 hôtes exécutant des services standard sur des ports standard, ou à cet hôte qui utilise l'obfuscation de port ?
Je regarderais du côté des 99 hôtes, à moins que l'expérience ne m'ait appris autre chose. Quelqu'un qui déplace des ports est probablement plus susceptible de patcher et de sécuriser, si vous voulez mon avis.
Je regarderais le seul hôte qui sort du lot, au cas où un PFY aurait pensé "Si je change les numéros de port, JE SUIS INVINCIBLE !" mais que le mot de passe root soit défini sur "password".
@Ceejayoz, tout à fait d'accord. J'exécute SSH sur 2222, aucune valeur de sécurité mais réduit considérablement les script enfants. J'imagine qu'ils sont plus susceptibles de m'ignorer aussi, ils ont pris la peine de changer le port, ils ont probablement pris d'autres mesures aussi. Manifestement, il n'y a pas que la configuration par défaut...
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
31 votes
Une chose que j'ai faite est d'utiliser certains ports par défaut (par exemple, le port 22 de SSH) comme pots de miel. Toute personne qui tente de se connecter à ces ports est entièrement bloquée pour les raisons suivantes
xde temps. Il s'est avéré efficace contre le balayage des ports. Bien entendu, il ne s'agit que d'un outil parmi d'autres dans la boîte à outils de la sécurité.0 votes
La question générale de la sécurité par l'obscurité est posée ici : security.stackexchange.com/questions/2430/
0 votes
C'est peut-être un obstacle pour les "scripting kids".
1 votes
@BelminFernandez, "un outil dans la boîte à outils de la sécurité" ? Non, c'est pour réduire la charge du serveur (performance) et a rien à voir avec la sécurité en plus de la simple illusion de celle-ci. En termes de sécurité, c'est totalement inutile si le serveur est déjà solide, et si le serveur est vulnérable, cela ne le rend pas plus sûr.
0 votes
@Pacerier, je suis d'accord pour dire 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 laquelle vous ne pouvez pas faire les deux.
0 votes
@BelminFernandez, La raison est qu'il y a des scénarios où faire du travail supplémentaire ne donne pas de sécurité supplémentaire. Voir http://serverfault.com/questions/316516/.... .