Cela n’est pas aussi utile que le prétendent certaines personnes, mais au moins, cela réduira au minimum l’impact sur vos fichiers journaux, car de nombreuses tentatives de connexion brutale utilisent uniquement le port par défaut au lieu d’analyser pour voir si SSH écoute ailleurs. Certaines attaques vont rechercher SSH ailleurs, alors ce n’est pas une solution miracle.
Si votre serveur doit être un hôte partagé, plutôt que de simplement répondre aux besoins de vos projets, l’utilisation d’un port autre que celui par défaut peut s'avérer difficile, car vous devrez l'expliquer encore et encore à vos utilisateurs. terminé quand ils oublient et que leurs programmes clients ne parviennent pas à se connecter au port 22!
Un autre problème possible avec SSH sur un port non standard est le cas où vous rencontrez un client avec un ensemble de filtres sortant restrictif, qui ne peut pas se connecter à votre port personnalisé car son filtre autorise uniquement, par exemple, les ports 22, 53 et 80. et 443 comme destination pour les nouvelles connexions sortantes. Ceci est rare, mais certainement pas inouï. De même, certains FAI peuvent voir le trafic chiffré sur un port autre que ceux sur lesquels il est généralement prévu (port 443 ou HTTPS, 22 pour SSH, etc.) comme tentative de masquage d'une connexion P2P et limitation (ou blocage) la connexion de manière incommode.
Personnellement, je garde SSH sur le port standard pour plus de commodité. Tant que les précautions habituelles sont prises (mot de passe fort / stratégie de clé, restriction des connexions à la racine, ...), il n’ya pas lieu de s’inquiéter et le problème de croissance du fichier journal lorsque vous êtes victime d’une attaque par force brute peut être atténué à l’aide d’outils tels que en tant que fial2ban pour bloquer temporairement les hôtes qui fournissent un trop grand nombre de mauvais identifiants d'authentification dans un laps de temps donné.
Quel que soit le port que vous avez choisi, si vous vous éloignez de 22, assurez-vous qu'il est inférieur à 1024. Sous la plupart des configurations de type Unix-a-a dans leur configuration par défaut, seuls les utilisateurs racine (ou les utilisateurs du groupe racine) peuvent écouter sur les ports inférieurs à 1024, mais tout utilisateur peut écouter sur les ports les plus élevés. L'exécution de SSH sur un port supérieur augmente le risque qu'un utilisateur malhonnête (ou piraté) parvienne à bloquer votre démon SSH et à le remplacer par son propre proxy ou par un autre.
Je suis le seul utilisateur de ce serveur. Merci d'avoir clarifié le problème 1024+. J'aurais utilisé un port 48xxx si j'avais choisi. Quoi qu'il en soit, à ce stade, je ne comprends toujours pas si c'est utile ou non = /
dynamique le
16
+1 pour le bit> 1024.
MattC
26
C'est une forme simple (mais étonnamment efficace) de sécurité par l'obscurité .
Si votre serveur SSH n'est pas sur le port 22, les personnes qui parcourent Internet tout entier sont moins susceptibles de trouver des mots de passe faibles pour les comptes par défaut. Si vous analysez tout le réseau, vous ne pouvez pas vous permettre de vérifier tous les 64k ports possibles pour trouver le serveur SSH.
Cependant, si quelqu'un vous cible activement, cela ne présente aucun avantage, puisqu'un simple nmapbalayage unique révélera le port sur lequel il est exécuté.
"vérifier tous les 64k ports possibles" ... Exécuter SSH sur un port supérieur à 1023 est tout simplement faux. Cela rend le système plus vulnérable que de le laisser fonctionner dans son port par défaut.
Juliano
3
@ Juliano - s'il vous plaît expliquer. Tout simplement parce que vous devez être root pour écouter sur un port privilégié ne fait pas (autant que je sache) , il l' insécurité à courir sur un port non privilégié.
Alnitak
4
À propos, ce n’est pas de la sécurité par l’obscurité, sinon vous devrez également appeler l’authentification par mot de passe de la même manière. La sécurité par l'obscurité, c'est quand la mise en œuvre n'est pas révélée. Ici, la mise en œuvre est clairement indiquée (c'est "j'ai changé le port de service"), et le secret ("quel port?") Est toujours secret.
Juliano
5
@ John - en fait, je vois le point de @ Juliano. Cela ne rend pas le démon SSH intrinsèquement moins sûr, mais dans le cas général, l’exécution sur un port non privilégié annule l’hypothèse normale selon laquelle le démon a été démarré par root . Donc, si vous pouvez en quelque sorte arrêter ce démon (par exemple en le faisant sur DoSing), vous pouvez démarrer votre propre faux démon à sa place sans avoir besoin d'un exploit root. Ce faux démon pourrait alors capturer suffisamment de détails pour permettre d'autres exploits.
Alnitak
2
@John, c'est vrai - l'attaquant doit toujours avoir un accès suffisant pour démarrer lui-même un nouveau démon. Le point clé est qu’ils n’ont plus besoin d’ un accès root pour le démarrer.
Alnitak
21
Pour vraiment éviter les attaques par force brute, il est toujours important de suivre certaines étapes:
Installer denyhosts ou fail2ban
Limite le nombre de connexions par seconde sur le port ssh
Changer le port ssh
Connexion root refusée
Activer l'authentification par clé au lieu du mot de passe
Cela semble être une bonne liste, à l'exception de la partie sur le changement de port avec laquelle je ne suis pas vraiment d'accord, c'est trop d'obscurité. Un scanner de port moderne le trouvera en quelques secondes? (et de nombreux réseaux ne laissent pas sortir le trafic de port aléatoire, généralement limité à 22, 80 et 443)
Oskar Duveborn
1
Le changement de port limite les attaques par force brute qui vérifient que ssh fonctionne sur le port par défaut, ainsi si l'attaque est plus grave, l'attaquant ne peut alors qu'analyser les ports de votre réseau / hôte.
Ali Mezgani
1
En fait, je pense que derrière un bon pare-feu, si vous maintenez vos services à jour et si vous modifiez leur paramètre par défaut, vous pourriez être à l'abri des attaques de personnes malveillantes. et peut-être pas des exploits de jour ou des attaques inconnues
Ali Mezgani
2
L'utilisation de denyhosts / fail2ban atténue la nécessité de changer de port ou de requérir des clés. Si vous n'autorisez pas les mots de passe, il est inutile d'utiliser denyhosts / fail2ban ou de changer de port.
Jeremy L
1
L'utilisation de denyhosts / fail2ban n'atténue pas nécessairement le besoin de mesures de sécurité supplémentaires. Le but de la sécurité est de créer autant d’obstacles que possible pour les utilisateurs qui tentent de contourner la sécurité. Bien sûr, vous n'avez probablement pas besoin de changer le port de 22 à 2222, mais supposons qu'un autre administrateur arrive et réactive le mot de passe ... vous aurez toujours plusieurs autres ralentisseurs en place. Chaque étape énumérée ci-dessus donne à l'administrateur un pourcentage proche de l'impossibilité d'une sécurité à 100%.
Patrick R
12
Oui, c'est utile car cela permet d'éviter les attaques par force brute et de garder les journaux clairs :)
en ce qui concerne le numéro de port qui vous appartient, j’ai vu des entreprises en utiliser 1291 assez souvent. J'utilise quelque chose de plus élevé, juste pour éviter certains scripts.
Ne pas autoriser les connexions root ssh et changer le numéro de port et peut-être quelque chose comme fail2ban et vous devriez être en or. ajoutez iptables pour faire bonne mesure et tenez-vous au courant, vous ne devriez pas avoir de problèmes.
Mais regardez la réponse de David Spillett pour savoir pourquoi le port 1291 (supérieur à 1024) pourrait être dangereux.
Konerak
Si vous conseillez d'utiliser un port non privilégié deux ans après de nombreuses autres meilleures réponses, préparez peut-être une meilleure raison que «j'ai vu des entreprises le faire». J'ai vu des entreprises faire beaucoup de choses. J'ai rarement envie de suivre leur exemple.
underscore_d
11
L'utilisation d'un port ssh non standard nécessiterait davantage d'explications et de documentation, et la réponse aux courriers électroniques "Je ne peux pas me connecter".
Je considère que les avantages suivants de l'exécution de sshd sur un port non standard sont plus importants que les problèmes qu'il crée:
99,9999% des attaques par force brute sont effectuées par des bots qui ne recherchent que le port 22 et ne perdent jamais de temps à essayer de découvrir le port non standard. Les attaques par force brute et les contre-mesures telles que denyhosts ou fail2ban consomment des ressources, que vous économiserez en exécutant simplement le serveur ssh sur un port non standard.
Vous vous débarrasserez de tous les rapports inutiles sur les robots qui tentent de s'introduire dans votre système. Si une adresse IP apparaît dans le rapport d'échec de connexion, il y a de fortes chances que ce soit un humain.
De plus, si vous voulez être vraiment méchant, vous pouvez toujours exécuter un faux sshd (avec DenyUsers * ) sur le port standard 22, alors que votre sshd habituel fonctionne sur le port 54321. Cela vous assurera que tous les robots et les intrus faramineux resteront à jamais. essayez de vous connecter à un service qui refuse toutes les connexions, car personne ne songe à essayer de trouver votre vrai service sshd.
Cela pourrait entraîner encore plus d'appels de support.
Brad Gilbert
3
Cela est vrai, mais une sécurité renforcée a un prix. :)
Né pour monter
11
Faire cela pour une raison de "sécurité" est faux. C'est le meilleur exemple de sécurité par obscurité qui n'est pas sécurité.
Si vous voulez garder vos journaux un peu plus légers et plus propres, alors oui, c’est utile, car vous n’obtiendrez pas autant de tentatives de frappe de port / script-kiddy bruteforce.
Oui. Lorsque j’avais ssh sur le port 22, il y avait plus de 20000 tentatives de mot de passe infructueuses qui apparaissaient dans mes journaux chaque jour. Ce qui signifiait que je recevais un courriel d'avertissement de sécurité chaque jour. L'authentification par mot de passe étant désactivée - vous devez disposer d'une clé privée appropriée pour vous connecter - je ne m'inquiétais donc pas de l'arrivée de quelqu'un, mais je préfère recevoir des courriels d'avertissement de sécurité uniquement lorsque quelque chose de réel se produit.
Jdege
10
Je voudrais exécuter ssh sur le port standard et utiliser quelque chose comme fail2ban ou denyhosts pour limiter le nombre d'attaques par dictionnaire.
Une autre option consiste à désactiver la connexion avec les mots de passe altogheter et à n'autoriser que les connexions avec ssh-keys.
Parce qu'il y a beaucoup de personnes mal intentionnées qui analysent toutes les adresses IP de serveur à la recherche de ports ouverts dans le but d'exploiter. J'avais des attaques de marteau sur mon port SSH toute la journée, jusqu'à ce que je le déplace sur un autre port et sur une adresse IP qui n'était plus liée à aucun de mes sites Web.
C'est utile en ce que les script-bots qui tentent des attaques par force brutale de deviner le mot de passe se concentrent généralement sur le port 22, donc changer les ports les jette généralement. Vous devrez équilibrer la valeur d'atténuer ce risque avec la difficulté de configurer les clients ssh pour qu'ils se connectent au port non standard (ce n'est pas très pénible si de nombreux utilisateurs ne se connectent pas, il est vrai).
Vous pouvez également limiter le risque de force brute en désactivant l'authentification par mot de passe et en exigeant une authentification par clé RSA.
En général, je ne change pas le port sur SSHD, je ne peux donc pas suggérer un autre numéro, mais consultez la liste des ports couramment utilisés pour trouver un autre numéro (c'est-à-dire un numéro qui n'est pas utilisé par autre chose et qui pourrait donc être scanné). .
Je change toujours mon disque SSH pour utiliser le port 2222, tout le monde qui aurait besoin d'entrer dans mes serveurs le sait et ce n'est pas un secret. Cela n'apporte absolument aucun gain de sécurité (à moins que le pirate informatique potentiel ne soit un imbécile absolu).
Le seul avantage que je tire de cela est que le journal d'authentification n'a pas un million de tentatives de connexion infructueuses pour 'root', 'alice', 'bob', 'sally', 'admin', etc.
La sécurité par l’obscurité s’est avérée inutile. En général, je configure l’accès ssh avec le port standard pour toutes les raisons mentionnées ci-dessus (problèmes de client lors de la reconfiguration, problèmes de pare-feu et de proxy, etc.).
En plus de cela, je désactive toujours les identifiants root et les authentifications par mot de passe et, en dernier lieu, j'utilise fail2ban pour me débarrasser de ces messages gênants dans le syslog. Dans Debian / Ubuntu, c'est aussi simple que de taper aptitude install fail2ban. La configuration par défaut fonctionne plutôt bien, mais je règle généralement certains paramètres pour qu'ils soient plus restrictifs, avec un délai d'interdiction plus long (au moins un jour) et seulement deux tentatives d'authentification ayant échoué comme déclencheur de l'interdiction.
Je dirais que la chose contre laquelle vous vous protégez le plus lorsque vous changez le port SSH sont des analyses automatisées qui tenteront d’obtenir un accès en utilisant des noms d’utilisateur / mots de passe standard. Si vos règles de mot de passe sont strictes, vous ne devriez pas avoir à vous soucier de leur.
sans oublier qu'un scanner de port essaiera également d'autres ports.
Jim Deville
4
Si vous désactivez les connexions par mot de passe sur votre serveur (ce qui est vivement recommandé), la modification du port SSH est totalement inutile. En désactivant les connexions par mot de passe (et en exigeant une authentification basée sur une clé), vous éliminez la possibilité de tentatives de mot de passe brutales. Vous ne gagnez donc rien en utilisant des numéros de port.
Si vous continuez à autoriser l'authentification par mot de passe, vous vous exposez à la possibilité d'une tentative de force brute réussie ou - plus communément, d'après mon expérience - votre mot de passe est compromis parce que vous le tapez lors de l'utilisation d'un système en cours d'exécution. un keylogger.
Si vous êtes / complètement inutile / complètement inutile pour la sécurité /, je suis d’accord. Changer le port est utile pour garder le bruit dans le journal d'authentification.
Chris S
"et nécessitant une authentification par clé"? qu'est-ce que c'est
dynamique
1
@ yes123, SSH peut utiliser des paires de clés public-privé pour authentifier un utilisateur au lieu d'un mot de passe. Leur paire de clés peut également être protégée par un mot de passe, offrant ainsi une authentification à deux facteurs (quelque chose que vous savez = mot de passe; quelque chose que vous avez = fichier de clé). Si vous implémentez cela, vous pouvez désactiver les connexions par mot de passe (ainsi, une personne connaissant votre mot de passe local ne peut pas entrer avec le fichier de clé et le mot de passe du fichier de clé). Les mots de passe sont relativement peu sûrs par rapport aux clés, des millions de fois plus faciles à utiliser que les paires de clés (bien que cela reste difficile en général). Voir man ssh-keygenpour beaucoup d'informations.
Chris S
@ yes123, les différentes pages de manuel relatives à ssh (sshd, sshd_config, ssh, ssh_config) sont des lectures utiles. Ce document ressemble à un bon tutoriel sur l’authentification par clé publique avec ssh.
larsks
2
Malgré le fait de ressembler à une "sécurité par obscurité" typique, j’estimerais que cela a du sens, car analyser tous les ports possibles (~ 64k) est beaucoup plus coûteux en temps que l’un d’eux.
Mais je peux ajouter que le "port frappant" est bien meilleur.
Pas une réponse, mais trop longue pour un commentaire, je vais donc faire cette CW.
Je réfléchis à celui-ci depuis un moment et j'en suis venu à la conclusion qu'il y a beaucoup de vérité dans ce que Juliano dit dans les commentaires sur la réponse d'Alnitak. Néanmoins, je trouve qu'en exécutant SSH sur le port 22, il est beaucoup trop facile de lancer des attaques de toutes sortes contre celui-ci.
Pour résoudre ce problème, j'exécute mes serveurs SSH internes sur le port 22 et utilise le pare-feu pour transférer le port haut sur 22 sur les ordinateurs cibles. Cela donne une certaine sécurité grâce à l'obscurité tout en maintenant la sécurité d'un port bas, comme l'a souligné Juliano.
La sécurité par l'obscurité n'est pas un principe auquel je souscris normalement et il est souvent souligné qu'un simple scan de port révélera le port cible, rendant ainsi l'obscurité sans valeur. Pour résoudre ce problème, mes pare-feu (Smoothwall Express), au travail et à la maison, utilisent un script appelé Guardian Active Response, déclenché par des alertes Snort. D'après les observations, je peux vous dire que lorsque vous frappez plus de 3 ports différents de la même source, vos paquets sont perdus jusqu'à l'heure de réinitialisation prédéfinie. Cela rend assez difficile et prend beaucoup de temps pour exécuter une analyse de port, rendant l'obscurité vraiment utile. En fait, cela m'a fait taire tellement de fois dans le passé que j'ai défini une exclusion pour mon adresse IP source (à la maison ou au bureau).
Bonne idée avec le port en avant, John! Je pense que nous avons tous les deux appris quelque chose :)
Alnitak,
1
Le problème que vous avez, c'est que le pare-feu est configuré pour autoriser uniquement certaines adresses IP à se connecter, et le patron en a assez d'ouvrir d'autres adresses IP lorsqu'il est en déplacement. Si vous verrouillez certaines adresses IP au niveau du pare-feu, cela peut être pénible.
Deux choses que je pense ici. Changer le port protège contre les attaques automatisées. C'est à peu près tout, mais cela représente une grande partie du trafic d'attaque moyen… des scripts automatisés analysant les réseaux. Si vous modifiez le port par défaut, ces attaques devraient disparaître. Cela a donc du sens à cet égard. Mais cela ne fait rien contre une attaque dirigée, l’attaquant pouvant simplement scanner à partir de Nessus ou de NMAP pour déterminer le ou les ports que vous utilisez si vous avez un petit ami spécial qui vous hait suffisamment.
Deuxièmement, si vous utilisez des serveurs de type UNIX, vous pouvez installer un utilitaire tel que Denyhosts pour arrêter les attaques. Si vous installez denyhosts, il surveille les tentatives de connexion incorrectes et après (quel que soit le nombre que vous déterminez) a échoué, il interdira l'IP pendant une période de temps que vous spécifiez. Denyhosts peut également parler à d'autres hôtes de denyhost et transmettre des listes d'interdiction. Ainsi, si un attaquant est verrouillé hors du système Linux de Fred au Montana, votre système obtiendra également cette adresse IP pour interdiction. Très utile tant que vos utilisateurs se souviennent de leurs mots de passe.
Tout dépend de vos scénarios d'utilisation. Combien de programmes avez-vous qui sont "pénibles" pour changer le port de connexion pour SSH / SCP (et s’ils ne le permettent pas ou ne gênent pas, vous devez vraiment envisager de changer de fournisseur, personnellement). S'il ne s'agit que d'une peur potentielle, je dirais que ce n'est pas un problème. Et voici votre patron, qui demande quelque chose qui n’est pas complètement farfelu, car beaucoup d’administrateurs système basculent le port SSH (avec un flak de ceux qui détestent tout ce qui sent la sécurité même à travers l’obscurité ... mais cela réduit vraiment la le bruit de fond cruft des balayages automatisés.)
En bouleversant - changer les ports bloque les scripts automatisés et la plupart du trafic. Ne pas arrêter les attaquants dirigés. Pensez également à installer un utilitaire d'interdiction automatique. La sécurité dans les couches ne vous fait pas mal si c'est bien fait et changer de ports aide plus que ça fait mal dans la plupart des situations.
J'utilise SSH sur le port> 1024 depuis plus de 5 ans maintenant. Depuis lors, je n'ai vu aucune tentative d'analyse de port dans mon fichier journal (sauf de ma propre initiative). Il y a mes serveurs que j'administre qui utilisent le port> 1024.
Beaucoup de serveurs SSH qui fonctionnent sur le port> 1024 ont leurs propres sites Web, ce qui est assez populaire.
Si le serveur SSH fonctionne dans ma propre entreprise, j'ai peut-être déjà posté l'adresse IP de ce serveur ici afin que vous puissiez essayer de pirater le serveur. Malheureusement, le serveur SSH n'est pas le mien. ;-)
Mais il y a d'autres choses que vous devez configurer pour le rendre sécurisé. SSH> 1024 ne suffirait pas. Le numéro de port ne doit pas être dans le fichier / etc / services, il faut utiliser le transfert de port (par exemple, le port 1124-> 22), l'accès direct à la racine doit être désactivé et autre.
Donc, si vous voulez vous disputer, utilisez SSH sur le port> 1024 pendant quelques années.
p / s: 1124 n'est pas mon numéro de port SSH. Haha.
Bien déplacer SSH vers un autre port n'a pas de sens, cela contribue à la sécurité mais pas énormément. Bien sûr, pour ce faire, vous devez contrôler vos pare-feu, mais ce n’est pas un problème pour vous. Ce qui annule l’avantage de déplacer le port, c’est l’ouverture de la gamme acceptée. En fait, je dirais qu’elle annule l’avantage et vous expose plus loin que ce que vous êtes aujourd’hui. Je suis sûr que vous pouvez le convaincre de déplacer le port ET de réduire considérablement la plage entrante en compilant une liste de points d'entrée probables au lieu de simplement les ouvrir.
Changer de port ssh est un exercice inutile qui ne vous rapporte qu'une sécurité limitée. Il vaut mieux désactiver simplement l’authentification par mot de passe, ce qui élimine le risque de tentatives de mot de passe brutales, et se fier exclusivement à l’authentification basée sur la clé ssh. Si votre environnement nécessite une authentification par mot de passe, adoptez un mécanisme à deux facteurs, tel que SecurID ou Wikid.
Ces deux solutions vous apportent une réelle augmentation de la sécurité, tandis que la modification du port ssh ne vous donne que l’illusion de sécurité.
C'est pratique: j'ai utilisé des serveurs ssh privés publiquement visibles pendant plus de quatre ans avec un port SSH modifié et je n'avais aucune tentative d'analyse de mot de passe. Par souci d’assurance qualité, je viens d’activer 22 l’un d’entre eux pour une journée. En conséquence, j'ai été scanné environ toutes les 10 minutes avec une fréquence de tentative de mot de passe d'environ 5 par seconde. De plus, "scan kiddies" recherche également des serveurs avec certaines vulnérabilités OpenSSH.
Bien sûr, c’est la sécurité par l’obscurité qui n’aide en rien si vous avez l’ennemi.
Cela fonctionne très bien, indépendamment des gémissements de la foule "sécurité par l'obscurité".
Lapins stupides, TOUTES la sécurité est la sécurité à travers l'obscurité. Ce n'est pas parce que vous croyez que l'obscur protocole de cryptographie Z [nécessitant une combinaison d'échantillons d'ADN, de clés partagées et impossible à saisir avec des mots de passe humains] est réellement sécurisé. La vérité est que toute mesure de sécurité repose sur des probabilités et des hypothèses formulées par les utilisateurs. Tant pis pour vous si je sais comment exploiter cette hypothèse, mais voilà.
En tous cas,
Nous le faisons depuis des années, avec a) un nombre limité de tentatives de connexion (cependant, je ne sais pas comment nous l’avons configuré, quelque chose dans la configuration ssh), et b) un script pour interdire tout hôte exécutant une attaque par dictionnaire avec plus de X devine mal en Y minutes. Nous interdisons à l'hôte d'établir la connexion pendant un certain temps, ce qui facilite son adaptation à la topologie des réseaux en évolution.
Si vos mots de passe sont suffisamment complexes et qu'ils ne peuvent faire que 3 tentatives en 15 minutes, il n'y a pas grand chose à craindre. Il n’est pas si difficile de surveiller les attaques distribuées, nous le faisons habituellement par sous-réseau et ip pour exclure ce genre de chose.
Enfin, tout ce dont vous avez besoin, c’est d’une méthode secrète en écureuil pour permettre les connexions à votre port en modifiant les règles f / w. Cela peut être n'importe quoi ... smtp, web, requêtes dns magiques. Des produits tels que SecurID ou Wikid donnent simplement plus d’informations à des tiers. Et ne me lancez pas sur des certificats sécurisés par des tiers.
-1, Tu n'as pas l'air de comprendre ce qu'est l'obscurité ... Faire quelque chose de pas évident, ce n'est pas la même chose que de le verrouiller. Il est vrai qu’aucune sécurité n’est absolue, mais il existe des différences et l’authentification à trois facteurs avec obscurité n’aide personne.
Chris S
1
Désolé, Chris, c'est la religion culte de la cargaison. Peut - être que vous ne pouvez pas choisir un verrou, et je pense donc avoir un fait de vous sécuriser, mais tous les verrous peuvent être retirés. Sortez des sentiers battus: dans de nombreux cas, faire quelque chose de "non évident" peut être supérieur à un verrou. Votre modèle / vision de la sécurité est comme laisser votre ordinateur portable dans une voiture verrouillée avec le système d'alarme - un tweaker avec une pierre et votre ordinateur portable est parti. Mais peut-être que ce n'est pas un tweaker, mais quelqu'un avec un exploit de 0 jour et le temps de tuer ... Oh, regarde! Chris a une cible "sécurisée" et bien visible! L’obscurité est une partie TRÈS importante de la sécurité.
joe aléatoire
Désolé, mais votre comparaison et votre logique ne tiennent pas. Je sais cueillir des serrures, il est plus rapide de les couper, de casser une fenêtre, de faire le tour. Chaque mesure de sécurité nécessite du temps et des efforts pour la contourner; l'obscurité demande peu de temps et d'efforts, de l'ordre de quelques minutes à quelques heures. La vraie sécurité, comme les tentatives de mot de passe limitant le débit, fait en sorte que le mot de passe prenne beaucoup de temps. Cette importante disparité dans le temps est la différence entre une "fausse" sécurité et une "réelle"; l'obscurité tombe dans le premier.
Réponses:
Cela n’est pas aussi utile que le prétendent certaines personnes, mais au moins, cela réduira au minimum l’impact sur vos fichiers journaux, car de nombreuses tentatives de connexion brutale utilisent uniquement le port par défaut au lieu d’analyser pour voir si SSH écoute ailleurs. Certaines attaques vont rechercher SSH ailleurs, alors ce n’est pas une solution miracle.
Si votre serveur doit être un hôte partagé, plutôt que de simplement répondre aux besoins de vos projets, l’utilisation d’un port autre que celui par défaut peut s'avérer difficile, car vous devrez l'expliquer encore et encore à vos utilisateurs. terminé quand ils oublient et que leurs programmes clients ne parviennent pas à se connecter au port 22!
Un autre problème possible avec SSH sur un port non standard est le cas où vous rencontrez un client avec un ensemble de filtres sortant restrictif, qui ne peut pas se connecter à votre port personnalisé car son filtre autorise uniquement, par exemple, les ports 22, 53 et 80. et 443 comme destination pour les nouvelles connexions sortantes. Ceci est rare, mais certainement pas inouï. De même, certains FAI peuvent voir le trafic chiffré sur un port autre que ceux sur lesquels il est généralement prévu (port 443 ou HTTPS, 22 pour SSH, etc.) comme tentative de masquage d'une connexion P2P et limitation (ou blocage) la connexion de manière incommode.
Personnellement, je garde SSH sur le port standard pour plus de commodité. Tant que les précautions habituelles sont prises (mot de passe fort / stratégie de clé, restriction des connexions à la racine, ...), il n’ya pas lieu de s’inquiéter et le problème de croissance du fichier journal lorsque vous êtes victime d’une attaque par force brute peut être atténué à l’aide d’outils tels que en tant que fial2ban pour bloquer temporairement les hôtes qui fournissent un trop grand nombre de mauvais identifiants d'authentification dans un laps de temps donné.
Quel que soit le port que vous avez choisi, si vous vous éloignez de 22, assurez-vous qu'il est inférieur à 1024. Sous la plupart des configurations de type Unix-a-a dans leur configuration par défaut, seuls les utilisateurs racine (ou les utilisateurs du groupe racine) peuvent écouter sur les ports inférieurs à 1024, mais tout utilisateur peut écouter sur les ports les plus élevés. L'exécution de SSH sur un port supérieur augmente le risque qu'un utilisateur malhonnête (ou piraté) parvienne à bloquer votre démon SSH et à le remplacer par son propre proxy ou par un autre.
la source
C'est une forme simple (mais étonnamment efficace) de sécurité par l'obscurité .
Si votre serveur SSH n'est pas sur le port 22, les personnes qui parcourent Internet tout entier sont moins susceptibles de trouver des mots de passe faibles pour les comptes par défaut. Si vous analysez tout le réseau, vous ne pouvez pas vous permettre de vérifier tous les 64k ports possibles pour trouver le serveur SSH.
Cependant, si quelqu'un vous cible activement, cela ne présente aucun avantage, puisqu'un simple
nmapbalayage unique révélera le port sur lequel il est exécuté.la source
Pour vraiment éviter les attaques par force brute, il est toujours important de suivre certaines étapes:
la source
Oui, c'est utile car cela permet d'éviter les attaques par force brute et de garder les journaux clairs :)
en ce qui concerne le numéro de port qui vous appartient, j’ai vu des entreprises en utiliser 1291 assez souvent. J'utilise quelque chose de plus élevé, juste pour éviter certains scripts.
Ne pas autoriser les connexions root ssh et changer le numéro de port et peut-être quelque chose comme fail2ban et vous devriez être en or. ajoutez iptables pour faire bonne mesure et tenez-vous au courant, vous ne devriez pas avoir de problèmes.
la source
Je considère que les avantages suivants de l'exécution de sshd sur un port non standard sont plus importants que les problèmes qu'il crée:
De plus, si vous voulez être vraiment méchant, vous pouvez toujours exécuter un faux sshd (avec DenyUsers * ) sur le port standard 22, alors que votre sshd habituel fonctionne sur le port 54321. Cela vous assurera que tous les robots et les intrus faramineux resteront à jamais. essayez de vous connecter à un service qui refuse toutes les connexions, car personne ne songe à essayer de trouver votre vrai service sshd.
Mes 2 centimes
la source
Faire cela pour une raison de "sécurité" est faux. C'est le meilleur exemple de sécurité par obscurité qui n'est pas sécurité.
Si vous voulez garder vos journaux un peu plus légers et plus propres, alors oui, c’est utile, car vous n’obtiendrez pas autant de tentatives de frappe de port / script-kiddy bruteforce.
la source
Je voudrais exécuter ssh sur le port standard et utiliser quelque chose comme fail2ban ou denyhosts pour limiter le nombre d'attaques par dictionnaire.
Une autre option consiste à désactiver la connexion avec les mots de passe altogheter et à n'autoriser que les connexions avec ssh-keys.
la source
Parce qu'il y a beaucoup de personnes mal intentionnées qui analysent toutes les adresses IP de serveur à la recherche de ports ouverts dans le but d'exploiter. J'avais des attaques de marteau sur mon port SSH toute la journée, jusqu'à ce que je le déplace sur un autre port et sur une adresse IP qui n'était plus liée à aucun de mes sites Web.
la source
C'est utile en ce que les script-bots qui tentent des attaques par force brutale de deviner le mot de passe se concentrent généralement sur le port 22, donc changer les ports les jette généralement. Vous devrez équilibrer la valeur d'atténuer ce risque avec la difficulté de configurer les clients ssh pour qu'ils se connectent au port non standard (ce n'est pas très pénible si de nombreux utilisateurs ne se connectent pas, il est vrai).
Vous pouvez également limiter le risque de force brute en désactivant l'authentification par mot de passe et en exigeant une authentification par clé RSA.
En général, je ne change pas le port sur SSHD, je ne peux donc pas suggérer un autre numéro, mais consultez la liste des ports couramment utilisés pour trouver un autre numéro (c'est-à-dire un numéro qui n'est pas utilisé par autre chose et qui pourrait donc être scanné). .
la source
Je change toujours mon disque SSH pour utiliser le port 2222, tout le monde qui aurait besoin d'entrer dans mes serveurs le sait et ce n'est pas un secret. Cela n'apporte absolument aucun gain de sécurité (à moins que le pirate informatique potentiel ne soit un imbécile absolu).
Le seul avantage que je tire de cela est que le journal d'authentification n'a pas un million de tentatives de connexion infructueuses pour 'root', 'alice', 'bob', 'sally', 'admin', etc.
la source
La sécurité par l’obscurité s’est avérée inutile. En général, je configure l’accès ssh avec le port standard pour toutes les raisons mentionnées ci-dessus (problèmes de client lors de la reconfiguration, problèmes de pare-feu et de proxy, etc.).
En plus de cela, je désactive toujours les identifiants root et les authentifications par mot de passe et, en dernier lieu, j'utilise fail2ban pour me débarrasser de ces messages gênants dans le syslog. Dans Debian / Ubuntu, c'est aussi simple que de taper
aptitude install fail2ban. La configuration par défaut fonctionne plutôt bien, mais je règle généralement certains paramètres pour qu'ils soient plus restrictifs, avec un délai d'interdiction plus long (au moins un jour) et seulement deux tentatives d'authentification ayant échoué comme déclencheur de l'interdiction.la source
Je dirais que la chose contre laquelle vous vous protégez le plus lorsque vous changez le port SSH sont des analyses automatisées qui tenteront d’obtenir un accès en utilisant des noms d’utilisateur / mots de passe standard. Si vos règles de mot de passe sont strictes, vous ne devriez pas avoir à vous soucier de leur.
la source
Si vous désactivez les connexions par mot de passe sur votre serveur (ce qui est vivement recommandé), la modification du port SSH est totalement inutile. En désactivant les connexions par mot de passe (et en exigeant une authentification basée sur une clé), vous éliminez la possibilité de tentatives de mot de passe brutales. Vous ne gagnez donc rien en utilisant des numéros de port.
Si vous continuez à autoriser l'authentification par mot de passe, vous vous exposez à la possibilité d'une tentative de force brute réussie ou - plus communément, d'après mon expérience - votre mot de passe est compromis parce que vous le tapez lors de l'utilisation d'un système en cours d'exécution. un keylogger.
la source
man ssh-keygenpour beaucoup d'informations.Malgré le fait de ressembler à une "sécurité par obscurité" typique, j’estimerais que cela a du sens, car analyser tous les ports possibles (~ 64k) est beaucoup plus coûteux en temps que l’un d’eux.
Mais je peux ajouter que le "port frappant" est bien meilleur.
la source
Pas une réponse, mais trop longue pour un commentaire, je vais donc faire cette CW.
Je réfléchis à celui-ci depuis un moment et j'en suis venu à la conclusion qu'il y a beaucoup de vérité dans ce que Juliano dit dans les commentaires sur la réponse d'Alnitak. Néanmoins, je trouve qu'en exécutant SSH sur le port 22, il est beaucoup trop facile de lancer des attaques de toutes sortes contre celui-ci.
Pour résoudre ce problème, j'exécute mes serveurs SSH internes sur le port 22 et utilise le pare-feu pour transférer le port haut sur 22 sur les ordinateurs cibles. Cela donne une certaine sécurité grâce à l'obscurité tout en maintenant la sécurité d'un port bas, comme l'a souligné Juliano.
La sécurité par l'obscurité n'est pas un principe auquel je souscris normalement et il est souvent souligné qu'un simple scan de port révélera le port cible, rendant ainsi l'obscurité sans valeur. Pour résoudre ce problème, mes pare-feu (Smoothwall Express), au travail et à la maison, utilisent un script appelé Guardian Active Response, déclenché par des alertes Snort. D'après les observations, je peux vous dire que lorsque vous frappez plus de 3 ports différents de la même source, vos paquets sont perdus jusqu'à l'heure de réinitialisation prédéfinie. Cela rend assez difficile et prend beaucoup de temps pour exécuter une analyse de port, rendant l'obscurité vraiment utile. En fait, cela m'a fait taire tellement de fois dans le passé que j'ai défini une exclusion pour mon adresse IP source (à la maison ou au bureau).
la source
Le problème que vous avez, c'est que le pare-feu est configuré pour autoriser uniquement certaines adresses IP à se connecter, et le patron en a assez d'ouvrir d'autres adresses IP lorsqu'il est en déplacement. Si vous verrouillez certaines adresses IP au niveau du pare-feu, cela peut être pénible.
Deux choses que je pense ici. Changer le port protège contre les attaques automatisées. C'est à peu près tout, mais cela représente une grande partie du trafic d'attaque moyen… des scripts automatisés analysant les réseaux. Si vous modifiez le port par défaut, ces attaques devraient disparaître. Cela a donc du sens à cet égard. Mais cela ne fait rien contre une attaque dirigée, l’attaquant pouvant simplement scanner à partir de Nessus ou de NMAP pour déterminer le ou les ports que vous utilisez si vous avez un petit ami spécial qui vous hait suffisamment.
Deuxièmement, si vous utilisez des serveurs de type UNIX, vous pouvez installer un utilitaire tel que Denyhosts pour arrêter les attaques. Si vous installez denyhosts, il surveille les tentatives de connexion incorrectes et après (quel que soit le nombre que vous déterminez) a échoué, il interdira l'IP pendant une période de temps que vous spécifiez. Denyhosts peut également parler à d'autres hôtes de denyhost et transmettre des listes d'interdiction. Ainsi, si un attaquant est verrouillé hors du système Linux de Fred au Montana, votre système obtiendra également cette adresse IP pour interdiction. Très utile tant que vos utilisateurs se souviennent de leurs mots de passe.
Tout dépend de vos scénarios d'utilisation. Combien de programmes avez-vous qui sont "pénibles" pour changer le port de connexion pour SSH / SCP (et s’ils ne le permettent pas ou ne gênent pas, vous devez vraiment envisager de changer de fournisseur, personnellement). S'il ne s'agit que d'une peur potentielle, je dirais que ce n'est pas un problème. Et voici votre patron, qui demande quelque chose qui n’est pas complètement farfelu, car beaucoup d’administrateurs système basculent le port SSH (avec un flak de ceux qui détestent tout ce qui sent la sécurité même à travers l’obscurité ... mais cela réduit vraiment la le bruit de fond cruft des balayages automatisés.)
En bouleversant - changer les ports bloque les scripts automatisés et la plupart du trafic. Ne pas arrêter les attaquants dirigés. Pensez également à installer un utilitaire d'interdiction automatique. La sécurité dans les couches ne vous fait pas mal si c'est bien fait et changer de ports aide plus que ça fait mal dans la plupart des situations.
la source
J'utilise SSH sur le port> 1024 depuis plus de 5 ans maintenant. Depuis lors, je n'ai vu aucune tentative d'analyse de port dans mon fichier journal (sauf de ma propre initiative). Il y a mes serveurs que j'administre qui utilisent le port> 1024.
Beaucoup de serveurs SSH qui fonctionnent sur le port> 1024 ont leurs propres sites Web, ce qui est assez populaire.
Si le serveur SSH fonctionne dans ma propre entreprise, j'ai peut-être déjà posté l'adresse IP de ce serveur ici afin que vous puissiez essayer de pirater le serveur. Malheureusement, le serveur SSH n'est pas le mien. ;-)
Mais il y a d'autres choses que vous devez configurer pour le rendre sécurisé. SSH> 1024 ne suffirait pas. Le numéro de port ne doit pas être dans le fichier / etc / services, il faut utiliser le transfert de port (par exemple, le port 1124-> 22), l'accès direct à la racine doit être désactivé et autre.
Donc, si vous voulez vous disputer, utilisez SSH sur le port> 1024 pendant quelques années.
p / s: 1124 n'est pas mon numéro de port SSH. Haha.
la source
Je suppose que si vous n’avez pas encore découvert le port cogner à sa portée, sinon, non.
la source
Bien déplacer SSH vers un autre port n'a pas de sens, cela contribue à la sécurité mais pas énormément. Bien sûr, pour ce faire, vous devez contrôler vos pare-feu, mais ce n’est pas un problème pour vous. Ce qui annule l’avantage de déplacer le port, c’est l’ouverture de la gamme acceptée. En fait, je dirais qu’elle annule l’avantage et vous expose plus loin que ce que vous êtes aujourd’hui. Je suis sûr que vous pouvez le convaincre de déplacer le port ET de réduire considérablement la plage entrante en compilant une liste de points d'entrée probables au lieu de simplement les ouvrir.
la source
Changer de port ssh est un exercice inutile qui ne vous rapporte qu'une sécurité limitée. Il vaut mieux désactiver simplement l’authentification par mot de passe, ce qui élimine le risque de tentatives de mot de passe brutales, et se fier exclusivement à l’authentification basée sur la clé ssh. Si votre environnement nécessite une authentification par mot de passe, adoptez un mécanisme à deux facteurs, tel que SecurID ou Wikid.
Ces deux solutions vous apportent une réelle augmentation de la sécurité, tandis que la modification du port ssh ne vous donne que l’illusion de sécurité.
la source
C'est pratique: j'ai utilisé des serveurs ssh privés publiquement visibles pendant plus de quatre ans avec un port SSH modifié et je n'avais aucune tentative d'analyse de mot de passe. Par souci d’assurance qualité, je viens d’activer 22 l’un d’entre eux pour une journée. En conséquence, j'ai été scanné environ toutes les 10 minutes avec une fréquence de tentative de mot de passe d'environ 5 par seconde. De plus, "scan kiddies" recherche également des serveurs avec certaines vulnérabilités OpenSSH.
Bien sûr, c’est la sécurité par l’obscurité qui n’aide en rien si vous avez l’ennemi.
la source
Cela fonctionne très bien, indépendamment des gémissements de la foule "sécurité par l'obscurité".
Lapins stupides, TOUTES la sécurité est la sécurité à travers l'obscurité. Ce n'est pas parce que vous croyez que l'obscur protocole de cryptographie Z [nécessitant une combinaison d'échantillons d'ADN, de clés partagées et impossible à saisir avec des mots de passe humains] est réellement sécurisé. La vérité est que toute mesure de sécurité repose sur des probabilités et des hypothèses formulées par les utilisateurs. Tant pis pour vous si je sais comment exploiter cette hypothèse, mais voilà.
En tous cas,
Nous le faisons depuis des années, avec a) un nombre limité de tentatives de connexion (cependant, je ne sais pas comment nous l’avons configuré, quelque chose dans la configuration ssh), et b) un script pour interdire tout hôte exécutant une attaque par dictionnaire avec plus de X devine mal en Y minutes. Nous interdisons à l'hôte d'établir la connexion pendant un certain temps, ce qui facilite son adaptation à la topologie des réseaux en évolution.
Si vos mots de passe sont suffisamment complexes et qu'ils ne peuvent faire que 3 tentatives en 15 minutes, il n'y a pas grand chose à craindre. Il n’est pas si difficile de surveiller les attaques distribuées, nous le faisons habituellement par sous-réseau et ip pour exclure ce genre de chose.
Enfin, tout ce dont vous avez besoin, c’est d’une méthode secrète en écureuil pour permettre les connexions à votre port en modifiant les règles f / w. Cela peut être n'importe quoi ... smtp, web, requêtes dns magiques. Des produits tels que SecurID ou Wikid donnent simplement plus d’informations à des tiers. Et ne me lancez pas sur des certificats sécurisés par des tiers.
la source